Thursday, February 14, 2008

Iteratief Ontwikkelen (RUP)

Zelf ben ik er nog niet helemaal over uit.

Is RUP nu een hype of wordt het inmiddels echt op veel plaatsen gebruikt en (succesvol) toegepast?

De (Software Architect) vacatures staan er in iedergeval vol mee.
Of RUP nu een hype is of niet, de principes die eraan te grondslag liggen lijken behoorlijk aan te slaan in de markt en in belangrijke bijdrage te leveren aan het slagen van steeds meer IT projecten.

Een van deze principes is "Iteratief ontwikkelen is nodig om tot een uitstekende bedrijfsoplossing te komen." (Vrije vertaling van principe nummer 5 uit DSDM).

Wanneer je dit principe uit haar context haalt zou je kunnen denken dat alleen de iteratieve ontwikkeltrajecten uitstekend worden gedaan maar dat is natuurlijk niet zo. Iteratief ontwikkelen is een oplossing voor het omgaan met onzekerheid. En slechts bij een specifiek soort projecten is iteratieviteit de oplossing om met onzekerheid om te gaan, namelijk:

  • Projecten waarbij resultaatgerichtwerken centraal staat: dus waarbij de opdrachtgever zeer tevreden is wanneer de belangrijkste 80% van de totale functionaliteit binnen tijd en budget ontwikkeld is;
  • Het projectteam wordt beschouwd als een zelfsturendteam van specialisten met bijbehorende beslissingsbevoegdheid;
  • Er geen sprake is van een politiekwespennest dus er is een open en positieve sfeer;
    Tussen de opdrachtgever, toekomstige eindgebruikers en het projectteam kan van dag tot dag informeel en open manier worden samengewerkt;
  • Er moet een oplossing worden ontwikkeld die direct een bedrijfsproces ondersteund (en is dan dus geen sprake van een technische oplossing die slechts indirect het bedrijfsproces ondersteund denk aan technische componenten)
  • Projecten waarvan duidelijk is, om welke reden dan ook, dat van te voren niet alles 100% kan worden bepaald maar door voortschreidend inzicht (en verwachtte veranderingen in de wereld om ons heen gedurende de uitvoering van het project) naar mate het project vordert alles steeds duidelijker zal worden.


Voordelen
Voor mij zijn de belangrijkste voordelen van het iteratief ontwikkelen:

  • Doordat een project wordt opgedeeld in velen miniprojecten wordt er veel effectiever gewerkt: er is minder sprake van stilstaan aan het begin en hollen aan het einde. Het succesvol afronden van enkele van deze miniprojecten kan zorgen voor een echte winnaarsgevoel.
  • Wanneer juist toegepast is er altijd sprake van een bruikbaar eindresultaat dat een groot deel van de belangrijkste doelstellingen realiseert.


De 9 DSDM Principes (bron wikipedia):

  • User involvement is the main key in running an efficient and effective project, where both users and developers share a workplace, so that the decisions can be made accurately.
  • The project team must be empowered to make decisions that are important to the progress of the project, without waiting for higher-level approval.
  • A focus on frequent delivery of products, with assumption that to deliver something "good enough" earlier is always better than to deliver everything "perfectly" in the end. By delivering product frequently from an early stage of the project, the product can be tested and reviewed where the test record and review document can be taken into account at the next iteration or phase.
  • The main criteria for acceptance of a "deliverable is delivering a system that addresses the current business needs. Delivering a perfect system which addresses all possible business needs is less important that focusing on critical functionalities.
  • Development is iterative and incremental, driven by users' feedback to converge on an effective business solution.
  • All changes during the development are reversible.
  • The high level scope and requirements should be base-lined before the project starts.
  • Testing is carried out throughout the project life-cycle. (See Test-driven development for comparison).
  • Communication and cooperation among all project stakeholders is required to be efficient and effective.

Sunday, February 3, 2008

Persoonlijke kenmerken van een architect

Wanneer men architecten in de praktijk vraagt naar de gewenste architectcompetenties, dan noemt hij of zij meestal persoonskenmerken. In de psychologie worden persoonlijkheidskenmerken in vijf groepen verdeeld, die bekend staan als de Big Five factorstructuur (Goldberg. “An Alternative "Description of Personality": The Big-Five Factor Structure”. Journal of Personality and Social Psychology 1990).

Classificeren we de meest genoemde persoonlijkheidskenmerken in deze big five, dan ontstaat het volgende beeld.

1. Extravertie.
• Communicatief
• Initatiefrijk

2. Aangenaamheid
• Teamplayer
• Empatisch (andermans standpunt kunnen invoelen)
• Luistervaardig

3. Betrouwbaarheid.
• Analytisch
• Georganiseerd, systematisch en ordelijk
• Besluitvaardig
• Resultaatgericht

4. Emotionele stabiliteit
• Zelfstandig

5. Intellect (reflectie).
• Creatief /innovatief
• Abstractievermogen
• Zichzelf blijven ontwikkelen

Deze lijst bevat alleen kenmerken die meerdere keren genoemd zijn. De volledige lijst is veel langer. Maar de lijst is al lang genoeg om ons af te vragen welke architect dat toch is die al deze eigenschappen heeft. Ik ken in elk geval niemand die ze allemaal heeft. Wel kan ik enkele herkenbare types architecten uit deze lijst afleiden. Twee contrasterende architecten die sommige, maar niet alle van deze persoonskenmerken hebben, zijn:

• De masculiene architect: resultaatgericht, besluitvaardig, met overtuigingskracht;
• De feminiene architect: een sensitieve teamplayer die goed luistert.

Twee andere types zijn die van de artiest versus de boekhouder:
• Artiest: Iemand die op hoog abstractieniveau creatieve oplossingen voorstelt;
• Analyticus: Iemand die nauwgezet en systematisch problemen analyseert en
oplossingen uitwerkt.

Bron: competenties van ict architecten (utwente)