organisatiepatronen

Geschiedenis

Hoewel organisatiepatronen al heel lang bestaan, gaat het concept van het patroon terug naar de architect Christopher Alexander . ^[2] [3] De ideeën van Alexander waren in de vroege jaren 1990 in de ontwikkeling van software vastgesteld en later uitgebreid naar organisaties. ^[1]

Organisatie Formulieren

Organisatieontwerppatroon

Projectmanagementpatroon

Gemeenschap van vertrouwen

De persoonlijke relaties tussen werknemers hebben een grote invloed op de effectiviteit van een team. Daarom is het belangrijk om een gemeenschap van vertrouwen op te bouwen ^[1] (Engels: community of trust ). Zonder vertrouwen tussen medewerkers is de communicatie beperkt en moeten workflows onafhankelijk worden afgehandeld, wat resulteert in meerdere inspanningen.

Om de gemeenschap te versterken, is het belangrijk om vertrouwen in anderen te tonen. Het beperken van toegang tot informatie of bureaucratische hindernissen voor workflows kan van invloed zijn op het vertrouwen. Daarom is het belangrijk om werknemers controle te geven over hun eigen workflows. Bovendien moeten werknemers het gevoel hebben dat ze invloed hebben op beslissingen, omdat ze de neiging hebben om de beslissingen van een beslissingsnemer te vertrouwen. Ook voelen de werknemers zich meer verplicht om de verantwoordelijkheid voor de toegewezen taken op zich te nemen. Dit is belangrijk omdat een andere persoon geen verantwoordelijkheid kan krijgen (ze kan alleen verantwoordelijk zijn voor haar daden be), maar de juiste persoon moet zelf de verantwoordelijkheid nemen.

Autorisatie

De machtiging ^[1] (Engels: empowerment ) geeft opzettelijk afstand van de controle over ondergeschikte werknemers. In tegenstelling tot de vertrouwensgemeenschap op basis van een (impliciete) bilaterale overeenkomst, is de machtiging unidirectioneel van een superieur orgaan. Aan de ene kant is het doel van de machtiging om de gemeenschap van vertrouwen op te bouwen en, aan de andere kant, om de hogere instanties te ontlasten door de bureaucratie te verminderen .

Beoordeling van de dienstregeling

Een schatting van het schema ^[1] (Engels: grootte van het schema ) wordt uitgevoerd wanneer het te maken product wordt begrepen en de projectgrootte kan worden geschat.

Zowel te smalle als te grote tijdschema’s zijn negatief. Te strakke schema’s zullen werknemers overbelasten en resulteren in het niet naleven van overeengekomen data of de levering van een inferieur product. Dit is ook van invloed op volgende organisatie-eenheden of de klant. Over-scale schema’s verhogen de kosten voor de klant door tijd te verspillen aan trivia. Beide leiden tot gemiste marktkansen.

Een versnelling van werkprocessen door het verhogen van het aantal werknemers is vaak het Brooks’sche wet en de wet van Amdahl tegen.

De medewerkers die aan het project werken, moeten werken aan de beoordeling van de projecttijd, vooral voor hun eigen werk. Goede beoordelingen kunnen worden beloond met financiële prikkels of extra vrije tijd ( zie ook: Compenseren van succes ). Daarnaast moeten twee tijdsschattingen worden gemaakt. Een intern rooster opgesteld in overleg met de werknemers, evenals een extern schema overeengekomen met de klant. Het externe schema voor een middelgroot project moet één tot twee weken of twee tot drie maanden boven het interne rooster liggen om eventuele overschrijdingen te kunnen onderscheppen.

Vergelijkbare Werk

Comparable Work ^[1] is een patroon gedefinieerd door Ward Cunningham als volgt:

Zie ook: Scrum .

Schiet op

Als je doorgaat met ^[1] of een gedeeltelijke evaluatie , is het project al gestart, hoewel nog niet alle vereisten duidelijk zijn . Bovendien zijn afhankelijkheden in detail vaak onvoorspelbaar en komen ze vaak pas aan het einde van een project naar boven. Zodra de richting van projectontwikkeling geschat kan worden, zou men moeten beginnen met de dingen die zeer zelfverzekerd zijn . In dit stadium kan al aan een informeel werkplan worden gewerkt en kunnen prototypes worden uitgewerkt. Tegelijkertijd geven de prototypen inzicht in hoe de structuur van het eindproduct eruit kan zien en kunnen stabiele basissen worden benoemd, Vaak worden vroege projecten uitgevoerd in de vorm van Skunk-werken . Deze kunnen het beste parallel aan andere bedrijfsprocessen worden uitgevoerd met ongebruikte bronnen.

Dit patroon leidt tot een versnelling van de voltooiing van het product. Omdat werk echter moet worden weggegooid vanwege veranderende eisen, moet dit patroon niet worden gebruikt als de middelen die nodig zijn voor de taak een bottleneck zijn waarvan andere processen ook afhankelijk zijn. Het vereist ook een goede communicatie met de daaropvolgende eenheden verantwoordelijkheden nemen en hal chatter .

Zie ook: Bouw prototypes .

Benoemde stabiele basen

Benoemde stabiele basen ^[1] zijn gedefinieerde interfaces tussen projectonderdelen. Deze zijn genoemd nadat het projectplan is gemaakt en de ontwikkeling van het product is gestart. Via de gedefinieerde interfaces krijgen de afzonderlijke teams een gemeenschappelijk begrip van het te ontwikkelen product en kunnen ze voortbouwen op een bepaald basisgedrag. De reeks gespecificeerde en benoemde interfaces moet regelmatig worden uitgebreid (bijvoorbeeld wekelijks).

De ontwikkeling van prototypen biedt een manier om een ​​reeks interfaces te definiëren.

Zie ook: prototypen bouwen , afleveringen programmeren .

Incrementele integratie

Met de incrementele integratie ^[1] [5] ( Engels: incrementele integratie ) worden de onderdelen van een te ontwikkelen product regelmatig samengesteld. Dit voorkomt grote integratieproblemen in de late ontwikkelingsfase van het product. De ontwikkelingsstatus wordt vastgelegd en wordt een nieuwe stabiele basis , waarop de verdere ontwikkeling van het product is gebaseerd.

Prive-wereld

Als een prive-wereld ^[1] [5] ( private wereld ) heet een werkomgeving op een individuele werknemer heeft alleen en biedt alle tools die nodig zijn voor de activiteiten van de werknemer.

Private werelden zijn vaak te vinden in de ontwikkeling van software, waarbij een programmeur in aanvulling op de ontwikkelomgeving en de compiler heeft ook een lokale momentopname van de te ontwikkelen software (d. E. A genaamd stabiele basis ) en de vereiste bibliotheken heeft de software op elk gewenst moment te maken en te testen.

Bouw prototypes

Build prototypes ^[1] [6] ( build prototypes ) is een principe dat de bouw van een prototype van het te maken product aanbeveelt. Het concept van het product wordt duidelijk op het prototype en potentiële problemen van het product kunnen al vroeg worden herkend en worden meegenomen bij de verdere ontwikkeling van het product in de vorm van te testen eisen .

Door het prototype komen wijzigingsverzoeken aan het product vroeg en worden dure, misplaatste ontwikkelingen vermeden. Het is raadzaam om de klant mee te nemen in de ontwikkeling en feedback te krijgen op het prototype.

Zie ook: klanten engageren .

Neem geen kleine slips

Neem geen kleine strookjes ^[1] (zeg: maak geen kleine misstap ) is van toepassing wanneer een project achterloopt op schema. Als de geplande voltooiingsdatum herhaaldelijk met een paar dagen wordt uitgesteld, neemt het vertrouwen in het projectplan af. Daarom moet de voltooiingsdatum worden verplaatst naar een groter gebied, mogelijk met geplande beveiliging. ^[7]

De projectstatus moet ongeveer een keer per week worden herzien en de geschatte einddatum moet opnieuw worden geschat op basis van statistische gegevens.

Indeling van de arbeid

Arbeidsverdeling ^[1] [8] (Engels: werkverdeling ) is een methode om zich te concentreren op de belangrijke activiteiten door het team te verdelen en minder belangrijke activiteiten in subgroepen onder te verdelen. De belangrijke activiteiten mogen niet meer dan de helft van het team in beslag nemen, terwijl onbelangrijke activiteiten kunnen worden geëlimineerd.

Een taakverdeling moet worden gebruikt wanneer belangrijke doelen achterlopen op schema omdat het team bezig is om minder belangrijke doelen te bereiken.

Voltooiing hoofdruimte

Indien de verwachte einddatum berekend voor elke groep in een project, het verschil tussen de verwachte einddatum en dato zijn voltooid headroom ^[1] [8] (letterlijk: Voltooiing headroom ), respectievelijk.

Dit verschil moet minstens één keer per week worden herberekend om dit met passende maatregelen door het management te kunnen tegengaan als het verschil te hoog wordt. Dit is onder meer een hergroepering en daaropvolgende verdeling van activiteiten en, indien nodig, uitstel van de geplande voltooiingsdatum.

Impliciete vereisten

Impliciete vereisten ^[1] ( impliciete vereisten ) zijn vereisten die de klant heeft, zonder expliciet te worden vermeld. Impliciete eisen ontstaan ​​doordat de individuele functies van het te ontwikkelen product worden verdeeld en benoemd.

Vooral in softwareontwikkeling kunnen impliciete vereisten beveiliging, prestaties, logboeken, back-upstrategieën, foutafhandeling, onderhoudbaarheid, aanpassingsvermogen aan veranderende bedrijfsprocessen, enzovoort omvatten.

Wachtrij

Een wachtrij ^[1] (Engels: werkwachtrij ) is een geprioriteerde lijst van impliciete vereisten , die nog moet worden uitgevoerd. De volgorde van activiteiten verandert als de vereisten veranderen.

Een wachtrij komt overeen met de achterstand in Scrum . ^{[8] [9] [10]}

Een wachtrij is veel gemakkelijker om mee te werken en duidelijker dan een traditionele netwerk van Gantt-grafieken , die moeilijker te maken, de mensen die betrokken zijn overweldigd door de details en ook moet worden weggegooid voor het grootste deel, als de eisen veranderen.

Recommitment Meeting

Een recommitment-bijeenkomst ^[1] [8] is een vergadering voor projectbeheer en een toonaangevende ontwikkelaar van een project wanneer niet aan impliciete vereisten kan worden voldaan binnen de geplande tijdlijn. Het is belangrijk om duidelijk te maken hoe een vereiste functionaliteit met de minste mogelijke inspanning kan worden gerealiseerd. Het schema wordt vervolgens bijgewerkt met behulp van een werkwachtrijrapport .

Informeel laboratoriumplan

Een informeel werkplan ^[1] is een indicatief tijdschema voor het publiek. Individuen of kleine groepen creëren hun eigen kortetermijnplanningen om het werk te verdelen, zodat het tijdschema dat door het management is vastgesteld het best kan worden gehaald. De projectmanager bewaakt het schema alleen met een grove resolutie, terwijl de medewerkers zelfstandig voor de details zorgen en zich committeren aan het voldoen aan hun tijdschema.

Development Episode [ edit | Bewerken ]

In een ontwikkelingsaflevering ^{[1] gaan} alle medewerkers van een team hetzelfde probleem aan. Dit combineert de verschillende sterktes van elke persoon om de best mogelijke oplossing te bereiken. Als bijwerking wordt kennis overgedragen van specialist naar andere werknemers en neemt ook de reputatie van specialisten binnen de groep toe.

Developer Controls Proces

Developer Controls Process ^[1] is een informatiestructuur binnen een bedrijf waar de ontwikkelaars van een product bidirectioneel kunnen communiceren met alle betrokken stakeholders. De informatiestroom omvat ideeën, vereiste verzameling, testen, levering en marketing van de respectieve producten.

Het is echter belangrijk om ervoor te zorgen dat ontwikkelaars niet worden overladen met taken. Dit kan worden gedaan door de informatiestroom, taakverdeling binnen het ontwikkelteam en delegatie te filteren.

Werkstromen naar binnen

Werkstromen naar binnen ^[1] is een informatiestructuur waarin het werk rechtstreeks van buiten het bedrijf naar de juiste rol vloeit. Om dit mogelijk te maken, zijn duidelijk omschreven rollen en gevestigde processen vereist.

Het is hier kenmerkend dat het management slechts een klein deel van de informatiestroom heeft en geen extra werk genereert. Bovendien moet ervoor worden gezorgd dat de informatiestroom van een klant naar de betreffende werknemer een informeel en niet-indicatief karakter heeft.

Episodes programmeren

Een programmeeraflevering ^[1] is wanneer softwareprogramma’s die secties van code in code programmeren waarvoor er een duidelijke beslissing over het gewenste gedrag is. Programmaonderdelen waarvoor geen duidelijke beslissing mogelijk is, worden gemaakt na een evaluatie van de bestaande codebase op een later tijdstip en geïmplementeerd in een downstream-programmeerperiode.

Iemand maakt altijd voortgang

Iemand maakt altijd vooruitgang ^[1] is een managementprincipe waarbij een deel van het team zorgt voor de kerntaak om een ​​bepaald doel te bereiken, terwijl een ander deel van het team zorgt voor taken die afbreuk doen aan de kerntaak.

Verdere projectbeheerpatronen

Dit artikel of gedeelte bestaat voornamelijk uit lijsten die beter tekstueel zouden moeten zijn. Help Wikipedia om dit te verbeteren. Meer over is hier te vinden.

Patroon voor geleidelijke groei

Formaat van de organisatie

In de omvang van de organisatie ^[1] het gaat om de mogelijkheid om de gewenste grootte van een team voor een project, en de vereiste omvang van de onderneming als de som van alle teams te schatten. Voor grote projecten (met Software> 25 k SLOC) is het zeldzaam dat het project binnen de geplande tijd en kosten zal worden afgerond. De redenen zijn veelvoudig:

• Als het projectteam te groot is, zijn de kosten meestal zo hoog dat de investering niet de moeite waard is.
• Als het projectteam te groot is, gaat het algemene overzicht van het product verloren.
• Te grote teams zijn minder flexibel in kleine veranderingen en het duurt langer om te reageren.
• Bij een te klein team kan de tijd niet worden vastgehouden.
• Als het projectteam te klein is, ontbreekt de kritische massa en daarmee het moment om het project te realiseren.
• Als het projectteam wordt vergroot tijdens het laatste deel van het project, treedt de wet van Brooks in werking .

Voor softwareprojecten met een goed gekozen en ondersteund projectteam van 10 personen, kunnen projecten van de volgende omvang worden beheerst: ^[1]

• 60 kSLOC in 8 maanden
• 200 kSLOC in 15 maanden
• 1500 kSLOC in 31 maanden

Elke rol in het team kan communiceren met 3 tot 7 andere rollen, wat ook zorgt voor communicatie binnen verschillende afdelingen in grote bedrijven.

De beste teamgrootte varieert met het project, maar mag niet minder zijn dan 3 personen en niet meer dan 12 personen. Grotere teams moeten worden opgesplitst, maar opsplitsing door veranderende werkprocessen kan ook de productiviteit verminderen.

Surrogaat klant

Een surrogaatklant ^[1] ( vervangende klant ) wordt gebruikt als de klant verplicht is voor productfeedback maar de klant niet beschikbaar is.

Het probleem dat de klant niet beschikbaar is, kan om verschillende redenen ontstaan. Bijvoorbeeld

• het product dat de klanten het eerst zouden moeten produceren
• de klant heeft het te druk
• Contact met de klant is op een bepaald moment niet geschikt
• een slecht bedrijfsbeleid scheidt de ontwikkelaars van het product van de klant

Om de klant te vervangen, moet een persoon worden gekozen die niet betrokken is bij de ontwikkeling van het product (dwz niet bevooroordeeld). Er moet echter worden opgemerkt dat een vervangende klant de werkelijke klant niet volledig kan vervangen en slechts een tijdelijke oplossing vertegenwoordigt.

Verdere groeipatronen

Dit artikel of gedeelte bestaat voornamelijk uit lijsten die beter tekstueel zouden moeten zijn. Help Wikipedia om dit te verbeteren. Meer over is hier te vinden.

Organisatie ontwerppatroon

Dit artikel of gedeelte bestaat voornamelijk uit lijsten die beter tekstueel zouden moeten zijn. Help Wikipedia om dit te verbeteren. Meer over is hier te vinden.

Organisatiestijlpatroon

Andere organisatiestijlpatronen

• Gemeenschap van vertrouwen
• Verdeel en heers
• Wet van Conway
• Vorm volgt functie

Persoonlijke en productstalen

Verdere mensen en productstalen

• Gemeenschap van vertrouwen
• Wet van Conway
• Incrementele integratie
• privéwereld
• genaamd stabiele basen

Verdere organisatiepatronen

Dit artikel of gedeelte bestaat voornamelijk uit lijsten die beter tekstueel zouden moeten zijn. Help Wikipedia om dit te verbeteren. Meer over is hier te vinden.

Standaarden

• BS 15000
• IT Infrastructure Library
• ISO / IEC 20000
• Microsoft Operations Framework (MOF)
• COBIT
• Verbeterde Telecom Operations Map

Personen

• Alistair Cockburn

Literatuur

• James O. Coplien, Heil B. Harrison: organisatorische patronen van Agile Software Development . Pearson , Prentice Hall , Upper Saddle River 2004, ISBN 978-0-13-146740-8 , blz. 432.
• Linda Rising: The Patterns Almanac 2000 . Addison-Wesley , Amsterdam 2000, ISBN 978-0-201-61567-8 , blz. 448.
• Steve Berczuk, Brad Appleton: Softwareconfiguratie Managementpatronen: effectief teamwork en praktische integratie . Addison-Wesley, 2002, ISBN 978-0-201-74117-9 , blz. 208.

Webkoppelingen

• Ward Cunningham : de Wiki van Portland Pattern Repository. Cunningham & Cunningham, Inc., geopend op 10 maart 2013 (Engels).
• Brian Foote : Pattern Labyrinth. Betreden op 10 maart 2013 (Engels).

Individuele proeven

1. ↑ ^{hoogspringen door:a b c d e f g h i j k l m n o p q r s t u v w x y z aa van ac advertentie ae af ag ah ai aj ak al ben om oa ap aq ar als bij au av aw ax ay az ba bb bc bd zijn bf bg bh bi bj bk bl bm bn bo bp bq br bs bt bu bv bw bx door bz ca cb cc cd ce cf cg ch ci cj ck cl cm cn co cp cq cr cs} James O. Coplien medicinaal B. Harrison: organisatorische patronen van Agile Software Development . Pearson , Prentice Hall, Upper Saddle River 2004,ISBN 978-0-13-146740-8 , blz. 432.
2. ↑ ^{Ga naar:a b c d} Christopher Alexander: A Pattern Language: Towns, Buildings, Construction . Oxford University Press, New York 1977, ISBN 978-0-19-501919-3 , blz. 1171.
3. Jump up↑ Christopher Alexander: de tijdloze manier van bouwen . Oxford University Press, 1979, ISBN 978-0-19-502402-9 , blz. 568.
4. ↑ ^{springen om:a b} John Vlissides , Norman Kerth , James Coplien : Pattern Talen van programma-ontwerp (= Pattern Talen van programma-ontwerp . Volume 2). 1e editie. Addison-Wesley, 1996, ISBN 978-0-201-89527-8 , Demo Prep: A Pattern Language voor de voorbereiding van softwaredemonstraties, blz. 624 (Engels, c2.com [geopend op 7 maart 2013]).
5. ↑ ^{Ga naar:a b} Stephen Berczuk, Brad Appleton: Softwareconfiguratie Managementpatronen: effectief teamwork, praktische integratie . Addison-Wesley, Amsterdam 2002, ISBN 978-0-201-74117-9 .
6. Jump up↑ Ian Graham: specificatie in expert-systemen en conventionele IT-projecten . In: Computing and Control Engineering Journal 2 . Volume 2, 1991, pp. 82-89.
7. Jump up↑ Frederick Brooks : The Mythical Man-Month: Essays on Software Engineering . Addison-Wesley, 1995, ISBN 978-0-201-83595-3 , blz. 272.
8. ↑ ^{springen om:a b c d} Ward Cunningham , John Vlissides , Norman Kerth , James Coplien : Pattern Talen van programma-ontwerp (= Pattern Talen van programma-ontwerp . Volume 2). Addison-Wesley, Amsterdam 1996, ISBN 978-0-201-89527-8 , Episodes: A Pattern Language of Competitive Development.
9. Jump up↑ Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, Jeff Sutherlan: Scrum: een patroontaal voor hyperproductieve softwareontwikkeling. Betreden op 28 maart 2013 (PDF, 118 kB, Engels).
10. Jump up↑ Linda Rising: The Patterns Almanac 2000 . Addison-Wesley, Amsterdam 2000, ISBN 978-0-201-61567-8 , blz. 448.
11. Spring omhoog↑ Luke Wroblewski: Twitter-sign-ups van geleidelijke engagement boost met 29%. 16 juni 2010, toegankelijk op 8 april 2013 (Engels).
12. Jump up↑ Alistair Cockburn: object-georiënteerde projecten overleven: een gids voor managers . Addison-Wesley, Amsterdam 1998, ISBN 978-0-201-49834-9 , blz. 272.
13. Jumping Up↑ Bruce G. Whitenack: Pattern Talen van programma-ontwerp (=  Pattern Talen van programma ontwerp band. 2). Addison-Wesley, 1995, ISBN 978-0-201-89527-8 , RAPPeL: A Requirements Analysis Process Pattern Language for Object-Oriented Development, pp. 259-291.