A folyamatos tervezés megismerése

Befejeződött

A folyamatos tervezés a nyolc DevOps-képesség egyike.

Ismerje meg, miért van szükség a folyamatos tervezésre

Tekintsük át a kormányzati ügynökség által 2000 és 2005 között kifejlesztett szoftveralkalmazás esettanulmányát. A projekt nem volt közel a befejezéshez, amikor 2005 januárjában hivatalosan felhagytak vele, és teljes kudarcba fulladt. Amellett, hogy legalább 100 millió dollárt elsiklott, a kudarc széles körben bírálta az ügynökséget és annak igazgatóját.

2006-ban egy második projekt indult el, hasonló katasztrofális eredménnyel. A két törekvés a nagy tervezést és a Vízesés fejlesztési módszertant használta, egy klasszikus tervezett big bang go-live eseménysel. Úgy végződtek, hogy semmit nem szállítottak le, és több száz millió dollárt költöttek.

Diagram shows the government agency project timeline.

Miért hiúsultak meg ezek a kísérletek?

  • Nagy tervezés elöl – a 200 fős csapat hat hónapot töltött a követelmények kialakításával.
  • A prioritások átcsoportosítása – katasztrófa történt a projekt során, ami jelentős hatókörváltozást eredményezett –, és hat hónapig egy másik 300 fős csapat dolgozott, ami 600 oldalnyi követelményt eredményezett.
  • Az elpazarolt munka és az átdolgozás miatt elmulasztott határidők és a csapat kiégett – 700 000 sornyi kód megírása és újraírása.

2010 decemberében egy Scrum-stúdiót hoztak létre és hoztak létre közösen. A személyzet az eredeti projektekben 400-ról 40-re csökkent. A tervezés 600 oldalnyi követelményről 670 felhasználói történetre terjedt ki. A csapat kéthetente szállította a kódot, és bemutatta az új funkciókat. Néhány futam után lehetővé vált a durva időskálák előrejelzése és a növekményes üzleti változások megtervezése. A kód 2011 decemberéig készült el.

De miért nehéz részletesen megtervezni?

Alan Turing kifejlesztett egy gépet a második világháború alatt, hogy feltörje az Enigma Machine néven ismert titkosítási eszközt.

Turingnak folyamatosan új kódokat kellett megfejtenie, hogy életeket mentsen. Ahelyett, hogy a látszólag végtelen összetettség miatt feladta volna, Turing tudta, hogy csak apró részleteket kell feltörnie, hogy nagyobb eredményekhez adjon utat:

"Csak rövid távot láthatunk előre, de rengeteget láthatunk ott, amit el kell végezni."

Az ambiciózus szoftverprojektek mindig összetettek. De ne hagyja, hogy az összetettség túlterhelje magát. Ehelyett hajtsa végre az egyértelműséget: a rövid kifejezést.

Folyamatosan és hatékonyan tervezze meg a célkitűzésekre és a fő eredményekre (OKR) támaszkodó egyértelmű irányt, fókuszt és rugalmasságot

A folyamatos tervezés meghatározása előtt egy fontos koncepciót és keretrendszert kell bevezetnünk, amely segít a folyamatos és hatékony tervezésben világos irány, fókusz és rugalmasság mellett.

A Célok és fő eredmények (OKRs) egy célmeghatározó keretrendszer, amelynek célja, hogy összekapcsolja a vezetés által kitűzött stratégiai célokat a végrehajtási csapatok napi tevékenységeivel.

Fontos

Az OKR-ek segítenek azonosítani a lehető legjobb eredményt , és egyértelművé tenni a valódi sikert.

Az OKR-ek általában negyedévente vannak beállítva az éles fókusz és az agilitás érdekében.

A cél az irány, és a fő eredménynek mérhetőnek kell lennie. A végén megnézheti, és érvek nélkül döntse el: Tettem ezt, vagy nem tettem meg? Igen? Nem? Egyszerű. Nincs ítélet benne.

Az OKR-ek le vannak honosítva a szervezet összes csapatában az igazítás és az átláthatóság bemutatásához.

Mik azok az OKR-ek?

Az OKR-ek három alapvető szempontot jelentenek:

  • Kereteket alkotnak a világos célkitűzések meghatározásához, és egyértelművé teszik a szándékot és az irányt a szervezet minden szintjén.

  • Mérhető kulcseredményekkel vannak megerősítve. A fő eredmények azok az eredmények, amelyekkel a sikert mérik.

  • Az eredményszemlénnyel kapcsolatos kultúrát vezetik be, lehetővé téve a kimeneti gondolkodásmódról az eredmény szemléletre való egyértelmű váltást.

OKR-példa

Íme egy OKR-példa:

Cél: 1970-ig helyezzen egy űrhajóst a Holdra.

Főbb eredmények:

  1. Építs egy űrhajót 1965-ig 40000 font alatt.
  2. Űrhajósokat tanít a holdra szállásra 1967-ig.
  3. Sikeresen leszállt az űrhajó a Holdra.
  4. Széf hozza vissza az űrhajósokat a földre.

Ez az OKR-példa azt a célt vagy célt azonosítja, hogy egy űrhajóst 1970-ig a Holdra helyezzenek.

Megjegyzés:

A célkitűzéseknek könnyen érthetőnek, világos iránynak és motivációnak kell lenniük.

Ebben a példában a fő eredmények olyan előrehaladási mértékek, amelyek mérik a célkitűzés sikerességét.

Megjegyzés:

A fő eredményeknek mérhetőnek kell lenniük, és azonosítaniuk kell, hogyan lehet elérni a célkitűzést.

Az OKRs főbb előnyei

Az OKR-ek öt fő előnye van:

  • Fókusz: minden célnak egy sorban kell elférnie. Ami a legfontosabb eredményeket, akkor nem lehet több, mint öt célkitűzés.
  • Igazítás: a vezetők és a közreműködők egyaránt összekapcsolják a napi tevékenységeiket a szervezet vállalati szintű elképzelésével. Ennek a kapcsolatnak a kifejezése az igazítás, és az értéke nem lehet túlértékelt.
  • Kötelezettségvállalás: az ütemezéseket és az erőforrásokat úgy módosítjuk, hogy minden elfogadott kötelezettségvállalás teljesüljön.
  • Az OKR-ek a kimenettől az eredményig való nyomon követése miatt a célkitűzések szerinti felügyelet annyira népszerű a felső szintű vállalatok körében. Minden OKR-nek nyomon kell követnie az íráskor megállapított metrikákat.
  • Nyújtás: Az OKR-ek eredendően arra ösztönözik a szervezeteket, hogy tovább törekedjenek, hogy egy kicsit többet tudjanak kihozni, mint amit lehetségesnek gondoltak.

Folyamatos és statikus tervezés összehasonlítása

A folyamatos tervezés olyan gyakorlat, amely megköveteli a tervezők, az építészek és az agilis csapatok számára, hogy terveiket folyamatosan integrálják a vállalaton belül.

A folyamatos tervezésben a scrum-alapú tervezési módszerek és az újonnan megjelenő tervek lehetővé teszik a csapatok számára a tervezés végrehajtási szintre történő finomítását.

Fontos, hogy egy olyan magas szintű terv legyen, amely rugalmas a változáshoz, de világos látás és cél vezérel.

A vízesés és az agilis fejlesztési módszertanok kompromisszumainak vasháromszöge a folyamatos és a statikus tervezés összehasonlítását szemlélteti.

A statikus módszertanban a hatókör tervezése rögzített. Ön határozza meg, hogy a projekt mennyi időt vesz igénybe, és mennyibe fog kerülni.

A folyamatos tervezési alapelveket használó Agilis módszertanban az idő az üzleti céloknak való megfeleléshez van rögzítve. Az egyetlen dolog, ami forgatható, a hatókör.

Diagram shows the iron triangle of tradeoffs for Waterfall vs. Agile development methodologies.

A vas háromszög általában az időt, az erőforrásokat és a funkciókat jeleníti meg. A Gartner hozzáadott minőséget az ábrázoláshoz, mivel az időtartam és a költség korrelál, és a minőség gyakran hiányzik.

De mi a helyzet a két gyakorlat sikerével?

Diagram shows a comparison between the success rates of Agile and Waterfall projects. 9% of the Agile projects failed, 39% succeeded, and 52% were challenged. 29% of the Waterfall projects failed, 11% were successful, and 60% were challenged.

Az Agile-projektek egyik sikeresebb oka az, hogy a kis kötegkiadások növelik a tudásszerzés lehetőségét.

Négy dolgot kell szem előtt tartani:

  • Az üzletnek folyamatosan változnia kell, és ezt rövid időn belül meg kell tenni.
  • Az Agile tervezési mechanizmusokkal rendelkezik, hogy lépést tartson az üzleti változásokkal.
  • A nagy teljesítményű csapatok gyorsan rossz irányba haladhatnak.
  • A tudás megszerzése csökkenti a kockázatot.

A Vízesés és az Agilis módszertan egyaránt kihívást jelent. Agilis csak történetesen sikeres 30%-kal több az idő.

A folyamatos tervezés hat alapelvének megismerése

A folyamatos tervezésnek hat alapelve van:

  1. Érték egyszerűsége
  2. Az agilis szoftverfejlesztés kiáltványa
  3. Tervezési gondolkodás
  4. Iteratív és növekményes fejlesztés
  5. Lean-kezelés
  6. Becslés pontossága

Folyamatos tervezés elve #1: Az érték egyszerűsége

Az első folyamatos tervezés alapelve az egyszerűség.

"Ha nem tudod egyszerűen elmagyarázni, nem érted elég jól."

-Albert Einstein

A folyamatos tervezés elve #2: Manifesto az agilis szoftverfejlesztéshez

A második folyamatos tervezés elve az agilis szoftverfejlesztés kiáltványa.

A kiáltvány a szoftverek kézbesítéséről szól. Ez a szoftverfejlesztésről szól – nem a projektkezelésről vagy a tervezésről. A folyamatos tervezés és a DevOps alapja.

Jobb módszereket fedezünk fel a szoftverek fejlesztésére azáltal, hogy ezt tesszük, és segítünk másoknak is. Ezzel a munkával a következőket értékeltük:

  • Egyének és interakciók folyamatok és eszközök felett
  • A szoftverek átfogó dokumentáción keresztüli használata
  • Ügyfél-együttműködés szerződéskötésen keresztül
  • Válasz a terv alapján történő változásra

Folyamatos tervezés elve #3: Tervezési gondolkodás

A harmadik folyamatos tervezés alapelve a tervezési gondolkodás.

A tervezési gondolkodás emberközpontú megközelítést alkalmaz az innovációra. Középpontjában az életképesség, a megvalósíthatóság és az kívánatosság metszete áll, hogy határokat állapítsunk meg és csökkentsük a hulladékot.

Diagram explains design thinking. Design thinking establishes the boundaries of the product early (often called the minimal viable product or “MVP”). It focuses on the intersection between business viability, technical and budget feasibility, and desirability. This intersection is where innovation happens.

Folyamatos tervezés elve #4: Iteratív és növekményes fejlesztés

A negyedik folyamatos tervezés elve az iteratív és növekményes fejlesztés.

Néhányan attól tartanak, hogy nem tudják, mit kapnak. Az iteratív fejlesztés úgy oldja meg ezt a problémát, hogy a követelményeket és a rangsorolást egy iteratív visszajelzési ciklusban az érdekelt felek kezébe helyezi. Minden iteráció teljes, használható és hasznos a felhasználók számára. Először több funkciót ad hozzá, lehetőleg a legfontosabb funkciókat.

Folyamatos tervezési alapelvek #5: Lean management

Az ötödik folyamatos tervezés alapelve a lean management.

Az érték a végfelhasználó szempontjából van definiálva. A folyamat során az értékáramok azonosíthatók, és azok a lépések, amelyekben az érték nem jut el az ügyfélhez, hulladékként lesznek azonosítva és eltávolítva.

A folyamat újra megkezdődik, folyamatos fejlesztéssel törekedve a tökéletesség állapotára.

Diagram shows the stages of the process: identify value, map the value stream, create flow, establish pull, and seek perfection.

Folyamatos tervezés elve #6: Becslés pontossága

A hatodik folyamatos tervezés elve a becslés pontossága.

A becslés egy elemzési előrejelzés arról, hogy mennyi ideig fog tartani valami, mennyibe fog kerülni, vagy hogy hány szolgáltatás érhető el. Két attribútuma van: pontosság és pontosság, amelyek teljesen függetlenek egymástól. A becslések a mérnöki csapat tulajdonában vannak.

A cél egy üzleti igény kimutatása: mennyi ideig szeretnénk valamit igénybe venni, mennyit szeretnénk, hogy mennyibe kerül, vagy hány funkciót szeretnénk kézbesíteni. A célokat a vállalat birtokolja.

A kötelezettségvállalás egy ígéret, amely egy bizonyos dátumig biztosítja a funkcionalitást és a minőséget. A kötelezettségvállalások közös tulajdonban vannak.

Fontos

A folyamatos tervezés célja a becslések, a cél és a kötelezettségvállalás közötti összhang fenntartása. Ellenkező esetben nem fogjuk teljesíteni a szervezeten belüli és kívüli elvárásokat.

Az OKR és a Scrum közötti kapcsolat ismertetése

Most, hogy megismerte az OKR-ek okát és mibenlétét , valamint a folyamatos tervezést, itt van a kapcsolat a kettő között.

Az OKR-ekhez hasonló technikákkal végzett munka strukturálása csökkenti a bizonytalanságot, legalábbis rövid távon. Mivel az OKR-ek kaszkádolt módon vannak definiálva, ez megváltozik, hogy a vezetők hogyan fogják ábrázolni a felügyeleti stílusukat.

Az OKR-hez hasonló technikák gyorsan és hatékonyan indítják el az utat a tekintélyelvű felügyeleti stílustól.

Objectives and key results lead to epics. Epics help define features, which involve user stories, and result in a development task.