Talk: SDLC v1: Difference between revisions

From OSM Public Wiki
Jump to: navigation, search
(Created page with "Regarding the split of budget weeks for each SDLC, I suggest to move from 16 weeks for Feature Development to 20 weeks. Regarding the workflow for the design phase, it was su...")
 
mNo edit summary
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Regarding the split of budget weeks for each SDLC, I suggest to move from 16 weeks for Feature Development to 20 weeks.
Regarding the split of budget weeks for each SDLC, the current split does not take into account feature collection and prioritization by TSC. I suggest to take it into account in the life cycle. Besides, I suggest to make feature hardening and documentation stay in parallel.


Regarding the workflow for the design phase, it was suggested:
My proposal below:
*Key Scope / Themes identified in first 2 weeks (eg. 80% of the scope for the release)
*'''Call for features and prioritization: 4 weeks'''
*Some idea of Demo Scenarios in first 2 weeks
**Explicit Call for features and use cases:
*Key Architecture / Design artifacts delivered in the first 4 weeks, in markdown, as part of the git repo
***Weeks 1-3
*Key Acceptance Criteria and Tests (first draft) delivered in first 4 weeks (think TDD)
***Input from EUAG and the community to TSC
**Feature prioritization and identification of module requirements:
***Week 4
***Prioritization by TSC
***Identification of module requirements per feature by TSC and MDL
*'''Feature development: 16 weeks'''
**Design artifacts/blueprints in markdown, as part of the git repo:
***By MDG Leads and Committers
***Weeks 5-7
**Acceptance Criteria and Tests (first draft)
***Weeks 5-7
**Coding:
***From week 8 or sooner depending on blueprints availability, up to week 20.
*'''Feature hardening and documentation: 5 weeks'''
**Feature hardening: Weeks 21-25
**Documentation: Weeks 21-25


That workflow does not take into account feature collection and prioritization by TSC. I suggest to take it into account in the life cycle:
For release 1, the call for features can start now, without the need to have release 0 ready.
*Explicit Call for features and use cases:
 
**Weeks 1-3
--
**Input from EUAG and the community to TSC
 
*Feature prioritization and identification of module requirements:
* The original plan called for 2 weeks features and use cases, followed by 2 weeks of architecture / design (arch/design work could happen in parallel).  Net net, first 4 weeks, or 15% of the cycle dedicated to initial features and design. More time may be needed initially, while the backlog is developing more extensively. Future cycles may not need as much time.
**Week 4
* Expanding this first part to 4 weeks, and having the final 2 phases go in parallel, may be reasonable. We can try it and determine whether the pace is adequate.
**Prioritization by TSC
**Identification of module requirements per feature by TSC and MDL
*Design artifacts/blueprints in markdown, as part of the git repo:
**By MDG Leads and Committers
**Weeks 5-7
*Acceptance Criteria and Tests (first draft)
**Weeks 5-7
*Coding:
**From week 8 or sooner depending on blueprints availability, up to week 20.
*Feature hardening
**Weeks 21-25
*Documentation
**Weeks 21-25

Latest revision as of 14:00, 26 April 2016

Regarding the split of budget weeks for each SDLC, the current split does not take into account feature collection and prioritization by TSC. I suggest to take it into account in the life cycle. Besides, I suggest to make feature hardening and documentation stay in parallel.

My proposal below:

  • Call for features and prioritization: 4 weeks
    • Explicit Call for features and use cases:
      • Weeks 1-3
      • Input from EUAG and the community to TSC
    • Feature prioritization and identification of module requirements:
      • Week 4
      • Prioritization by TSC
      • Identification of module requirements per feature by TSC and MDL
  • Feature development: 16 weeks
    • Design artifacts/blueprints in markdown, as part of the git repo:
      • By MDG Leads and Committers
      • Weeks 5-7
    • Acceptance Criteria and Tests (first draft)
      • Weeks 5-7
    • Coding:
      • From week 8 or sooner depending on blueprints availability, up to week 20.
  • Feature hardening and documentation: 5 weeks
    • Feature hardening: Weeks 21-25
    • Documentation: Weeks 21-25

For release 1, the call for features can start now, without the need to have release 0 ready.

--

  • The original plan called for 2 weeks features and use cases, followed by 2 weeks of architecture / design (arch/design work could happen in parallel). Net net, first 4 weeks, or 15% of the cycle dedicated to initial features and design. More time may be needed initially, while the backlog is developing more extensively. Future cycles may not need as much time.
  • Expanding this first part to 4 weeks, and having the final 2 phases go in parallel, may be reasonable. We can try it and determine whether the pace is adequate.