[Alg] Software ontwikkelmethode voor Open-Source projecten

[Spider.007]

---

Software ontwikkelmethode voor Open-Source projecten

---

Open-Source projecten zijn doorgaans wezenlijk anders dan reguliere IT projecten die, in tegenstelling tot Open-Source, vaak commercieel van aard zijn. Reguliere IT projecten maken goed gebruik van de bestaande ontwikkelmethoden, deze ontwikkelmethoden zijn echter onbruikbaar voor Open-Source projecten.

Een storende factor in bijna alle methoden is de prominente rol die de klant in neemt. In de meeste Open-Source projecten is echter geen sprake van een klant. Het project wordt gestart door een enthousiaste groep ontwikkelaars die een applicatie willen bouwen. Wat ons betreft kan de klant daarom geheel verdwijnen uit de methode. Op de 3oProgramming website (http://www.3o.nl) bespreken we nog enkele andere belemmerende factoren in de bestaande methoden.

Bij het ontbreken van een degelijke ontwikkelmethode voor onze projecten hebben we zelf het initiatief genomen en een eerste versie van een methode geschreven, gedoopt 3oProgramming. Deze opzet is echter verre van voltooid. Het doel van deze eerste opzet is het aanzwengelen van de discussie omtrent een ontwikkel methode. We willen gedurende het komende jaar 3oProgramming, op basis van deze discussie, gaan bijschaven en perfectioneren.

Deze post is de eerste stap in die discussie. Deze post is niet bedoeld om een discussie aan te zwengelen omtrent het wel of niet nuttig zijn van een methode in het algemeen. In plaats daarvan willen we wetenwat er goed is aan onze opzet en wat niet. Wat er mist. Wat er teveel in staat. Welke methoden we gemist hebben in onze zoektocht een goede te vinden.

---

Concreet:

• Vinden jullie de ontworpen methode makkelijk te doorgronden? Ben je (of was je al?) overtuigd van het nut van een methode?
• Hanteren ontwikkelaars op GoT die überhaupt een methode bij projecten?

UbeS! | PACT | Spider.007

[ Voor 5% gewijzigd door Spider.007 op 28-10-2003 00:16 ]

[Rukapul]

Hmmm.. Is dit niet XP (extreme programming) met het 'core team' als customer

Kan niet zeggen dat ik de 'methodiek' erg vernieuwend vindt die op de website gepresenteerd wordt. Aangezien veel concepten op dit moment al gebruikt worden in open source projecten (muv de explicite stories en tasks wellicht) heeft het vast z'n nut

[ Voor 64% gewijzigd door Rukapul op 28-10-2003 00:01 ]

[Verwijderd]

Rukapul,

Het is inderdaad zo dat 3oP delen bevat die gelijk zijn aan XP met alleen een wezenlijk verschil dat er in de open-source community niet gesproken wordt over customers. Het is een closed loop met developers. Om dit geheel in goede banen te kunnen leiden is er enige vorm van standaardisatie nodig. Hierbij spelen de story cards en de task cards een belangrijke rol. Deze worden repectievelijk als functionele en technische documentatie cq beschrijvingen gebruikt voor de applicatie. Het core-team is verantwoordelijk voor het uitdragen van deze standaarden zo ook het open houden van de communicatielijnen tussen hunzelf en de developers binnen de rest van het team.

[Creepy]

Verwijderd schreef op 28 oktober 2003 @ 00:17:
Het is inderdaad zo dat 3oP delen bevat die gelijk zijn aan XP met alleen een wezenlijk verschil dat er in de open-source community niet gesproken wordt over customers.

Er zijn wel degelijk OpenSource produkten waarbij wel degelijk costumers zijn. Niet alle software doe voor een speciale klant wordt geschreven is niet automatisch closed source. Hier heb je dus totaal geen rekening mee gehouden? Of omdat jullie methode zoveel op XP lijkt, is het dan beter om XP te gebruiken i.p.v. jullie methode?

[mbravenboer]

Jullie hebben er duidelijk aardig wat werk en tijd in gestoken. Ik ben eigenlijk met name benieuwd naar de onderbouwing en achtergrond van jullie methode. Op de website kan ik hier niets over vinden.

Bij het presenteren van een nieuwe methodiek is het noodzakelijk om te beschrijven hoe deze ontstaan is uit concrete projecten waaraan er gewerkt is. Hoe kwamen jullie tot deze inzichten? Zijn jullie toen deze methode gaan toepassen in die projecten? Heeft dat de situatie in het project verbeterd? Hebben jullie concrete gegevens die het succes van de methode in die projecten duidelijk maakt?

offtopic:
Op de front-page staat een typo die veel gemaakt wordt: GNU Free Documentation Licence. Licence moet license zijn.

[mjax]

Ik denk dat een ontwikkelmethode zonder een vertegenwoordiging van klanten (oftewel eindgebruikers) gedoemd is om te mislukken. Een developer is nu eenmaal geen prototype eindgebruiker. Hoe weet het development team nu waar de eindgebruiker om vraagt of op te wachten zit?

Uiteindelijk ontwikkel je software om een bepaald probleem op te lossen: het ontwikkelen is geen doel op zich.

Als je bij aanvang van een project (al dan niet open-source) nog geen concrete eindgebruiker hebt, dan wordt een hoofdtaak het samenstellen van een gebruikersvertegenwoordiging. Ga op het net opzoek naar potentiele gebruikers en laat hen meedenken over de gewenste functionaliteiten.

Eveneens een belangrijke stap die overgeslagen wordt in deze methode, is een soort van acceptatietest (dus een test op gebruikersniveau). De enige testen die ik beschreven zie is een test door de developer zelf en een soort van integratietest.

[Verwijderd]

De klant wordt niet zozeer vervangen door het core team maar door de gebruikersgemeenschap. Gebruikers kunnen en zullen hun voorkeur uitspreken voor bepaalde wijzigingen. Die feedback wordt opgevangen en door het core team gefilterd. Er is dus wel een testmechanisme ingebouwd, de software wordt getest. op de website is dit nog niet duidelijk uitgewerkt maar het is al wel opgenomen. 3oP definieert zo juist rollen waar ze van nature liggen en past groepen en personen niet in rollen die toevallig binnen de methode passen.

Voor Open-source projecten die wel een opdrachtgever hebben als initiator of sponsor kan inderdaad beter XP gebruikt worden. Dergelijke projecten hebben we vooralsnog buiten de scope gelaten. In een later stadium kunnen dergelijke projecten nog altijd binnen de methode ingepast worden.

N.B. 3oP verkeert momenteel nog in een pril stadium en wat er nu staat is voornamelijk bedoeld om discussie aan te zwengelen.

[Spider.007]

Inmiddels wil ik dit topic toch een schopje verkopen aangezien het voor mij nog niet de waarde heeft die het zou kunnen hebben. Ook al hebben wij deze ontwikkeltechniek nog nooit in de praktijk uit kunnen proberen zouden we toch graag feedback ontvangen van wat ontwikkelaars op GoT. Maken jullie sowieso gebruik van een ontwikkelmethodiek, of programmeer je maar wat in het wilde weg? Zijn er hier ontwikkelaars van open-source programma's? Hoe pakken jullie een groot project aan?