[MSF] Phases vs Milestones

[BikkelZ]

Ik moet als afstudeeropdracht op mijn werk een project doen wat op 31 december live moet zijn. Omdat ik dan waarschijnlijk alleen de core functionaliteit af heb, wil ik hem in een aantal delen opbreken waarbij ik aan de hand van mijn moscow analyse en verspreid over de logische delen van een applicatie bepaal wat ik wanneer oplever, en welke zaken optioneel zijn en welke niet. Ik ben gewend dat milestones te noemen. Afgesloten blokken functionaliteit die getest kunnen worden.

In MSF heb je een aantal fases, en na iedere fase heb je een milestone bereikt. En development, dat is maar één fase cq. milestone. Een andere optie die er is noemen ze de Iterative Approach, waarbij ik alle fases weer opnieuw moet gaan doorlopen. En dat lijkt me weer overkill.

Wat is de filosofie hier achter?

Ik wil de applicatie in delen bouwen, zodat op 31 december iedereen al vrolijk er mee aan de slag kan zijn omdat de eerste twee delen al opgeleverd zijn, en dat het laatste deel pas daarna toegevoegd wordt.

Ik kan me wel voorstellen dat je na iedere oplevering van een deel evalueert, maar dan hoef ik toch niet door een complete nieuwe cycle heen te gaan?

Wie heeft er ervaring mee?

[BikkelZ]

Uit wat documentatie over MSF:

Recommended Interim Milestones

Proof of Concept Complete
The proof of concept tests key elements of the solution on a non-production simulation of the existing environment. The team walks operations staff and users through the solution to validate their requirements.

Internal Build n Complete, Internal Build n+1 Complete
Because the developing phase focuses on building the solution, the project needs interim milestones that can help the team measure build progress.

Developing is done in parallel and in segments, so the team needs a way to measure progress as a whole. Internal builds accomplish this by forcing the team to synchronize pieces at a solution level.

How many builds and how often they occur will depend on the size and duration of the project. Often it makes sense to set interim milestones to achieve a visual design freeze and a database freeze because of the many dependencies on these. For example, the screens that are needed to create documentation and the database schema form a deep part of the overall architecture.

Dus dan kan ik ook internal build milestones kunnen maken, met bijbehorende proof of concept milestones. Verder lijkt het me het verstandigste twee keer de development cycle doorlopen, een keer voor 31 december en één keer na 31 december.


Iemand nog een duit in het zakje te doen?

[mOrPhie]

Het gaat erom dat je een fase afsluit met deliverables. Dit kunnen er ook goed meerdere zijn. Welke deliverables dat zijn, is aan jou. Dat kun je zelf bepalen. In de envisioning schrijf je meestal een Vision/Scope document, maar je zou er ook een risk management plan kunnen doen. Het hangt helemaal van de omvang en impact van het project af. MSF doet hier wat recommendations in, maar je hoeft ze niet per se op te volgen. Milestones zijn delen van deliverables die in 1 iteratie worden opgeleverd.

Het aantal iteraties in een fase is aan jou. Dit hangt weer van de situatie af. Het is wel zo dat in kleine projecten de envisioning en planning fase meestal ieder 1 iteratie zijn. De development deel je op in meerdere iteraties. Soms veel kleine iteraties, soms wat minder en grotere iteraties. Het is in elk geval de bedoeling dat je iedere iteratie aan -elke- deliverable werkt. Zorg wel dat je per project 1 iteratieduur per fase kiest en dus niet gaat zwalken.

Deployment en stabalizing vind ik zelf altijd lastig. Ik doe tijdens de development altijd graag een proefdeployement. Je zou het zelf kunnen opnemen als deliverable. Of dat van MSF mag weet ik niet. Maar het voelt imho wat veiliger als je de deployment al een keer hebt doorlopen tijdens ontwikkeling. De deploymentfase is dan normaalgesproken 1 iteratie. Stabalizingfase is zoevel fases als je nodig hebt of budget voor hebt. Ik zou zelf minimaal uit gaan van 2 kleine iteraties (van bijvoorbeeld een week) in een klein project.

Een milestone is dus een deelproduct of draft van een deliverable binnen een fase.

In elk geval is het zo dat wanneer je slechts een korte periode denkt bezig te zijn, toch met iteraties te werken, maar dan de iteraties een stuk korter te houden.

[ Voor 5% gewijzigd door mOrPhie op 05-08-2008 15:14 ]

[BikkelZ]

Ah kijk, en passant zelfs een paar vragen beantwoord die ik nog niet eens gesteld had

mOrPhie schreef op dinsdag 05 augustus 2008 @ 15:11:Zorg wel dat je per project 1 iteratieduur per fase kiest en dus niet gaat zwalken.

Wat bedoel je daar precies mee?

[Verwijderd]

BikkelZ schreef op dinsdag 05 augustus 2008 @ 16:08:
Wat bedoel je daar precies mee?

Dat je niet een iteratie van 3 weken doet, dan weer een iteratie van 2 weken, dan weer van 4. Ik heb zelf geen ervaring met MSF maar wel met agile/scrum waar je ook met iteraties werkt. Het vervelende aan variabele iteraties bij agile (en ik vermoed ook bij MSF) is dat je a) niet echt een lekker ritme op kunt bouwen en b) moeilijk leert plannen (een gevoel ontwikkelt voor) wat wel en niet binnen een iteratie past. MSF klinkt interessant, daar ga ik eens dieper in duiken.

[BikkelZ]

Verwijderd schreef op dinsdag 05 augustus 2008 @ 20:39:
[...]

Dat je niet een iteratie van 3 weken doet, dan weer een iteratie van 2 weken, dan weer van 4. Ik heb zelf geen ervaring met MSF maar wel met agile/scrum waar je ook met iteraties werkt. Het vervelende aan variabele iteraties bij agile (en ik vermoed ook bij MSF) is dat je a) niet echt een lekker ritme op kunt bouwen en b) moeilijk leert plannen (een gevoel ontwikkelt voor) wat wel en niet binnen een iteratie past. MSF klinkt interessant, daar ga ik eens dieper in duiken.

Ja ik heb nu 6/5/5 weken gedaan, waarbij ik in de eerste fase zeg maar de fundering leg voor de applicatie, de database en stored procedures maak en de hele structuur binnen de applicatie, dus daar dan dat extra weekje naar toe gezet heb. Ik heb duidelijk aangegeven dat er een versie 2 is maar daar verder nog helemaal niets over gezegd, omdat het in principe gewoon een compleet nieuwe cycle is.

Ik moet zeggen dat de documentatie wel behoorlijk netjes is, je hebt een speciale subsite met allerlei document templates en documentatie, en ondanks dat het nog niet helemaal compleet is is het zeker uitgebreid genoeg voor mij. Bovendien kun je je ook certificeren voor MSF, iets wat volgens mij toch wel een heel mooi pluspunt is op je CV.

[mOrPhie]

BikkelZ schreef op woensdag 06 augustus 2008 @ 10:05:
[...]


Ja ik heb nu 6/5/5 weken gedaan, waarbij ik in de eerste fase zeg maar de fundering leg voor de applicatie, de database en stored procedures maak en de hele structuur binnen de applicatie, dus daar dan dat extra weekje naar toe gezet heb. Ik heb duidelijk aangegeven dat er een versie 2 is maar daar verder nog helemaal niets over gezegd, omdat het in principe gewoon een compleet nieuwe cycle is.

Met fase bedoel je iteratie*? Je moet om je aan de einddatum te kunnen houden wel schatten wat het kost om bepaalde delen van het systeem te maken. Zo kun je alleen inplannen en kun je eventueel zeggen dat je tijd over hebt, of tijd te kort komt. Als je tijd te kort komt, dan gebruik je een MoSCoW lijst om te kijken wat eerst moet en wat vervolgens gekozen kan worden. Je iteratieplanning kun je wel bij aanvang van de iteratie doen, maar je moet wel weten wat je in de beschikbare tijd kunt verwezenlijken. Nooit de aanname doen dat je genoeg tijd hebt. Dat kan wel 'ns tegen vallen.

Je noemt een project met een vaste begin en einddatum ook wel een "timebox" project. In MSF termen kun je dat beschrijven met de "Trade-Off Matrix" (zoek maar op in de documentatie). Dat is een erg handig middel om opdrachtgevers duidelijk te maken dat ze niet alles in zo weinig mogelijk tijd kunnen krijgen. Een timebox project (welke je in je eentje doet) beschrijf je dan met: "Given fixed resources, we will choose a schedule and adjust features as necessary". NB: "choose a schedule" betekent niet dat de einddatum variabel is, maar dat je de keuze maakt om bijvoorbeeld tijd voor documentatie inpland, zodat je meer features kunt inplannen.

* Fases zijn afsluitbaar en brengen deliverables. Fases zijn wel overlapbaar. Immers, 2 analysten zouden aan de scenario's kunnen werken en een milestone daarvan over kunnen dragen aan developers. Dit kan uiteraard niet als je in je 1tje bent.

[BikkelZ]

Trade-off matrix is inderdaad een mooie om op dit project toe te passen

En je hebt inderdaad gelijk over iteratie ipv fase.

[ Voor 6% gewijzigd door BikkelZ op 06-08-2008 15:15 ]