Software tbv development

[general.failure]

Onze ontwikkelingen ontwerpen we via een min of meer zelf gedistilleerde mix van Software Requirment Specifications, Use Cases, detailed designs (allemaal word docs)

Het daadwerkelijke programmeren wordt via iterations gepland, en bijgehouden in spreadsheets

Voor de bugs gebruiken we TestTrack, een web based bug tracking program.
Ons team bestaat uit 15 personen, verdeeld over 2 lokaties (NL en India)

Tot nu toe is dit allemaal redelijk vrijblijvend en matig gestructureerd.
Ik weet dat er applicaties zijn als Rational Unified Process, die dit soort trajecten kunnen structureren.
Nu is RUP nogal huge, mijn vraag is eigenlijk: zijn er lichtere alternatieven, liefst GPL?

[Verwijderd]

RUP is een development proces. Hiermee structureer het software development proces. Er staat dus in welke activitieten er uitgevoerd moeten worden in welke volgorde, uit welke rollen uit development team bestaat, welke artifacts (zoals documenten en software) er opgeleverd moeten worden, etc.

RUP is een zoganaamd agile development process wat er eigenlijk op neer komt dat je iteratief werkt, veel aandacht besteedt aan testen en veel met de eind gebruiker overlegt. Ik vermoedt dat een agile methodiek wel past bij jullie organisatie.

Maar RUP is inderdaad nogal huge en lijkt me over the top voor een redelijk kleine organisatie zoals de jouwe. Wat dan beter zou kunnen werken is XP (eXtreme Programming www.extremeprogramming.org). Dit is meer lichtgewicht en beter (!).

Daarnaast heb je software nodig om het proces en development the ondersteunen zoals tools voor use cases, design, programmeren, etc. Op zich vind ik Word documenten prima voor dit doeleinde maar zorg er dan wel voor dat je documenten in een version control systeem stopt zoals Subversion. Zorg er daarnaast voor dat een standaard directory structuur hebt in dat version control systeem die bij ieder project hetzelfde is.
Je zou ook voor Rational tools of zoiets dergelijks kunnen kiezen maar dat is erg duur. GPL tools in die richting ken ik niet.

[Janoz]

Het grote nadeel van word documenten is dat ze zo enorm lastig in versie beheer op te slaan zijn. Natuurlijk kun je zel wel opslaan, maar dingen als mergen en diffs zijn niet te doen. Bij een vorige werkgever gebruikten we voor dergelijke documentatie gewoon latex. Werkte een stuk prettiger, zeker nadat er een fikse toolset opgebouwd was. Het invoeren van latex lukte trouwens alleen maar omdat het hoofd van de afdeling en ik al behoorlijk ervaren met latex waren en we het er op die manier redelijk doorheen wisten te drukken.

[Verwijderd]

Janoz, je hebt gelijk dat merges en diffs lastig zijn met Word, maar je kunt je in dit geval afvragen in hoeverre dat van belang is. Het ontwikkel team bevat maar 15 personen dus hoe groot is de kans dat er 2 of meer mensen aan hetzelfde document werken?

[kenneth]

Verwijderd schreef op vrijdag 15 december 2006 @ 11:23:
RUP is een zoganaamd agile development process wat er eigenlijk op neer komt dat je iteratief werkt,

RUP iteratief noemen is vloeken in de kerk he

Maar RUP is inderdaad nogal huge en lijkt me over the top voor een redelijk kleine organisatie zoals de jouwe. Wat dan beter zou kunnen werken is XP (eXtreme Programming www.extremeprogramming.org). Dit is meer lichtgewicht en beter (!).

XP beter in de absolute zin? Lijkt me nogal een flink statement.

Op zich vind ik Word documenten prima voor dit doeleinde maar zorg er dan wel voor dat je documenten in een version control systeem stopt zoals Subversion.

Word + versiebeheer is niet echt 'n gelukkig huwelijk, ivm diffs en merges. Plain text oid zou handiger zijn.

Hmm, dat zeggen anderen ook al En: kreeg ik LaTeX er hier maar doorheen

[ Voor 4% gewijzigd door kenneth op 15-12-2006 12:29 ]

[Janoz]

Verwijderd schreef op vrijdag 15 december 2006 @ 12:17:
Janoz, je hebt gelijk dat merges en diffs lastig zijn met Word, maar je kunt je in dit geval afvragen in hoeverre dat van belang is. Het ontwikkel team bevat maar 15 personen dus hoe groot is de kans dat er 2 of meer mensen aan hetzelfde document werken?

Met merges heb je misschien wel gelijk, maar zeker de diffs zijn erg handig. Gelukkig kun je in word zelf nog wel een dergelijke actie uithalen. Wij maken vaak diffs van verschillende versies van FO's. Kun je heel makkelijk zijn wat nu exact de veranderingen zijn tussen de verschillende versies en wat je dus voor de nieuwe versie moet implementeren.

---

Hier hebben ze zelfs een speciaal token. Alleen als je dat token hebt mag je aan het word document werken. Te vaak hebben ze gehad dat het document volledig corrupt raakte.

[ Voor 11% gewijzigd door Janoz op 15-12-2006 13:04 ]

[djc]

Janoz schreef op vrijdag 15 december 2006 @ 13:02:
Met merges heb je misschien wel gelijk, maar zeker de diffs zijn erg handig. Gelukkig kun je in word zelf nog wel een dergelijke actie uithalen. Wij maken vaak diffs van verschillende versies van FO's. Kun je heel makkelijk zijn wat nu exact de veranderingen zijn tussen de verschillende versies en wat je dus voor de nieuwe versie moet implementeren.

Word heeft volgens mij stiekem wel een soort ingebouwde diff-tool; weet niet precies hoe het werkt, maar ik weet vrij zeker dat het wel mogelijk is.

Verder ben ik een groot fan van Trac, een softwarepakketje dat ook een bug tracker bevat, maar daarnaast ook een wiki (kan je ook heel goed stukken docs in schrijven, geeft er ook gewoon diffs van) en integratie met versiebeheer (mits het een ondersteund systeem betreft -- bij voorkeur Subversion, maar Mercurial moet inmiddels ook redelijk werken). Is helemaal webbased.

[BertS]

Word heeft volgens mij stiekem wel een soort ingebouwde diff-tool; weet niet precies hoe het werkt, maar ik weet vrij zeker dat het wel mogelijk is.

offtopic:
DocV2.doc opslaan als DocV1.doc, terwijl DocV1.doc al bestaat. Dan krijg je mogelijkheden aangeboden voor merging/revisie van wijziging

[ Voor 4% gewijzigd door BertS op 15-12-2006 19:39 ]

[MSalters]

Stap 1 in een gestructureerd proces is niet het overboord zetten van tools en opeens andere tools invoeren, en dan hopen dat het opeens beter gaat. Dan maakt het niet uit of de tool RUP heet, Java of nog iets anders.

De echte eerste stap is goed in kaart brengen wat je nu gebruikt, en waar je (business!) problemen zitten. Als jij niet weet wat je probleem is, dan weten wij geen oplossing. "matig gestructureerd" is geen probleem; maar "vrijblijvend" zou wel op een probleem kunnen wijzen. Gebruiken alle mensen wel dezelfde tools, of werken ze langs elkaar heen? Dat laatste zou een business probleem zijn. Maar als er nu N tools naast erlkaar gebruikt worden, hoe moet tool N+1 dat oplossen?

[JeroenB]

Janoz schreef op vrijdag 15 december 2006 @ 11:28:
Het grote nadeel van word documenten is dat ze zo enorm lastig in versie beheer op te slaan zijn. Natuurlijk kun je zel wel opslaan, maar dingen als mergen en diffs zijn niet te doen.

Hoezo niet? Veel versiebeheerapplicaties supporten mergen en diffen met Word-documenten (bijv. ClearCase).

kenneth schreef op vrijdag 15 december 2006 @ 12:29:
RUP iteratief noemen is vloeken in de kerk he

Bedoel je omdat het niet zo is? Of omdat RUP en iteratief werken geen bal met elkaar te maken hebben? Want meestal doelen mensen die zoiets zeggen op het eerste, terwijl dat op een behoorlijke misvatting duidt mbt. wat RUP is.

[Verwijderd]

general.failure schreef op vrijdag 15 december 2006 @ 08:21:
Ons team bestaat uit 15 personen, verdeeld over 2 lokaties (NL en India)

Tot nu toe is dit allemaal redelijk vrijblijvend en matig gestructureerd.

'redelijk vrijblijvend' en 'matig gestructureerd' kan prima binnen een bedrijf met een klein ontwikkelteam, maar het stelt wel wat voorwaarden: je ontwikkelaars moeten hart voor "de zaak" hebben, en ze moeten weten wie hun klanten zijn en wat hun klanten willen. Ik werk al 9 jaar in zo'n type bedrijf.
Maar een paar jaar geleden hebben we ook serieus geprobeerd 3 ontwikkelaars in India aan 't team toe te voegen, maar daar zijn we na een jaar mee gestopt. Technisch gezien prima vakmensen, maar ze zeggen nooit 'nee', pas 2 dagen voor een deadline krijg je een IRC-berichtje als 'Your valued guidance would be greatly appreciated', oftewel, we gaan de deadline niet halen.

Bovendien heeft een ontwikkelaar in India geen dagelijks contact met de collega's die installatie, training en helpdesk doen. M.i. essentieel wanneer je een klein bedrijf 'redelijk vrijblijvend' wilt houden.

Al met al hebben we na een jaar het India-avontuur gestaakt, omdat 't binnen onze organisatie niet werkte. Het zou wel kunnen werken wanneer we de ontwikkeltrajecten veel stricter zouden regisseren, maar dan zou 't onze organisatie niet meer zijn.

[kenneth]

JeroenB schreef op vrijdag 15 december 2006 @ 23:07:
Bedoel je omdat het niet zo is? Of omdat RUP en iteratief werken geen bal met elkaar te maken hebben? Want meestal doelen mensen die zoiets zeggen op het eerste, terwijl dat op een behoorlijke misvatting duidt mbt. wat RUP is.

RUP probeert juist niet iteratief te zijn: eerder al een trechter, waar je heel breed en algemeen begint, en steeds meer (al ontwikkelend en pratend) gedetailleerder wordt (beginnend met de belangrijkste use cases van het aanstaande systeem).

/kortdoordebocht

[Refro]

Binnen onze organisatie werkt het op eenzelfde manier (redelijk vrijblijvend en matig gestructureerd) en ook wij hebben een 16 man in NL zitten en dan nog 2 in de USA. Er is hier een paar jaar geleden geprobeerd om in een keer de omslag van de huidige structuur naar Rational Rose (UML) te maken. En je kan het al raden dat is vreselijk mislukt. Hiervoor zijn/waren een aantal redenen:

-Te weinig kennis van hoe ons ontwikkelprocess echt werkt
-Te weinig kennis van het nieuwe ontwikkel process
-De gekozen tools paste niet goed bij onze (embedded) omgeving
-Het was voor veel mensen een te grote stap

Nu zijn we nog steeds bezig met verbetering van ons process maar dit gaat heel langzaam. We willen richting Extreme programming en daar pakken we steeds een onderdeeltje uit. Dit wordt in een kleine groepje (3 a 4 man) getest en vervolgens met onze specifieke aanpassingen over de afdeling uitgerold. Dit process is nu al bijna 2 jaar bezig en zal nog zeker zo lang duren.

Maar het ertegenaan gooien van tools heeft geen zin als er geen duidelijk (op papier beschreven) process bestaat. Als je dat wel gaat doen zijn tools alleen maar een snellere manier om dezelfde (of zelfs meer) chaos te creeren.

Het meeste van specs, ontwerpen, pr/cr doen we in ms office het is niet ideaal maar beter als niets.

[OMX2000]

kenneth schreef op zaterdag 16 december 2006 @ 00:03:
[...]
RUP probeert juist niet iteratief te zijn: eerder al een trechter, waar je heel breed en algemeen begint, en steeds meer (al ontwikkelend en pratend) gedetailleerder wordt (beginnend met de belangrijkste use cases van het aanstaande systeem).

/kortdoordebocht

RUP is iteratief, dat de voortgang van het resultaat zich manifesteert in een trechter is heel wat anders. De "driver" is iteratief. Om RUP Agile te noemen is in sommige kringen vloeken in de kerk. RUP kan Agile zijn, maar hoeft dat niet.

Breed beginnen is in mijn ogen een vage term? Breed in de zin van functionele specificaties, of technische? Of bedoel je met breed een globale schets van het geheel, in de vorm van een use case model wat een overall plaatje schetst van de gewenste functionaliteit. Architectonische of functioneel risicovolle use cases pak je het eerst aan. Dus als je bijv. voor het eerst gebruik maakt van webservices en dus geen ervaring ermee hebt, is het slim om functionaliteit die op webservices gebaseerd is als eerste te doen.

Ik geloof zelf niet zo erg in strikte processen die van hoger hand opgelegd worden (en hoger hand is ook de projectleider). Als je geen ervaring hebt met Agile werkwijzen is het meestal handig om iemand in te schakelen die je op weg helpt. En in eerste instantie een soort van richtlijn voor je neerzet. Je zult gaandeweg deze werkwijze finetunen zodat dit je eigen ontwikkelproces wordt.

Ik zou als eerste gaan naar Manifesto for Agile Software Development

En op deze site vind je bakken vol informatie, check zeker de article library: http://www.agilealliance.org/