- Top Development -

- a better solution for software development -

Version 1.26, Copyright (c) Harald Sørbu.

You are free to use, copy, distribute and transmit the work.

License at http://creativecommons.org/licenses/by-nd/3.0/

Summary (English)

"Top Development" is an iterative project method that can be used in small project with only a few project members or by large projects with several hundreds of project members. It's primary use is for information technology projects, but it can also be used for other types of projects where worktime are the main cost. The project method can greatly reduce costs when developing apps for iOS (iPad, iPhone), Android and Windows mobile.

The method emphasizes planning in the beginning of the project period in combination with iterative development. In addition it has focus on the systems infrastructure before implementing the functional requirements. When the infrastructure is in place, the project is "Over the Top", - that is why the method is called "Top Development".

To avoid bad choices of technology, frameworks etc., it uses "Throw'n go" at every review after an iteration. It is best for the final system to throw away bad elements as early as possible during a projects lifetime.

You are free to make commercial use of this project method.

Click this link to translate the rest of the document from Norwegian to English: http://translate.google.com/translate?u=http://www.fibon.com/top-development&hl=en&ie=UTF-8&sl=no&tl=en

1 Introduction

"Top Development" er en iterativ prosjektmetode som kan benyttes i små prosjekter med bare noen få deltakere til store prosjekter med over flere hundre deltakere. Den er primært beregnet for IT-prosjekter, men kan også benyttes med suksess for andre former for prosjekter der timekostnader er den største utgiften.

Metoden vektlegger få til en god planlegging i starten av prosjektperioden samtidig som prosjektgjennomføringen er iterativt. I tillegg vektlegges det å få plass en grunnleggende infrastruktur før implementering av funksjonelle krav. Når hoveddelen av infrastrukturene er på plass, er prosjektet "Over the Top", derav navnet "Top Development".

Fokuset er også på å unngå at feil valg tidlig i prosjektet får lov til å bli med videre i senere iterasjoner. Dette kalles "Throw'n go" og oppfordrer til å kaste ut teknologier, rammeverk osv. fra prosjektet som ikke viser seg å fungere tilfredsstillende.

2 Why

De mange budsjettoverskridelsene i IT-prosjekter gir en indikasjon på at tidligere brukte prosjektmetoder ikke har vært tilfredsstillende. Mange har prøvd både fossefallsmetoden, spiralmetoden, agile methods (Scrum) etc. uten å lykkes.

"Top Development" er basert på årevise erfaringer og er en prosjektmetode som øker sannsynligheten for å få IT-baserte prosjekter til å levere riktig funksjonalitet innenfor fastsatte kostnadsrammer og risiko.

3 Project flow

"Top Development" is a project method where the content and implementation of each iteration follows a defined project flow.

Hver iterasjon begynner med en planleggingsfase. I denne fasen planlegges omfang, aktiviteter, roller, personer, ariktetur, funksjonelle krav osv. Når innholdet i forestående iterasjon er definert, begynner en med fasene design, så utvikling og til slutt test. Selv om fasene er sekvensielle, vil det likevel være parallelle aktiviteter. Eks. testingen kan føre til at designet må endres.

Til slutt utføres en "review" av iterasjonen. Her der det viktig å kartlegge hva som ikke fungerte (eventuelt fjernes fra prosjektet) og hva en tar med seg videre til neste iterasjon.

4 "Throw'n go"

Den største kostnaden for nesten alle typer prosjekter er timekostnader for deltakere i prosjektet og ikke materielle kostnader. Ved å benytte seg av en iterativ fremgangsmåte i prosjektet, får en kontinuerlig tilbakemelding på hva som bør endres og kan justere kursen deretter.

Problemet med andre prosjektmetoder er at kursen likevel nesten ikke blir justert slik at en fortsetter omtrent med det samme som tidligere, - selv om en burde ha foretatt drastiske endringer. Det medfører at et meget stort antall prosjekttimer går med til å implementere en dårligere løsning pga. dårlige valg tidlig i prosjektet.

Top Development" reduserer denne risikoen ved bruk av "Throw'n go". Ved hver "review" av en iterasjon, skal en ha en kritisk gjennomgang av prosjektet. Målet er å kvitte seg med mest mulig som ikke fungerte i iterasjonen. Hvis det viser seg at eksempelvis valgt rammeverk for brukergrensesnitt ikke er modent nok, skal en kvitte seg med dette og prøve å finne en erstatter for neste iterasjon. Hvis valgt databasedesign ikke er godt nok, skal en kaste det som er dårlig og lage et bedre i neste iterasjon.

Det er aldri for sent å kaste ut noe som ikke fungerer i prosjektet. En må heller ikke la seg avskrekke av eventuelle implikasjoner av fjerningen. En dårlig valgt løsning må uansette fjernes. Ved å gjøre dette så tidlig så mulig, vil langtidskostnadene for systemet bli betraktlig redusert.

5 "Over the Top"

"Are you over the Top?" This is a critical moment for the project.

Innholdet i iterasjonene endrer seg kontinuerlig i prosjektet. I starten er det fokus på planlegging, deretter på infrastruktur og til slutt implementering av funksjonelle krav. Antallet iterasjonen kan endre seg i løpet av prosjektperioden.

Metoden vektlegger få til en god planlegging i starten av prosjektperioden samtidig som prosjektgjennomføringen er iterativt. I tillegg vektlegges det å få plass en grunnleggende infrastruktur før implementering av funksjonelle krav.

Prosjektet er over en meget kritisk fase når det meste av planleggingen er ferdig samtidig som den grunnleggende infrastrukturen er på plass. Dette kalles for punktet "Over the Top". De resterende iterasjonene skal nå implementere funksjonelle krav samt kun justere underliggende infrastruktur.

"Planning":

Projectplanning, Costs, Risks, Iterations, Persons, Roles, Architecture, Functional requirements etc.

"Infrastructure":

Installing products, implementing architecture, testing technology, establish frameworks, establish development environment, environment for testing

"Functionality":

Implement functionality, detailed functional requirements

6 Organizing

Organisasjonskartet viser hvilke personer som innehar prosjektets ulike roller. I tillegg oppgis det hvor mange prosent hver enkelt kan bidra i prosjektet. Noen vil bidra fulltid (100%) mens andre kanskje deltar i flere prosjekter samtidig og får dermed en lavere prosjektdeltakelse (Eks. 30%). En fører også opp om deltakeren er intern eller ekstern (Eks. Konsulent).

6.1 Roles

6.1.1 Steering committee

Denne gruppen skal hjelpe prosjektleder med organisatoriske utfordringer som oppstår. Det kan være å fremskaffe mer penger til prosjektet eller å allokere ressurser på tvers i organisasjonen(IT-kompetanse, forretningssiden). Prosjekteier bør være leder for denne gruppen.

• Project owner (money)

• Directors for different divisions (allocation of people)

• Projectleader

6.1.2 Project leader

Ansvarlig for den daglige ledelsen av prosjektet. Det innebærer å planlegge prosjektet, lede prosjektdeltakere samt rapportere til styringsgruppen. For store prosjekter kan det være hensiktsmessig å ha to prosjektledere der den ene har et teknisk fokus mens den andre har et administrativt fokus.

Det skal alltid være en intern ansatt som har selve prosjektansvaret.

6.1.3 Project members

Sammensetningen av prosjektdeltakere avhenger av type prosjekt som skal gjennomføres. Viktig at arbeidsområdet for hver rolle er klart definert. En person kan innha flere roller. Når en ekstern har en rolle, er det viktig at selve ansvaret for oppgaven likevel tildeles en intern deltaker selv om den interne ikke utfører oppgaven.

Examples:

• Architect

• Developers

• Functional architect

• Tester

• Q&A

• etc.

6.2 Meetings

Møter holdes ved behov:

• Statusmeeting for the steering committee every end of a review

• Statusmeeting once a week for the whole project (usually friday)

• One meeting with core project members once a week (usually tuesday)

• Any numbers of work-meetings between project members during the week

It is important that the meeting has a common structure every time.

• Agenda

• Discussions

• Conclusions

Det bør lages referat fra viktige møter.

Eksempel:

Statusmøte 2 Tilstede: Navn #1, Navn#2 Sak 1: Tekst om saken Konklusjon: Må gjøre dette Ansvar: Navn #1 Frist: 01.01.01 Sak 2: ...

7 Business requirements

7.1 Project Vision

Prosjekter er satt sammen av mennesker med forskjellige kvalifikasjoner og egenskaper. Eksempelvis kan alder på deltakerne variere med flere titalls år, det kan være kulturelle forskjeller samt at personer med helt forskjellig utdannelse må samarbeide. Det er derfor viktig at en definerer en felles prosjektvisjon for å få alle i prosjektet til å ha en overordnet retning og plan for prosjektet.

Example:

• "Our common goal is to solve the functional requirements at a high quality"

7.2 Project business goals

Just use plain sentences to define the business goals:

Example:

• Total of 1000 new customer before next year

• Possible to use e-mail instead of regular mail

8 Tasks list

Hovedprinsippet er å bryte ned alle aktiviteter til de tar mellom 1 og 10 timer å gjennomføre. Det er viktig å understreke at å gjennomføre betyr her å gjøre selve oppgaven, -eks. tiden det tar å programmere akkurat dette spesielle skjermbildet. Tiden det tar å planlegge, designe, teste osv. skal ikke tas med her. Timene for dette regnes ut når en estimerer totaltiden for iterasjonen.

Aktivitetene blir deretter kvantifisert ("Quantity"). I tillegg settes vanskelighetsgrad på oppgaven ("Easy", "Medium", "Hard").

Det overordnede innholdet i hver iterasjon bestemmes av om prosjektet er "Over the Top" eller ikke. Aktiviteter før toppen har hovedfokus på planlegging og infrastruktur. Senere blir fokuset mer på implementering av funksjonelle krav.

Tabellen innholder i tillegg navn på hver aktivitet, person som tiltenkt oppgaven samt en detaljert beskrivelse. Summen av timer for alle aktivitetene benyttes for å estimere omfanget av iterasjonen.

For å kunne estimere hele prosjektet, skal en så godt det lar seg gjøre finne aktiviteter for alle iterasjonene i prosjektet. Ved hver "review" oppdateres aktivitetstabellen for alle iterasjonene.

9 Estimate project

Summen av timer for aktivitetene er utgangspunktet for estimering av hver iterasjon samt av estimering av hele prosjektet. Dette timeantallet settes inn inn i linjen for "Develop", - tilsvarende 100%. Timeantallet for fasene "Planning", "Design" osv. er en prosentandel av antall utviklingstimer ("Develop").

Example:

Utviklingstiden for "Iteration 2" er 210 timer. For å finne antall timer som går med til design, regner en ut hva 50% av 210 timer er. I dette tilfellet er det 105 timer.

Prosentandelene oppgitt i tabellen er et utgangspunkt. Etter hvert vil erfaringsdata fra tidligere prosjekter og iterasjoner gi informasjon om hva som er korrekte prosentfordelinger i din organisasjon.

Totalsummen i denne tabellen er prosjektets totale omfang gitt i enheten timer.

10 Project reporting

Grafen viser hvor god kontroll en har på prosjektet. Målet er at estimert antall timer skal være likt antall brukte timer for hver iterasjon. Store avvik indikerer at risikoen har økt i prosjektet og at en må bli bedre på kartlegge omfanget av hver iterasjon.

Her ser en at estimatet ved iterasjon 3 bommet med ca 40%. Omfanget for neste iterasjon bør derfor reduseres noe.

11 Responsibilitytable

Det er meget viktig at prosjektdeltakerne har klart definerte ansvarsområder. Dette bidrar til klare avhengigheter mellom ulike oppgaver, og er med å drive prosjektet fremover. Eksterne deltakere kan kun ha ansvaret for utførelsen av en oppgave. Det vil alltid være en intern deltaker som har det endelig ansvaret for enhver oppgave.

Name	Area	Internal responsibility
Name #1	Responsible for database	Name #
Name #2	Responsible for functional requirements	Name #

12 Risk-management

Tabellen viser hva slags risiko som kan oppstå samt hvilke tiltak som kan settes inn. Laveste verdi er 1 mens høyeste verdi er 25. Verdier mellom 6 og 12 indikerer middels risiko. Alt over 12 betyr høy risiko.

Etter hver "review" skal risikotabellen for prosjektet oppdateres.

Formula: Probability * Consequence = Risk

Probability-/Consequence-values:

1. Very small

2. Small

3. Medium

4. Large

5. Very large

What	Probability	Consequence	Risk	To do
Participation from internal project members are lower than expected	3	2	6	Use external project members
			15
			3