Talk:SDLC v1 - Revision history

Rimi at 14:00, 26 April 2016

2016-04-26T14:00:46Z

← Older revision		Revision as of 14:00, 26 April 2016
Line 25:		Line 25:

	--		--
	- 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.		* 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.

Rimi at 14:00, 26 April 2016

2016-04-26T14:00:20Z

← Older revision		Revision as of 14:00, 26 April 2016
Line 23:		Line 23:

	For release 1, the call for features can start now, without the need to have release 0 ready.		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.

Garciadeblas at 11:26, 26 April 2016

2016-04-26T11:26:32Z

← Older revision		Revision as of 11:26, 26 April 2016
Line 21:		Line 21:
	**Feature hardening: Weeks 21-25		**Feature hardening: Weeks 21-25
	**Documentation: 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.

Garciadeblas at 11:24, 26 April 2016

2016-04-26T11:24:53Z

← Older revision		Revision as of 11:24, 26 April 2016
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:
	~~That workflow does not take into account feature collection and prioritization by TSC. I suggest to take it into account in the life cycle:~~		***Week 4
	*Explicit Call for features and use cases:		***Prioritization by TSC
	**Weeks 1-3		***Identification of module requirements per feature by TSC and MDL
	**Input from EUAG and the community to TSC		*'''Feature development: 16 weeks'''
	*Feature prioritization and identification of module requirements:		**Design artifacts/blueprints in markdown, as part of the git repo:
	**Week 4		***By MDG Leads and Committers
	**Prioritization by TSC		***Weeks 5-7
	**Identification of module requirements per feature by TSC and MDL		**Acceptance Criteria and Tests (first draft)
	*Design artifacts/blueprints in markdown, as part of the git repo:		***Weeks 5-7
	**By MDG Leads and Committers		**Coding:
	**Weeks 5-7		***From week 8 or sooner depending on blueprints availability, up to week 20.
	*Acceptance Criteria and Tests (first draft)		*'''Feature hardening and documentation: 5 weeks'''
	**Weeks 5-7		**Feature hardening: Weeks 21-25
	*Coding:		**Documentation: Weeks 21-25
	**From week 8 or sooner depending on blueprints availability, up to week 20.
	*Feature hardening
	**Weeks 21-25
	*Documentation
	**Weeks 21-25

Garciadeblas: 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..."

2016-04-26T11:14:16Z

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..."

New page

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 suggested:
*Key Scope / Themes identified in first 2 weeks (eg. 80% of the scope for the release)
*Some idea of Demo Scenarios in first 2 weeks
*Key Architecture / Design artifacts delivered in the first 4 weeks, in markdown, as part of the git repo
*Key Acceptance Criteria and Tests (first draft) delivered in first 4 weeks (think TDD)

That workflow does not take into account feature collection and prioritization by TSC. I suggest to take it into account in the life cycle:
*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
*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