Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
public:astron_pwt_agile_workshop [2012-06-04 02:12] – Adriaan Renting | public:astron_pwt_agile_workshop [2017-03-08 15:27] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 125: | Line 125: | ||
* De kosten om van een prototype (en ik zie LOFAR 1.0 gedeeltelijk als een prototype!) te komen naar een functioneel robuust systeem. (factor 3) | * De kosten om van een prototype (en ik zie LOFAR 1.0 gedeeltelijk als een prototype!) te komen naar een functioneel robuust systeem. (factor 3) | ||
* De kosten van het in huren van expertise vs. het in huis hebben ervan. | * De kosten van het in huren van expertise vs. het in huis hebben ervan. | ||
+ | * De kosten van late en constante wijzigingen in het ontwerp. | ||
+ | * De kosten van flexibiliteit, | ||
Ik snap dat hier ook afwegingen m.b.t. de opgelegde financieringsmodellen een rol spelen, waardoor de ideale keuze niet altijd gemaakt kan worden, maar ik heb het beeld dat er ook binnen die kaders veel niet optimale keuzes gemaakt worden wegens een gebrek aan inzicht in de uiteindelijke kosten. | Ik snap dat hier ook afwegingen m.b.t. de opgelegde financieringsmodellen een rol spelen, waardoor de ideale keuze niet altijd gemaakt kan worden, maar ik heb het beeld dat er ook binnen die kaders veel niet optimale keuzes gemaakt worden wegens een gebrek aan inzicht in de uiteindelijke kosten. | ||
Line 137: | Line 139: | ||
* Een focus om de meest arbeidsintensieve taken eerst te automatiseren. | * Een focus om de meest arbeidsintensieve taken eerst te automatiseren. | ||
* Het inramen van tijd en mankracht voor actieve bewaking van het software ontwikkelingsproces en de software architectuur. | * Het inramen van tijd en mankracht voor actieve bewaking van het software ontwikkelingsproces en de software architectuur. | ||
+ | * Het vroeg inzetten van die ontwikkelingen die het grootste risico hebben. | ||
==== Clear management ==== | ==== Clear management ==== | ||
- | Het LOFAR project heeft naar mijn mening veel te leiden gehad onder een gebrek aan een duidelijke chain-of-command en lijn van verantwoordelijkheid. Op veel lagen werden/ | + | Het LOFAR project heeft naar mijn mening veel te leiden gehad onder een gebrek aan een duidelijke chain-of-command en lijn van verantwoordelijkheid. Op veel lagen werden/ |
Daarnaast leeft bij mij het beeld bij de selectie/ | Daarnaast leeft bij mij het beeld bij de selectie/ | ||
- | Ik mis een duidelijke verantwoordelijkheidsstruktuur, duidelijke, meetbare doelen | + | |
+ | ==== Communicatie met developers ==== | ||
+ | |||
+ | Er wordt weinig met de developers gecommuniceerd over de verwachtingen, tijdslijnen en wat met externe partijen afgesproken is. Mogelijk dat dit wel in wollige documenten te vinden is, als deze al beschikbaar zijn. Ik denk dat de waarde van het actief opzoeken van directe communicatie hier onderschat wordt, en dat er ook een verschil in mondigheid is tussen de ontwikkelaars en wetenschappers wat mogelijk te weinig onderkend wordt. | ||
+ | |||
+ | Management is voor een groot gedeelte de communicatie tussen de ontwikkelaars en de eind-gebruikers en de algemene buitenwereld. Ik heb het gevoel dat er vaak een groot verschil zit in het beeld wat aan beide kanten leeft. | ||
==== 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, | + | Mijn beeld is dat er weinig gekeken wordt naar eerdere software projecten om daar lessen uit te trekken. (TMS, Newstar, AIPS++ bijvoorbeeld, |
- | 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. | + | |
+ | 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. | ||
===== Paviljoen West Team ===== | ===== Paviljoen West Team ===== | ||
Line 171: | Line 181: | ||
* Onderdelen die niet direct op het eigen ' | * Onderdelen die niet direct op het eigen ' | ||
* Een probleem wat zich voordoet wordt gauw op het eigen " | * Een probleem wat zich voordoet wordt gauw op het eigen " | ||
- | * Samengevat een sterke neiging om zich een klein stukje toe te eigenen, maar voor de rest de verantwoordelijkheid van zich af te schuiven naar andere developers of "Het management" | + | * Samengevat een sterke neiging om zich een klein stukje toe te eigenen, maar voor de rest de verantwoordelijkheid van zich af te schuiven naar andere developers of "het management" |
+ | |||
+ | ==== Testen ==== | ||
+ | |||
+ | 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, | ||
+ | |||
+ | ===== Conclusie ===== | ||
+ | |||
+ | Mijn voorlopige conclusie is dat zowel bij management als bij het PWT meer kennis nodig is van Software Management, zodat men elkaars ' | ||
+ | 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, | ||
+ | |||
+ | Ik zou graag op een hoger niveau naar de processen binnen Astron willen kijken dan alleen de implementatie van Scrum. |