Talk: SDLC v1: Difference between revisions
From OSM Public Wiki
Garciadeblas (talk | contribs) (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 | 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. | |||
* | |||
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
- Explicit Call for features and use cases:
- 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.
- Design artifacts/blueprints in markdown, as part of the git repo:
- 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.