public:astron_pwt_agile_workshop

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
public:astron_pwt_agile_workshop [2012-06-04 02:31] – Adriaan Rentingpublic:astron_pwt_agile_workshop [2017-03-08 15:27] (current) – external edit 127.0.0.1
Line 155: Line 155:
 ==== Lessons Learned ==== ==== Lessons Learned ====
  
-Mijn beeld is dat er weinig gekeken wordt naar eerdere software projecten om daar lessen uit te trekken. (TMS, Newstar, AIPS++ bijvoorbeeld, nu ook LOFAR).+Mijn beeld is dat er weinig gekeken wordt naar eerdere software projecten om daar lessen uit te trekken. (TMS, Newstar, AIPS++ bijvoorbeeld, nu ook LOFAR). Ik zou graag willen dat meer geleerd werd, zodat richting APERTIF en SKA niet dezelfde fouten gemaakt worden.
  
 Dit heeft ook te maken met mijn eerste PWT punt. Volgens mij is het met het huidige uren schrijf systeem (Primavera) en de manier waarop dat vanuit management aangestuurd wordt, vrijwel onmogelijk om een goed inzicht te hebben waar de knelpunten liggen in de besteding van manuren, in het ieder geval waar het software ontwikkeling betreft. Dit betekent dat men weinig kwantitatief inzicht heeft waar de grootste winst te behalen is en waar de grootste verliezen gemaakt worden. Ik denk dat hierdoor ook een sterke focus is op het binnenhalen van nieuwe projecten, en weinig reflectie op bestaande projecten. Dit heeft ook te maken met mijn eerste PWT punt. Volgens mij is het met het huidige uren schrijf systeem (Primavera) en de manier waarop dat vanuit management aangestuurd wordt, vrijwel onmogelijk om een goed inzicht te hebben waar de knelpunten liggen in de besteding van manuren, in het ieder geval waar het software ontwikkeling betreft. Dit betekent dat men weinig kwantitatief inzicht heeft waar de grootste winst te behalen is en waar de grootste verliezen gemaakt worden. Ik denk dat hierdoor ook een sterke focus is op het binnenhalen van nieuwe projecten, en weinig reflectie op bestaande projecten.
Line 186: Line 186:
  
 Wat duidelijk bleek uit de integratie stappen die de laatste tijd gedaan zijn, is dat er stukken software zijn die eigenlijk geen "test modus" hebben. Ook is er in de architectuur, voor zover deze er al is, weinig rekening daarmee gehouden. Ik denk dat een 'test modus' een expliciet onderdeel zou moeten zijn van interface en architectuur afspraken. Hoe deze vorm te geven is denk ik een discussie die we zo snel mogelijk moeten voeren. Wat duidelijk bleek uit de integratie stappen die de laatste tijd gedaan zijn, is dat er stukken software zijn die eigenlijk geen "test modus" hebben. Ook is er in de architectuur, voor zover deze er al is, weinig rekening daarmee gehouden. Ik denk dat een 'test modus' een expliciet onderdeel zou moeten zijn van interface en architectuur afspraken. Hoe deze vorm te geven is denk ik een discussie die we zo snel mogelijk moeten voeren.
 +
 +===== Conclusie =====
 +
 +Mijn voorlopige conclusie is dat zowel bij management als bij het PWT meer kennis nodig is van Software Management, zodat men elkaars 'sparring partner' kan zijn bij het verbeteren daarvan.
 +Daarnaast is meer transparantie nodig in verantwoording en verantwoordelijkheid en duidelijke lijnen voor de communicatie van doelen en prioriteiten en de terugkoppeling daarop. Op sommige plaatsen in de organisatie is een cultuur verandering nodig als we tot verbeteringen willen komen.
 +
 +Gedeeltelijk zijn deze problemen inherent aan de grootte van het project en de organisatie, en zou een stuk bewustwording voldoende zijn.
 +
 +Ik zou graag op een hoger niveau naar de processen binnen Astron willen kijken dan alleen de implementatie van Scrum.
  • Last modified: 2012-06-04 02:31
  • by Adriaan Renting