Software ontwikkel methodiek

[RiCk]

Ela,
Voor mijn werkgever / collega's ben ik eens aan het kijken naar een ontwikkel methodiek welke hier snel en simpel kan worden toegepast. De mensen hier ontwikkelen minimaal en ik wil de methodiek dus ook niet te zwaar neer leggen. Wij beheren hier een aantal ERP's (PeopleSoft) en onderhouden daarnaast wat kleinere applicaties en websites (portal). Het totaal van de mensen in dit team is 8. Wat mijn doel is van zo'n methodiek/cursus is om de mensen inzicht te geven in verschillende stadia van software ontwikkelen (van vraag naar overdracht) dit in projectperspectief geplaatst. Overigens zijn wij voornamenlijk hebben wij voornamenlijk internetapplicaties en koppelen wij een heleboel systemen aan elkaar

Ik heb reeds gekeken naar de opties:

- RUP
RUP is cool. Maar RUP is zwaar, ik heb niet zo'n zin om de mensen eerst een UML cursus te gaan geven oid.
- DSDM
Steeds meer bedrijven (en opleiders/certificering) stappen over op RUP, is DSDM uit?
- XP
Extreme programming is cool, maar ik zie dat hier niet zo snel werken ivm naar mijn mening vrijheden.
- RAD
Heb je ook nog ook interessant

Wat meer?

Wij hanteren hier Prince2 als projectmethodiek...

Wat vinden jullie toepasbaar/handelbaar voor een organisatie als deze?

[ Voor 6% gewijzigd door RiCk op 29-03-2007 09:34 ]

[Refro]

Wij zitten zo wat in dezelfde situatie hier. Ooit is geprobeer RUP in een keer neer te zetten en dit is uiteraard mislukt. Het projectmanagement gebeurt bij ons ook via PRINCE2. De rest van de ontwikkeling is een allegaartje van DSDM,XP en wat ons verder goed uitkomt. De nadruk ligt bij ons op het moment ook niet op het kiezen van een standaard methode en die overal gebruiken maar meer op kijken wat we nodig hebben en dat in ieder geval via een standaard techniek te doen.

Het moet dus vooral direct praktisch bruikbaar zijn en niet te veel extra tijd kosten. Als tip wil ik meegeven je zou eens naar bijvoorbeeld Code Complete van McConnell kunnen kijken of The Pragmatic programmer (beide boeken met zat praktisch bruikbare dingen)

Extreme programming is cool, maar ik zie dat hier niet zo snel werken ivm naar mijn mening vrijheden.

Zou je dit nader kunnen toelichten want ik zie weinig beperking van vrijheden in deze methode.

[Alarmnummer]

Ik zou kijken naar Agile in het algemeen (waar XP, Rup, Scrum etc ook onder vallen) en kijken welke practices je het beste toe kunt passen.

Paar practices die wel erg prettig zijn:
-unittesting
-continuous integration
-continuous feedback
-werken in iteraties

[mOrPhie]

RUP hoeft helemaal niet zwaar te zijn, zolang je maar definieert (dus onderkent en documenteert!) wat je wel en wat je niet van RUP gebruikt. Een persoon kan bijvoorbeeld best 2 rollen hebben binnen rup, waar je vervolgens 1 rol van maakt. Let wel even op "kiss of death" problemen; rollen waarbij belangenverstrengeling optreedt, zoals (bijvoorbeeld en niet perse RUP-rollen) de Product Manager en een Architect. Dat moeten echt 2 verschillende mensen zijn. Lang verhaal kort: in een team van 8 mensen kun je prima RUP invoeren.

Je hoeft je niet vanaf dag 1 te houden aan de volledige standaard. In een lerende organisatie is het vrij normaal dat je selectief gebruik maakt van verschillende principes van verschillende methodes. Hier gaan soms jaren overheen. De meeste organisaties komen dan meestal op een eigen implementatie van een methode uit. Je moet immers altijd in je achterhoofd houden dat je met een methode een probleem wilt oplossen. De methode is een toolbox, een middel. Niet een doel an sich.

Als laatste opmerking: RUP is een rational versie van UP, maar ze komen in grote lijnen op hetzelfde neer. Het betekent echter niet dat als je RUP gebruikt, je direct aan UML vast zit. Je kunt heel goed RUP gebruiken en vervolgens Scenario's schrijven in plaats van Use Cases, bijvoorbeeld.

[4of9]

Wij gaan zelf op het werk scrum gebruiken. Dit lijkt echter erg veel op DSDM (als het daar al niet van afgeleid is). Ik heb zelf ook een cursus RUP gedaan. Ik vond RUP nogal uitgebreid,

Maar DSDM is toch wel de methode die mij het meeste aanspreekt.
RAD is volgens mij een minder gestructureerde vorm van SCRUM/DSDM/RUP.
Waar RAD helemaal niets voorschrijft, heeft DSDM bijvoorbeeld toch wat meer voorschriften (documenten, producten) wat dan weer minder is dan in SDM.

Sinds ik iteratief ontwikkel kan ik me niet meer voorstellen hoe het was toen ik nog via SDM ontwikkelde. Welke iteratieve methode je pakt hangt sterk af van het soort software dat je gaat ontwikkelen, en of de methode geschikt is voor je team/organisatie/product etc.

DSDM bijvoorbeeld heeft een checklist om te kijken of DSDM geschikt is voor je project.

[gassiepaart]

Ontwikkeltechnieken, modeleringstechnieken of projectbeheerseringsmethoden, je kan ze allemaal combineren tot iets bruikbaars. Kijk vooraal welke methode /techniek echt bruikbaar is en vooraal wat de toegevoegde waarde is. Kies vooral geen methode/techniek die documentatie oplevert zonder dat je daar wat mee doet.

Let er ook op dat je geen toestanden krijgt zoals PINO (Prince in name only)
In de meest gevallen is bij een kleine afdeling JBF (jan boeren fluitjes) nog altijd het meest toegepast.

[beany]

gassiepaart schreef op donderdag 29 maart 2007 @ 11:17:
In de meest gevallen is bij een kleine afdeling JBF (jan boeren fluitjes) nog altijd het meest toegepast.

En daar is in principe ook niet veel mis mee. Echter, het probleem ligt in het feit dat werknemers niet 40 jaar lang bij het zelfde bedrijf blijven werken(zoals mijn opa wel deed). Mensen wisselen tegenwoordig vaker van baan dan van ondergoed lijkt het wel. En tijdens zo'n wisseling gaat er kennis en informatie verloren.

Mijn ervaring is dat de strikte toepassing van een methodiek vaak belemmerend werkt. Pik de dingen eruit die van toepassing zijn op de situatie, en laat de rest achterwege. Ik heb het te vaak gezien dat er enorme hoeveelheden documentatie werd gegenereerd(wat enorm veel manuren kostte) en dat die documentatie vrij snel obsolete werd, en er tevens nooit wat mee werd gedaan. Dat is kapitaal vernietiging vind ik. Tijdens de implementatie van een methodiek is dit probleem het belangrijkste om zien te voorkomen!