PI suunnittelu

tulevia tuotekehitystehtäviä ei voi ennalta määrätä. Jakaa suunnittelua ja valvontaa niille, jotka ymmärtävät ja reagoivat lopputulokseen.

– Michael Kennedy, tuotekehitys Lean Enterpriselle

turvallisessa ei ole taikaa . . . paitsi ehkä yksityisetsivän suunnittelussa.

– tekijät

Johdatus PI suunnittelu: Nopea yleiskatsaus

Program Increment (PI) Planning on kadenssipohjainen tapahtuma, joka toimii Agile Release Trainin (ART) sykkeenä, joka yhdistää kaikki taiteen tiimit yhteiseen missioon ja visioon.

pi-suunnittelu on oleellista turvallisuuden kannalta: jos et tee sitä, et tee turvallista.

Etsi kurssi:

Agile manifestissa todetaan: ”tehokkain ja tehokkain tapa välittää tietoa kehitystiimille ja sen sisällä on kasvokkain käytävä keskustelu.”SAFe vie tämän seuraavalle tasolle PI suunnittelu.

tähän liittyy mahdollisuuksien mukaan fyysinen yhteistoiminta, ja näitä laajamittaisia PI-suunnittelutapahtumia järjestetään nykyään monissa yrityksissä ympäri maailmaa. He ovat selvästi osoittaneet todellisen taloudellisen sijoitetun pääoman tuoton, puhumattakaan aineettomista tekijöistä, joita syntyy, kun ketterät joukkueet luovat sosiaalisen rakenteen, joka on henkilökohtaisesti ja kollektiivisesti palkitseva.

koko taiteen kollokaatio ei välttämättä kuitenkaan aina ole käytännöllistä, ja nykyisinä aikoina COVID-19 on luonut tilanteen, jossa tämä ei ole vaihtoehto. Vaikka fyysisellä kasvotusten suunnittelulla on etunsa, kirjoittamaton turvallinen ’sääntö’ on ”ihmiset, jotka tekevät työn, suunnittelevat työn.”Kun fyysinen läsnäolo ei ole mahdollista, reaaliaikainen, samanaikainen, virtuaalinen, kasvokkain tapahtuva suunnittelu on nyt osoittautunut tehokkaaksi. Monet taiteet ovatkin onnistuneet luomaan hybriditilanteen, jossa useat tiimit liittyvät etäyhteydellä, kuten kuvassa 1 on esitetty.

advanced topic-artikkeli, Distributed PI Planning with SAFe, tarjoaa lisäohjeita ja huomioita näiden skenaarioiden onnistuneeseen hallintaan.

Kuva 1. Kasvotusten yksityisetsivän kanssa. Etätiimit suunnittelevat samaan aikaan videoneuvotteluja.

PI—suunnittelulla on vakioagenda, joka sisältää liiketoimintayhteyden ja vision esittelyn, jota seuraa tiimisuunnittelu breakouts-jossa tiimit luovat Iterointisuunnitelmansa ja tavoitteensa tulevalle Ohjelmalisäykselle (pi). Helpotti Release Train Engineer (RTE), tämä tapahtuma sisältää kaikki jäsenet taiteen ja tapahtuu sisällä Innovaatio ja suunnittelu (IP) iteraatio. Tapahtuman pitäminen IP-iteraation aikana ei vaikuta PI: n muiden iteraatioiden ajoitukseen tai kapasiteettiin. PI suunnittelu tapahtuu kahden päivän aikana, vaikka tämä on usein laajennettu mahtuu suunnittelu yli useita aikavyöhykkeitä.

PI: n suunnittelun liiketoimintahyödyt

PI: n suunnittelulla on monia liiketoiminnallisia etuja, mm.:

  • face-to-face-viestinnän luominen kaikille tiimin jäsenille ja sidosryhmille
  • sosiaalisen verkoston luominen taide riippuu
  • kehityksen sovittaminen liiketoiminnan tavoitteisiin liiketoiminnan kontekstin, vision sekä tiimin ja ohjelman pi tavoitteiden kanssa
  • riippuvuuksien tunnistaminen ja työryhmien ja taiteiden välisen yhteistyön edistäminen
  • tarjoaa mahdollisuuden right amount ” of architecture and lean user experience (UX) guidance
  • matching demand to capacity and eliminating excess work in process (WIP)
  • fast päätöksenteko

PI: n suunnittelun panokset ja tuotokset

PI: n suunnittelun panokset ovat:

  • liiketoimintaympäristö (KS. jäljempänä ”sisältövalmius”)
  • tiekartta ja visio
  • Ohjelmakannan Top 10-ominaisuudet

onnistunut PI-suunnittelutapahtuma tuottaa kaksi ensisijaista tuotosta:

  • sitoutunut PI tavoitteet – joukko älykkäitä tavoitteita, jotka on luotu kunkin joukkueen kanssa liiketoiminnan arvo määritetty yritysten omistajat.
  • program board-korostaen uusien ominaisuuksien toimituspäivämääriä, ominaisuusriippuvuuksia joukkueiden välillä ja olennaisia virstanpylväitä.

valmistelu

PI-suunnittelu on merkittävä tapahtuma, joka vaatii valmistelua, koordinointia ja viestintää. Sitä helpottavat RTE ja tapahtuman osallistujia ovat yritysten omistajat, tuotehallinta, ketterät tiimit, järjestelmä-ja ratkaisuarkkitehti/suunnittelu, Järjestelmätiimi ja muut sidosryhmät, joista kaikista on ilmoitettava etukäteen, jotta ne ovat hyvin valmistautuneita. Yritysten omistajien aktiivinen osallistuminen tähän tapahtumaan tarjoaa tärkeän suojakaiteen talousarvioon.

tapahtuman onnistuminen edellyttää valmistautumista kolmella pääalueella:

  • organisatorinen valmius-strateginen linjaus ja joukkueiden ja junien asetukset
  • Content ready – Management and development preparation
  • Logistics ready – Considerations for running a successful event

alla on poimintoja ART ready Checklististä. (Täydellinen tarkistuslista on valmisteyhteenvetojen käytettävissä olevassa safe PI Planning Toolkit-työkalupakissa).

organisatorinen valmius

ennen PI: n suunnittelua osallistujien, sidosryhmien ja yritysten omistajien on yhdenmukaistettava strategiaa. Kriittiset roolit annetaan. Jotta tähän voidaan puuttua etukäteen, tapahtumajärjestäjien on kuitenkin otettava huomioon seuraavat seikat::

  • suunnittelun laajuus ja konteksti-ymmärretäänkö suunnitteluprosessin laajuus (tuote, järjestelmä, teknologia-ala)? Tiedämmekö, mitkä tiimit suunnittelevat yhdessä?
  • yritysten linjaus – onko yritysten omistajien kesken järkevää yksimielisyyttä tärkeysjärjestyksestä?
  • ketterät joukkueet-onko meillä ketteriä joukkueita? Onko tiimissä omistautuneita jäseniä ja tunnistettuja Scrum Master ja Product Owner jokaiselle tiimille?

Sisältövalmius

yhtä tärkeää on varmistaa selkeä visio ja asiayhteys sekä oikeiden sidosryhmien osallistuminen. Tämän vuoksi PI: n suunnitteluun on sisällyttävä:

  • Executive briefing – a briefing that defined the current business context
  • Product vision briefing(s) – Briefings prepared by Product Management, including the top 10 features in the Program Backlog
  • Architecture vision briefing – a presentation made by the CTO, Enterprise Architect, or System Architect to communicate new Enablers, features, and Nonfunctional Requirements (NFRs)

Logistiikkavalmius

tapahtuman valmistelu suuren osallistujamäärän tueksi ei ole vähäpätöistä. Fyysisessä yhteistuotantosuunnittelussa tähän voi sisältyä fyysisen tilan varmistaminen ja valmistelu. Etäosallistujien tai täysin hajautetun PI-suunnittelun osalta tähän sisältyy myös investointi tarvittavaan tekniseen infrastruktuuriin. Huomioita ovat:

  • paikat – jokainen suunnittelupaikka on valmisteltava etukäteen
  • Tekniikka ja työkalut – reaaliaikainen tiedonsaanti ja työkalut hajautetun suunnittelun tai etäosallistujien tueksi
  • viestintäkanavat-ensisijaiset ja toissijaiset ääni–, video-ja esityskanavat on oltava saatavilla

Standardiagenda

tapahtuma seuraa agendaa, joka vastaa kuva 2. Kuvaukset kunkin kohteen jälkeen. Ohjeita tämän ohjelman mukauttamisesta tukemaan suunnittelua useilla aikavyöhykkeillä, katso advanced topic artikkeli, hajautettu pi suunnittelu turvallinen.

kuva 2. Standard kaksipäiväinen PI-suunnitteluohjelma

Day 1 Agenda

  • Business context – yrityksen omistaja tai Ylin johto kuvaa liiketoiminnan nykytilaa, jakaa portfolion Vision ja esittää näkökulman siihen, kuinka tehokkaasti olemassa olevat ratkaisut vastaavat nykyisiä asiakastarpeita.
  • Product / solution vision-Product Management esittelee nykyisen vision (jota edustavat tyypillisesti seuraavat top 10 tulevat ominaisuudet) ja tuo esiin kaikki muutokset edellisestä PI-suunnittelutapahtumasta sekä mahdolliset tulevat virstanpylväät.
  • Architecture vision and development practices-System Architect/Engineering esittelee arkkitehtuurin vision. Myös senior development manager voi ottaa käyttöön ketterästi tukevia muutoksia kehityskäytäntöihin, kuten testiautomaatioon, DevOps: iin, jatkuvaan integraatioon ja jatkuvaan käyttöönottoon, joita kehitetään tulevassa PI: ssä.
  • Suunnittelukonteksti ja lounas-RTE esittelee tapahtuman suunnitteluprosessin ja odotetut lopputulokset.
  • Team breakouts #1-breakoutissa joukkueet arvioivat kapasiteettinsa jokaista iteraatiota varten ja tunnistavat ne backlog-kohteet, joita ne todennäköisesti tarvitsevat ominaisuuksien toteuttamiseksi. Jokainen joukkue luo suunnitelmaluonnoksensa, jotka ovat kaikkien nähtävissä, iteraatio kerrallaan.

tämän prosessin aikana ryhmät tunnistavat riskit ja riippuvuudet ja laativat ensimmäiset team PI-tavoitteensa. PI: n tavoitteet sisältävät yleensä ”sitomattomia tavoitteita”, jotka on sisällytetty suunnitelmaan (esim.näitä tavoitteita varten määritellyt ja sisällytetyt tarinat), mutta työryhmä ei ole sitoutunut niihin liian monien tuntemattomien tai riskien vuoksi. Sitomattomat tavoitteet eivät ole ylimääräisiä asioita, jos aikaa on. Sen sijaan ne lisäävät suunnitelman luotettavuutta ja antavat johdolle ennakkovaroituksen tavoitteista, joihin taide ei välttämättä pysty. Tiimit lisäävät myös ohjelmatauluun ominaisuuksia ja niihin liittyviä riippuvuuksia, kuten kuvassa 3 on esitetty.

kuva 3. Ohjelmataulu, jossa näkyvät ominaisuudet ja riippuvuudet
  • suunnitelmaluonnoksen tarkastelu-tiiviin aikalaatikon aikana työryhmät esittelevät keskeisiä suunnittelutuloksia, joihin kuuluvat kapasiteetti ja kuormitus, PI-luonnoksen tavoitteet, mahdolliset riskit ja riippuvuudet. Yritysten omistajat, tuotehallinta ja muut tiimit ja sidosryhmät tarkastelevat ja antavat panoksensa.
  • Management review and problem-solving-on todennäköistä, että luonnoksissa on haasteita, kuten laajuus, ihmiset ja resurssirajoitteet sekä riippuvuudet. Ongelmanratkaisutapahtuman aikana johto voi neuvotella soveltamisalan muutoksista ja ratkaista muita ongelmia sopimalla erilaisista suunnittelumuutoksista. RTE helpottaa ja pitää ensisijaiset sidosryhmät yhdessä niin kauan kuin on tarpeen, jotta voidaan tehdä tarvittavat päätökset saavutettavissa olevien tavoitteiden saavuttamiseksi.

monitaiteellisissa Ratkaisujunissa vastaava tapahtuma saatetaan järjestää ensimmäisen suunnittelupäivän jälkeen ratkaistakseen eteen tulleita poikkitaiteellisia kysymyksiä. Vaihtoehtoisesti mukana olevien junien RTEs: t voivat keskustella keskenään nostaakseen esiin kysymyksiä, jotka sitten ratkaistaan kunkin taiteen erityisessä johdon katselmus-ja ongelmanratkaisutapahtumassa. Solution Trainin Engineer (STE) auttaa helpottamaan ja ratkaisemaan eri taiteenalojen ongelmia.

päivä 2 Agenda

  • suunnittelumuutokset – seuraavana päivänä tapahtuma alkaa johdon esitellessä mahdolliset muutokset suunnittelun laajuuteen, henkilöihin ja resursseihin.
  • Team breakouts #2-joukkueet jatkavat suunnittelua edellisen päivän agendansa mukaan tehden tarvittavat muutokset. Ne viimeistelevät PI: tä koskevat tavoitteensa, joille yritysten omistajat antavat liiketoiminnan arvon, kuten kuvassa 4 esitetään.
    Kuva 4. A team ’ s PI objectives sheet with assigned business value
  • lopullinen suunnitelmakatsaus ja lounas-tämän istunnon aikana kaikki tiimit esittelevät suunnitelmansa ryhmälle. Kunkin joukkueen aikarajan lopussa joukkue ilmoittaa riskinsä ja esteensä ja antaa riskit RTE: lle käytettäväksi myöhemmin ROAMing-harjoituksessa. Sen jälkeen tiimi kysyy yrittäjiltä, onko suunnitelma hyväksyttävä. Jos suunnitelma hyväksytään, joukkue tuo team pi-tavoitelehtensä huoneen eteen, jotta kaikki voivat nähdä kokonaistavoitteet reaaliajassa. Jos yritysten omistajilla on huolia, tiimeille annetaan mahdollisuus mukauttaa suunnitelmaa tarpeen mukaan havaittujen ongelmien ratkaisemiseksi. Tämän jälkeen tiimi esittelee uudistetun suunnitelmansa.
  • ohjelman riskit – suunnittelun aikana tiimit ovat tunnistaneet ohjelman riskejä ja esteitä, jotka voivat vaikuttaa heidän kykyynsä saavuttaa tavoitteensa. Näitä ratkotaan laajemmassa johtamiskontekstissa koko junan edessä. Yksi kerrallaan riskeistä keskustellaan ja niihin puututaan rehellisesti ja avoimesti, minkä jälkeen ne luokitellaan johonkin seuraavista luokista:
    • ratkaistu-joukkueet ovat yhtä mieltä siitä, että riski ei ole enää huolenaihe.
    • omistaja – joku junassa ottaa riskin omakseen, koska sitä ei voida ratkaista PI: n suunnittelun aikana.
    • hyväksytty-jotkut riskit ovat vain tosiasioita tai mahdollisia ongelmia, jotka on ymmärrettävä ja hyväksyttävä.
    • Mitigated – joukkueet tunnistavat suunnitelman riskin vaikutusten vähentämiseksi.
  • luottamusäänestys – kun ohjelman riskit on käsitelty, joukkueet äänestävät luottamuksestaan team PI-tavoitteiden saavuttamiseen.

jokainen joukkue johtaa ”nyrkki viisi” – äänestyksen. Jos keskiarvo on kolme sormea tai enemmän, johdon pitäisi hyväksyä sitoumus. Jos se on alle kolme, tiimi laatii suunnitelman uudelleen. Jokaiselle, joka äänestää kahta sormea tai vähemmän, pitäisi antaa mahdollisuus ilmaista huolensa. Tämä saattaa lisätä riskiluetteloa, vaatia uudelleensuunnittelua tai yksinkertaisesti olla informatiivista. Kun jokainen joukkue on äänestänyt, prosessi toistetaan koko taiteen osalta kaikkien ilmaistessa luottamuksensa yhteiseen suunnitelmaan, kuten kuvassa 5 esitetään.

kuva 5. Luottamusäänestys taiteesta
  • Plan rework-tarvittaessa tiimit muokkaavat suunnitelmiaan, kunnes saavutetaan korkea luottamustaso. Tämä on yksi tilaisuus, jossa yhdenmukaistamista ja sitoutumista arvostetaan enemmän kuin aikalaatikosta kiinni pitämistä.
  • Planning retrospective and moving forward-lopuksi RTE johtaa lyhyen retrospektiivin PI: n suunnittelutapahtumaan, jossa kuvataan, mikä meni hyvin, mikä ei, ja mitä voidaan tehdä paremmin seuraavalla kerralla, kuten kuvassa 6 esitetään.
kuva 6. PI planning retrospective
  • seuraa tyypillisesti keskustelu seuraavista vaiheista sekä lopulliset ohjeet joukkueille. Tähän voisi sisältyä:
    • suunnitteluun käytettyjen Huoneiden siivoaminen.
    • tallettaa tiimin tavoitteet ja tarinat ketterään projektinhallintatyökaluun.
    • tarkistamassa joukkue-ja taidetapahtumakalentereita.
    • Iteraatiosuunnittelun ja päivittäisten stand-up (DSU) paikkojen ja ajoitusten määrittäminen.

kun suunnittelutapahtuma on tehty, RTE ja muut taiteen sidosryhmät tiivistävät yksittäiset tiimi pi tavoitteet osaksi joukko ohjelman pi tavoitteet (Kuva 7) ja käyttää tätä kommunikoida ulkoisesti ja seurata edistymistä kohti tavoitteita.

tuotehallinta käyttää pi-ohjelman tavoitteita tiekartan päivittämiseen ja parantaa ennustetta kahdelle seuraavalle Pi: lle juuri saatujen tietojen perusteella.

Ohjelmataulua käytetään usein Scrumien Scrumeissa riippuvuuksien seuraamiseen. Sitä voidaan tai ei voida ylläpitää (manuaalisesti), kun suunnittelu on valmis. Tämä riippuu käytössä olevasta ketterästä projektinhallinnan työkalusta ja taiteen tarpeista.

joukkueet poistuvat PI: n suunnittelutapahtumasta valmiiksi kasatulla iterointiruuhkalla tulevaa PI: tä varten. He vievät tiiminsä PI-tavoitteet, iterointisuunnitelmat ja riskit takaisin normaaliin työalueeseensa. Ohjelman riskit pysyvät RTE: llä, joka varmistaa, että riskin omistamisesta tai lieventämisestä vastuussa olevat henkilöt ovat ottaneet tiedon ja hallitsevat riskiä aktiivisesti.

tärkeintä on, että taide etenee PI: n toteuttamiseen seuraten edistymistä ja mukautuen tarpeen mukaan muutoksiin, joita tapahtuu uuden tiedon syntyessä. PI: n toteuttaminen alkaa siitä, kun kaikki ryhmät suorittavat suunnittelun ensimmäistä iteraatiota varten käyttäen PI-suunnitelmiaan lähtökohtana. Tämä on tuore panos iteraation suunnitteluprosesseihin, jotka seuraavat. Koska PI-suunnittelun aikana luoduissa iterointisuunnitelmissa ei otettu huomioon yksityiskohtaisia tarinatason hyväksymiskriteereitä, on todennäköistä, että ensimmäiseen ja myöhempään iterointisuunnitelmaan on tehtävä muutoksia.

Kuva 7. Ohjelma pi tavoitteet

Ratkaisujuna pi suunnittelu

tässä artikkelissa käsitellään yksittäisen taiteen suunnittelutoimintaa. Suurissa Arvovirroissa voi kuitenkin olla useita taiteita ja toimittajia. Tässä tapauksessa Ratkaisujuna koordinoi Pi: tä edeltävän suunnittelutapahtuman avulla, joka asettaa asiayhteyden ja antaa panokset yksittäisiin ART PI: n suunnittelutapahtumiin. Post-PI-Suunnittelutapahtuma seuraa ART PI-suunnittelua,ja sen avulla integroidaan ratkaisua edistävien Taiteiden suunnittelutulokset.

Kuva 8. Pre-ja Post – PI suunnittelu

Innovaatio-ja suunnittelun Iterointiartikkeli tarjoaa esimerkkikalenterin PI: tä edeltävien ja sen jälkeisten suunnittelutapahtumien huomioon ottamiseksi.

Learn More

Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Vuonna 2011. Kennedy, Michael. Tuotekehitys Lean-yritykselle. Oaklea Press, 2003.

viimeinen päivitys: 12. elokuuta 2020

tämän sivun tiedot ovat © 2010-2021 Scaled Agile, Inc. ja on suojattu Yhdysvaltain ja kansainvälisten tekijänoikeuslakien. Kuvia tai tekstiä ei voi kopioida tältä sivustolta ilman tekijänoikeuden haltijan nimenomaista kirjallista lupaa. Scaled Agile Framework ja SAFe ovat Scaled Agile, Inc: n rekisteröityjä tavaramerkkejä. Käy käyttöoikeudet Usein Kysytyt Kysymykset ja ota meihin yhteyttä käyttöoikeudet.

Tekijät

  • Dean Leffingwell –

Vastaa

Sähköpostiosoitettasi ei julkaista.