[Alg] Agile development

[-FoX-]

Te vaak wordt ik nog geconfronteerd met onprofessionele omgang in software ontwikkeling. Dikwijls ligt dit niet bij de projectleiding, maar eerder bij de mentaliteit van de developer.

Waarom het op die manier doen, zo kan het toch ook perfect?

Idd, dat 'werkt' ook ja.. maar het ziet er niet lekker uit en gaat gegarandeerd tot problemen leveren. En dan wordt er verder gewoon maar wat aangemodderd, beetje bugfixing en klaar.. het 'werkt'.

Nu ga ik niet lopen verkondingen dat agile ontwikkeling hier iets aan zal verbeteren. Je zou misschien zelfs zeggen: "Ja, dat is toch agile... het 'werkt' op de simpelste en kortste manier". Maar die definitie is niet helemaal correct. Agile is veel meer dan dat en streeft daarenboven naar een hogere software kwaliteit. Denk maar aan unit/regression/acceptance testing, TDD, design in de code ipv in zware documenten, ... zijn maar enkele facetten die bijdragen tot een hogere kwaliteit.

agi·le (bw.): [soft.] snel, flexibel en met gemak kunnen inspelen op verandering.
Dit is eigenlijk een korte definitie van agile development; natuurlijk is er veel meer dan dat.

Agile is een erg praktijk gebaseerd proces gedefinieerd naar bewezen waarden en princiepen van software ontwikkeling. Het richt zich vooral op het doeltreffend werken en onnodige zaken achterwege laten. Nu wordt agile vaak ook wel eens als een proces gezien, dit is niet helemaal zo. Het is een deel proces, die zich wel laat inpassen in overige software processen zoals xp, fdd, dsdm, rup, ...

Agile development streeft ernaar om dingen eenvoudig te houden, onnodige complexiteit is vaak niet nodig. Nutteloos toepassen van design patterns is hier een voorbeeld van. Het is niet de bedoeling dat patterns op voorhand ingewerkt worden, het is beter om er pas naar toe te refactoren als de oplossing voor het probleem duidelijk wordt.

Verder is het ook nodig dat er ontzettend goed en snel ingespeeld kan worden op verandering. Veranderende requirements zijn de realiteit en iedereen (in software ontwikkeling) heeft ermee te maken. Hier zijn een aantal methoden voor, zoals agile requirement management: de requirements worden op een 'stack' geplaatst, samen met een prioriteit die toegekend wordt door de klant.

Modelleer en documenteer met een doel en naar een lezer. Het mag niet de bedoeling zijn om te gaan modelleren omdat het zo hoort; is ineffectief, beperkt het overzicht en kost daarenboven ook nog eens een hoop geld.

De nr1. prioriteit van iedere developer zou namelijk het effectieve ontwikkelen moeten zijn.

Bij agile model driven development wordt er in zeer kleine cycles gewerkt, maar wordt de programmeur wel gedwongen om eerst goed over de opzet na te denken; model/brain storming.

De intiële cycle (meestal een paar dagen) dient om de globale architectuur te doordenken, opzet van het gehele systeem, appserver, database, multi-tier, netwerk, ..
Dan volgt de volledige development stage; Er wordt per user story een korte sessie gehouden van een aantal minuten (5 à 10), waar deze story in het kort gemodelleerd wordt (vaak op een whiteboard) zodat deze gedefinieerd wordt als model. Na deze model storm sessie, wordt er overgaan in het effectieve coderen, liefst nog TDD zodat we onze codebase kunnen voorzien van regressie/unit testen. Op deze manier proberen we dan althans de software kwaliteit naar boven te krikken. Er wordt minder tijd verprutst aan onnodige details, er wordt meer tijd in de code gestopt.

Is agile een oplossing? Ik weet het eerlijk gezegd niet.. op lange termijn misschien. Wat zijn jullie ervaringen? Hoe gaan jullie op een hoog niveau om met software processen?

[Varienaja]

Ik werk op dit moment aan een project volgens de dsdm-methode. Ook daarbij maak je een lijst van "todo's", met een prioriteits-aanduiding. Het idee is dat je op deze manier altijd een werkend stuk software hebt; alleen de mate van 'afheid' varieert. Dat wil dus zeggen dat je op ieder moment in de ontwikkelfase een werkende release kunt maken. Met name de managers binnen ons bedrijf spreekt dat natuurlijk erg aan.

In de praktijk blijkt toch dat je eerst een flinke aanloopperiode nodig hebt waarin helemaal geen zichtbare ontwikkeling plaatsvindt. Het bedenken van een objectmodel en datamodel, het opzetten van je business-logica met unittests, etc. etc. Dat is allemaal niet zichtbaar van buitenaf.

Ook komt het weleens voor dat een nieuw item uit de todo-lijst een grotere impact heeft op je ontwerp dan je van tevoren verwachtte. Dat kan tot gevolg hebben dat je dermate diep aan het refactoren slaat dat je soms wekenlang je applicatie ubehaupt niet op kunt starten.

Het grootste probleem in mijn optiek bij software ontwikkeling is altijd dat de managers twee conflicterende eisen stellen, namelijk 1) korte ontwikkelperiode 2) een hoge mate van kwaliteit, uitbreidbaarheid en robuustheid.
Je kunt nog zo'n leuke ontwikkelmethode toepassen, maar als je als ontwikkelaar zijnde niet genoeg tijd krijgt zal het eindresultaat altijd teleurstellen.

[Grijze Vos]

Dit verhaaltje geeft mij heel erg de indruk dat dit lijkt op Extreme Programming.

[kenneth]

XP is dan ook een agile methode

[Soultaker]

Grijze Vos schreef op maandag 30 januari 2006 @ 18:22:
Dit verhaaltje geeft mij heel erg de indruk dat dit lijkt op Extreme Programming.

Dit is precies waar ik ook aan dacht.

Kun je misschien uitleggen waarom het nuttig is om een extra term te introduceren voor een verzameling concepten die afzonderlijk al namen hebben en die ook al toegepast worden in doctrines zoals XP? I.m.o. zit de software-industrie namelijk niet zozeer te wachten op meer buzzwords en ontwikkelmodellen, maar vooral aan een werkomgeving waarin bekende technieken daadwerkelijk, goed uitgevoerd worden.

Of in andere woorden: waar wil je het over hebben in dit topic? (Had je de andere topics over ontwikkelmethoden al gevonden?)

[ Voor 10% gewijzigd door Soultaker op 30-01-2006 20:34 ]

[Michali]

XP volgt (of draagt bij aan) het zogenaamde Agile Manifesto. Ik weet alleen niet zeker welke van beide termen er nu eerder was. Wat ik wel weet is dat Agile geen nieuw buzzword is, maar al zeker een tijdje bestaat. XP valt er idd ook onder, maar niet alleen dat.

Eigenlijk gaat dat over enkele principes:

quote: http://agilemanifesto.org/principles.html

Principles behind the Agile Manifesto

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity--the art of maximizing the amount
of work not done--is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Als je naar die site kijkt zou je bijna denken dat het over een religie gaat oid echt te erg.

[ Voor 76% gewijzigd door Michali op 30-01-2006 21:13 ]

[Verwijderd]

Ik ben een voorstander van Agile ontwikkeling. Ik heb een artikel gelezen over zogeheten "Lean Programming" waarin veel van de Agile ideeen naar voren kwamen en vond het bijzonder interessant en inspirerend om te lezen: http://www.poppendieck.com/lean.htm

Overigens denk ik dat de ideologie wel sterk gedragen moet worden de organisatie, inclusief sales en upper management, en moet je klant ook willen meedenken en meewerken.

Verder is mijns inziens ook niet iedere developer geschik hiervoor, omdat veel ontwikkelaars niet open staan voor verandering en denken dat ze het altijd het beste weten. Je hebt daarom enkele sterke senior developers nodig die andere developers meetrekken in het proces. Daarnaast is het aanleren van Agile een moeilijk proces, omdat er voor veel developers enkele sterk tegen-intuitieve elementen in zitten.

[ Voor 55% gewijzigd door Verwijderd op 30-01-2006 21:46 ]

[Michali]

Ik ben ook zeker een voorstander. Heb er laatst veel over gelezen in het boek Agile Software Development (echt een aanrader trouwens), en daaruit werd wel duidelijk dat het een erg logische en goede manier van werken is. Zeer ontwikkelaar en (uiteindelijk) klant vriendelijke manier van werken denk ik.

[tijn]

Persoonlijk heb ik een goed gevoel bij de dingen die ten grondslag liggen aan de hele 'Agile' beweging. Het gaat erom dat je als team gewoon accepteert dat veranderingen in bijvoorbeeld requirements voor komen en dat je daarbij probeert om daar op de meest efficiente wijze mee om te gaan. Uiteindelijk is het doel hierbij dat zowel de klant als de ontwikkelende partij met een voldaan gevoel uit een traject te laten komen (oftewel, op een plezierige manier goede software maken).
Let wel dat alles staat of valt met de bereidheid van alle stakeholders om hierin mee te gaan. Vaak genoeg komt het voor dat ergens bij een partij iemand zijn kont tegen de krib gooit (want al jaren gewend aan een andere werkwijze) waardoor alsnog een project gefrustreerd kan worden.

[daank]

Yupz .. XP it is ...
en het werkt echt super ... gebruik het zelf sinds 4 maanden , en moet zeggen .. projecten gaan een stuk soepeler. ^_^

[-FoX-]

Soultaker schreef op maandag 30 januari 2006 @ 20:33:
Dit is precies waar ik ook aan dacht.

Kun je misschien uitleggen waarom het nuttig is om een extra term te introduceren voor een verzameling concepten die afzonderlijk al namen hebben en die ook al toegepast worden in doctrines zoals XP? I.m.o. zit de software-industrie namelijk niet zozeer te wachten op meer buzzwords en ontwikkelmodellen, maar vooral aan een werkomgeving waarin bekende technieken daadwerkelijk, goed uitgevoerd worden.

Of in andere woorden: waar wil je het over hebben in dit topic? (Had je de andere topics over ontwikkelmethoden al gevonden?)

Nee, Agile development is niet persé XP (of RUP, DSDM, FDD, ...); maar kan eerder gezien worden als een deel proces dat een hoeksteen vormt voor bijvoorbeeld XP. Maar het is ruimer dan dat en het mag ook zeker niet als proces gezien worden.

Eigenlijk is het heel simpel, agile (model driven) development richt zich op het ontwikkelen van software. Dat is hun primaire doel. Niet al hetgeen er bij komt kijken. Klanten actief betrekken, alles simpel houden, geen onnodige documenten schrijven of modellen maken. Een heel ad-hoc manier van aanpakken dus.

Ik had de andere topics van ontwikkelmethoden al gevonden ja, maar daar wordt het 'agile' gebeuren slechts vernoemd als hoeksteen. Hier wil ik me meer concenteren op de omgang met agile. De klant staat centraal en de klant beslist nog steeds; het merendeel ziet documentatie dan ook als een soort van houvast. Het lijkt alsof ze dan de touwtjes in handen hebben. Maar dit is imho de foute manier om hen te betrekken bij het development proces. Ze moeten actief meedenken en niet de papiertjes even nalezen en kijken of het er wel goed uit ziet.

Graag had ik meningen gehad over de werking hiervan in de praktijk. Hoe ben je gekomen tot het ontwikkelproces die je nu volgt en wat speelt hier allemaal mee? Waarom vind je de agile aanpak goed, waarom niet...

Hoe AM in het globaal proces past en verdere info vind je hier: http://www.agilemodeling.com/

[Cuball]

martin fowler heeft ook een boeiend artikel geschreven over agile methodologie:

http://www.martinfowler.com/articles/newMethodology.html

[whoami]

Eigenlijk is het heel simpel, agile (model driven) development

Is 'agile driven development' perse 'model driven development' en vice versa ?
Ik dacht het niet; ze zijn wel te combineren, maar het is niet hetzelfde.

Model driven development is een manier van ontwikkelen, waarbij de agile methodologie goed van pas komt. Agile development is eigenlijk 'wendbaar zijn'. Snel kunnen inspelen op veranderende requirements, je architectuur zo opstellen dat het voldoet aan de eisen van vandaag, maar geen rekening houden met 'eisen die wel eens in de toekomst zouden kunnen bestaan. Dat houdt niet in dat je geen 'uitbreidbare' architectuur moet hebben, maar wel dat je daar niet in moet overdrijven. Eén van de agile development bouwstenen is ook Testdriven development. De unit-tests die je hier schrijft, komen later ook van pas bij het refactoren of het uitbreiden van de bestaande functionaliteit. Mbhv die unit-tests kan je controleren of je 'oude' functionaliteit nog werkt.

Hier wil ik me meer concenteren op de omgang met agile. De klant staat centraal en de klant beslist nog steeds; het merendeel ziet documentatie dan ook als een soort van houvast. Het lijkt alsof ze dan de touwtjes in handen hebben. Maar dit is imho de foute manier om hen te betrekken bij het development proces. Ze moeten actief meedenken en niet de papiertjes even nalezen en kijken of het er wel goed uit ziet.

Idd.
Eén van de 'regels' is dan ook: do not write documentation untill it is really necessary
Dit wil zeggen dat je tijdens het development process beter geen documentatie schrijft, omdat je, als je later tijdens het ontwikkelprocess iets moet veranderen aan de code, de documentatie toch hoogstwaarschijnlijk niet zult aanpassen, waardoor die binnen de kortste keren out of sync is. Beter geen documentatie dus, dan slechte documentatie. (Ik heb het niet over comments binnen de code, maar externe documenten). Ik geloof dat het beter is om je documentatie (externe docs dus), pas te schrijven eens je een versie af hebt.

[ Voor 35% gewijzigd door whoami op 31-01-2006 09:01 ]

[-FoX-]

whoami schreef op dinsdag 31 januari 2006 @ 08:58:
Is 'agile driven development' perse 'model driven development' en vice versa ?
Ik dacht het niet; ze zijn wel te combineren, maar het is niet hetzelfde.

Nee, maar eigenlijk zou het zo wel moeten zijn. Het verschil is dat er iets meer gemodelleerd wordt op een agile manier alvorens de eigenlijke code te schrijven, en daar ben ik wel voor te vinden.
• stap 0: Aantal dagen voor het project begint; globale structuur en architectuur uitdenken + bediscussieren.
• stap 1(n): Model storming, slechts 5 à 10 minuten voordat de effectieve user story/use case/feature wordt uitgewerkt, wordt deze eerst geschetst. De globale structuur wordt gedefinieerd aan de hand van een klein model.
• stap 2(n): We gaan het model/user story implementeren a.d.h.v. code, liefst nog met de TDD (test driven development) aanpak. De details van het abstracte model worden hier dus geïmplementeerd en gedocumenteerd (door de unit test suite).
• stap 3(n): We komen vast te zitten of er treedt een bijkomend probleem op? We itereren terug naar stap 1(n).

Mijn inziens kan dit geen tijdverspilling zijn, maar zou het iedere keer opnieuw opgenomen moeten worden.

Idd.
Eén van de 'regels' is dan ook: do not write documentation untill it is really necessary
Dit wil zeggen dat je tijdens het development process beter geen documentatie schrijft, omdat je, als je later tijdens het ontwikkelprocess iets moet veranderen aan de code, de documentatie toch hoogstwaarschijnlijk niet zult aanpassen, waardoor die binnen de kortste keren out of sync is. Beter geen documentatie dus, dan slechte documentatie. (Ik heb het niet over comments binnen de code, maar externe documenten). Ik geloof dat het beter is om je documentatie (externe docs dus), pas te schrijven eens je een versie af hebt.

Hmm, niet helemaal. Documentatie mag enkel en alleen geschreven worden als deze ook effectief een doel heeft. Vaak kan dit ook gaan om de functionele specificaties met de gebruikers te doorspreken bij een fixed price project. Dan is het natuurlijk wel nodig om een globaal definitiepunt te definiëren. Het mag niet de bedoeling zijn om het requirements document een aantal maanden vooraf volledig uit te werken aangezien deze hoogstwaarschijnlijk voor een groot deel gewijzigd zullen worden.. hier dus wel een waste-of-time.

Verder zijn / zouden je unit-tests ook de ideale design documentatie moeten voorstellen. Documentatie in de code is ook documentatie!

[PowerFlower]

Interesting stuff. * PowerFlower heeft weer heel wat leesvoer. In de praktijk passen wij in feite al veel van dit soort dingen toe maar er is geen reden het wiel opnieuw uit te vinden. Zelf vind ik dat veel project/ontwikkelmethodieken nuttig zijn (en in de eerste fase vaak onontbeerlijk) maar je moet het dan heel erg pragmatisch toepassen (dat is eigenlijk waar voor zover ik zie dit ook op neerkomt). Bij ons kwam dat voort uit een frustratie met de standaard cycle van enorme papierstapels van quasi-goed georganiseerde (in feite overgeorganiseerde) projecten die een jaar duren, waarbij na de eerste fase van het verzamelen van requirements geen verandering meer mogelijk is aan de opzet en je dus uiteindelijk na een jaar iets hebt dat gebaseerd is op de theoretische requirements die inmiddels achterhaald zijn, niet blijken te kloppen, niemand tevreden maken (niet de klant, niet de ontwikkelaars) en dan begin je weer van voren af aan. Wat je uiteindelijk hebt is honderden pagina's projectdocumentatie en een "eindproduct" dat niet is wat nodig is en dat per definitie ook nooit zal worden.

whoami schreef op dinsdag 31 januari 2006 @ 08:58:
[...]
Idd.
Eén van de 'regels' is dan ook: do not write documentation untill it is really necessary
Dit wil zeggen dat je tijdens het development process beter geen documentatie schrijft, omdat je, als je later tijdens het ontwikkelprocess iets moet veranderen aan de code, de documentatie toch hoogstwaarschijnlijk niet zult aanpassen, waardoor die binnen de kortste keren out of sync is. Beter geen documentatie dus, dan slechte documentatie. (Ik heb het niet over comments binnen de code, maar externe documenten). Ik geloof dat het beter is om je documentatie (externe docs dus), pas te schrijven eens je een versie af hebt.

Wij hebben iemand neergezet die de documentatie continu bijwerkt naar de stand van zaken. Dat is wel redelijk tegen de stroom op roeien maar in ieder geval wordt het dan niet overgeslagen door deadlines en tijdgebrek Dat is natuurlijk niet ideaal maar we ontwikkelen momenteel zo rap door dat er anders gewoon níets is

[ Voor 4% gewijzigd door PowerFlower op 31-01-2006 12:18 ]

[Michali]

Maar het lijkt me wel dat je binnen de code altijd wel een stukje documentatie schrijft. Bij iedere functie en class etc. Dat blijft denk ik ook beter in sync, en meer heb je vaak ook niet nodig.

Voor de mensen die echt de Agile methodiek (voornamelijk XP denk ik) volgen. Hoe gaan jullie om met de richtlijn dat er altijd iemand (de klant of een representant) op locatie moet zijn, liefst werkend in hetzelfde kamer of gebouw? Wordt dat ook veel gedaan dan?

[ Voor 6% gewijzigd door Michali op 31-01-2006 14:27 ]

[-FoX-]

PowerFlower schreef op dinsdag 31 januari 2006 @ 12:14:
Wij hebben iemand neergezet die de documentatie continu bijwerkt naar de stand van zaken. Dat is wel redelijk tegen de stroom op roeien maar in ieder geval wordt het dan niet overgeslagen door deadlines en tijdgebrek Dat is natuurlijk niet ideaal maar we ontwikkelen momenteel zo rap door dat er anders gewoon níets is

Maar is het ook zinnig werk dat hij doet? Of werkt hij de documentatie maar gewoon bij om alles in-sync te houden? Want dat is imho een beetje onzinning.

Michali schreef op dinsdag 31 januari 2006 @ 14:26:
Maar het lijkt me wel dat je binnen de code altijd wel een stukje documentatie schrijft. Bij iedere functie en class etc. Dat blijft denk ik ook beter in sync, en meer heb je vaak ook niet nodig.

Binnen je code documentatie schrijven is natuurlijk wel handig, maar dat zijn enkel de specifieke implementatie details die hierin zouden moeten staan.
De globale class beschrijving geeft dan wel iets meer een overzicht over de class en zijn gebruik; maar gaat hier ook niet verder in. Documentatie schrijven blijft dus wel noodzakelijk, alleen mag dit niet te specifiek en te breed uitgewerkt worden.

Voor de mensen die echt de Agile methodiek (voornamelijk XP denk ik) volgen. Hoe gaan jullie om met de richtlijn dat er altijd iemand (de klant of een representant) op locatie moet zijn, liefst werkend in hetzelfde kamer of gebouw? Wordt dat ook veel gedaan dan?

Hier ben ik ook wel nieuwsgierig na. Op welke manier hier in de echte praktijk mee omgegaan wordt.

[PowerFlower]

-FoX- schreef op woensdag 01 februari 2006 @ 17:17:
[...]
Maar is het ook zinnig werk dat hij doet? Of werkt hij de documentatie maar gewoon bij om alles in-sync te houden? Want dat is imho een beetje onzinning.

Zoals ik al zei, het is niet ideaal, maar beter dan dat de devvers het tussendoor moeten doen

[Cuball]

als je wikipedia mag geloven:

Agile software development processes are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

en XP is een "best-known" agile process met wat me direct opvalt is dat er bij XP vanuit gegaan worden dat er EERST testen geschreven worden en dan pas effectief beginnen codekloppen.

Extreme Programming, XP, is the best-known agile process. In XP, the phases are carried out in extremely small (or "continuous") steps compared to the older, "batch" processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development.

op de duur weet ik het ook niet meer hoor, een totaal overzicht zou soms wel handig zijn :-)

meer te vinden op : http://en.wikipedia.org/wiki/Software_development_process

[whoami]

en XP is een "best-known" agile process met wat me direct opvalt is dat er bij XP vanuit gegaan worden dat er EERST testen geschreven worden en dan pas effectief beginnen codekloppen

Dat is gewoon Test Driven Development, en als ik het goed heb is dat één van de bouwstenen van agile development. Maw, alle agile stromingen zullen dit concept hebben.

[CubicQ]

Volgens mij niet alle Agile stromingen. In mijn DSDM boek vind ik niets over TDD, en ook wanneer ik naar de history bekijk denk ik dat DSDM (jaren 90) eerder is bedacht dan TDD (2000?).

[Verwijderd]

Agile Software Development methodes als XP is niet overal geschikt. Het werkt alleen als de projectteam klein is. Daarnaast is het een vereiste dat klanten ook aanwezig en beschikbaar zijn bij het ontwikkelen van software. En volgens mij is het dit niet altijd mogelijk. Als dit het geval is, is XP dan nog steeds geschikt? En hoe zit het met complexe projecten (bijvoorbeeld het ontwikkelen van een informatie systeem voor NASA voor het aansturen van een sateliet of zo?) is Agile Software Development team nog steeds geschikt (XP werkt namelijk met korte iteraties en hou het zo simpel mogelijk). En volgens mij is het bij zulke projecten wel noodzakelijk om meer onderzoek te verrichten en meer te documenteren.

Maar goed, Een aantal principes van Agile Software Development spreekt me zeker aan en kan denk ik ook toegepast worden binnen andere methodieken. Het schrijven van testen en dan pas coderen zie ik wel zitten. Maar ook het toepassen van refactoring spreekt me wel aan om gemakkelijk op veranderingen in te spelen.

Maar goed. Wat ik wel graag zal willen weten hoe het zit met documentatie (volgens agile software development principes zijn de source codes en human to human interactie de beste documentatie) en hoe het zit met het ontwerpen (door bijvoorbeeld gebruik te maken van UML) van verschillende diagramen voor het ontwikkelen van de informatie systeem? Ook wil ik graag weten hoe het in de praktijk gaat?

[cvs79]

offtopic:
Agile software methodiek is al weer achterhaald. In 2006 zal Waterfall2006 helemaal hot worden.

[ Voor 10% gewijzigd door cvs79 op 03-02-2006 08:31 ]

[staefke]

cvs79 schreef op vrijdag 03 februari 2006 @ 08:30:

offtopic:
Agile software methodiek is al weer achterhaald. In 2006 zal Waterfall2006 helemaal hot worden.

offtopic:
vooral die conference-datum is interessant. Wie gaat mee ?

[Cuball]

staefke schreef op vrijdag 03 februari 2006 @ 09:01:
[...]

offtopic:
vooral die conference-datum is interessant. Wie gaat mee ?

offtopic:
oei dringend tijd dat ik nog wat code refuctor :-)
leuk om te lezen !

[-FoX-]

Verwijderd schreef op vrijdag 03 februari 2006 @ 03:30:
Maar goed. Wat ik wel graag zal willen weten hoe het zit met documentatie (volgens agile software development principes zijn de source codes en human to human interactie de beste documentatie) en hoe het zit met het ontwerpen (door bijvoorbeeld gebruik te maken van UML) van verschillende diagramen voor het ontwikkelen van de informatie systeem? Ook wil ik graag weten hoe het in de praktijk gaat?

Niet helemaal waar. De source code/testen zijn de beste documentatie voor het systeem, het is dus m.a.w. niet nodig om deze beschrijvingen ook nog eens een externe documentatie op te nemen. De beste plaats om deze code te documenteren is in de code zelf.

UML is niet de key voor alle ontwerpen. Heb je al ooit zelf een use-case/sequence/class diagram gemaakt over de Java API (of een deel ervan zoals IO) zodat je ze beter zou begrijpen? Het probleem met UML is dat het veel kan, maar wat je je dan kan afvragen is: Waarom bestaat er geen UML diagram (vb use-case) die aantoont op welke wijze je UML nu moet gaan gebruiken? Het is dus niet voor alles geschikt..