Yritysten kasvaessa skaalaus Ketterä tuotekehitys kiristyy. EU: n 52%: n vastaajista 13. ketterän tilan raportti , organisaatiokulttuurin ja ketterien arvojen erot ovat heidän työnsä tärkein haittapuoli.

Organisaation johtajat pystyvät hyödyntämään ketterää kulttuuria tuotekehityksen parantamiseksi. Vankka ketterä kulttuuri sisältää tiimin autonomian lähestyessä monimutkaisia ​​ongelmia, läheistä työtä asiakkaiden kanssa sekä pitkän aikavälin visiota ja strategiaa.

Näitä abstrakteja arvoja on vaikea arvioida ja harjoittaa. Organisaatiossa tehokkaan strategian toteuttamisesta niiden hyödyntämiseksi tulee ei-triviaalia työtä. Mission Driven Development (MDD) -lähestymistapa on noussut keskivaiheen startup-yrityksistä vaihtoehtona sellaisen kulttuurin kasvattamiselle.

Haasteiden skaalaus

Skaalauksessa voi ilmetä useita hidastumismalleja. Tiimimotivaatio voi heikentyä hankkeilla, joiden loppu on epäselvä. Tuotepäälliköt voivat tuntea itsensä hukkaan operatiivisissa kokouksissa ja menettää siten aikaa strategisten tuotepolkujen suunnittelussa. Uusien ominaisuuksien ja tuotteiden käyttöönotto voi hidastua järjestelmien monimutkaistumisen myötä.

Näihin esteisiin tulisi suhtautua kulttuurisesti ja käytännöllisesti. Niiden voittaminen edellyttää hallinnasta luopumista, tiimin autonomian kasvamista, radikaalin läpinäkyvyyden toteuttamista ja tehokkaan tuotekehyksen luomista tulosten saavuttamiseksi.

Hidastuskuviot	Hallintavivut
Joukkueen motivaatio heikkenee.	Hallinnosta luopuminen ja tiimin autonomian kasvaminen
Tuotepäälliköt kokevat operatiivisten kokousten olevan hukkua.	Radikaalin avoimuuden toteuttaminen
Uusien ominaisuuksien käyttöönotto hidastuu.	Tehokkaan tuotekehityskehyksen luominen

Perinteisten ketterien kehysten skaalaushaasteet

Ketterää skaalattaessa hallinta- ja tiimitasot on synkronoitava. Johtotaso vastaa yrityksen strategian kehittämisestä, tuotevision luomisesta ja kommunikoinnista, henkilöstöpäätösten toteuttamisesta ja tiimin kehittämisen edistämisestä. Tiimitasolla suoritetaan tarvittavat tehtävät tämän vision ja strategian muuntamiseksi tehokkaasti arvokkaiksi tuotteiksi ja ominaisuuksiksi.

Perinteiset ketterät kehykset (XP, Scrum ja Kanban) on optimoitu toimimaan tiimitasolla, jolloin hallintosuhteet jäävät pääosin käsittelemättömiksi. Uusi aalto skaalatut ketterät kehykset kehittynyt täyttämään tämä aukko, ts. SAFe, LeSS, Scrum of Scrums, Nexus, DAD jne. Nämä lähestymistavat edellyttävät kuitenkin paljon suunnittelun toteuttamista ja vaivaa hallita ja ylläpitää.

Kevyt lähestymistapa, Mission Driven Development Framework antaa riittävät ohjeet vankan rakenteen toteuttamiseksi kehityksen skaalaamiseksi ja ketterien arvojen hyödyntämiseksi.

Missioihin perustuvan kehityksen ydinelementit

Tehtävät

Lähtökohtana on Mission Discovery. Liiketoiminta vie aikaa ja vaivaa, ja sen tulisi tunnistaa piilevä ongelma, ratkaisutila ja haluttu liiketoiminnan tulos. Tarkkaan määritelty missio ohjaa motivaatiota, edistää yhteistyötä ja edistää laajempien suunnittelutilojen tutkimusta.

Joukkueet

Vastuulliset toimijat kunkin tehtävän onnistumisesta ovat joukkueita. Pienet 2–4 hengen joukkueet tekevät yhteistyössä tuotepäälliköiden kanssa tarvittavat toimet toimittaa ratkaisuja, jotka sopivat tehtävän tavoitteeseen ja aikarajoituksiin.

6 viikon sykli

6 viikon aikaraja antaa kaikkien joukkueiden seurata samaa aikataulua perussuunnitteluun ja antaa samalla riittävästi aikaa merkityksellisen lopputuloksen tuottamiseen.

Puskurikausi

MDD-kehys sisältää yleensä yhden tai kahden viikon puskurijakson muun muassa lopullisiin integraatioihin ja käyttöönottoon, koulutukseen ja taitojen kehittämiseen, innovaatiotoimintaan ja seuraavan jakson suunnitteluun.

6 viikon jakson merkitys

Vaikka kuuden viikon jakso saattaa tuntua paljon joillekin ketterille harjoittajille, se sisältää useita tärkeitä etuja.

Lyhyissä jaksoissa työskentelevät joukkueet menettävät sitoutumisensa tuotteen visioon, koska heistä tuntuu siltä, ​​että he tarkistavat 'pesulistan' korjauksista, virheistä ja pienistä ominaisuuksista. Tämä uhkaa joukkueiden itsenäisyyttä tutkia ja valita paras tapa toimittaa ratkaisuja.

Syklien pidentyessä tuotteen arviointitarkkuudet pienenevät. Seurauksena on, että tuotetiimit vaativat paljon suunnittelua.

Kuusi viikkoa on kutsuttu Kullanlukot tuotteiden aikatauluista , joka tarjoaa riittävästi aikaa tuottaa minimituotteen innovatiivisella ajattelulla, nopealla prototyypillä ja jatkuvalla toimituksella.

6 viikon jakso parantaa entisestään tiimin visioihin sitoutumista hyödyntämällä autonomiaa. Mikrohallinta ei ole välttämätöntä, kunhan tehtävät on ilmoitettu selkeästi ja jaksot ovat riittävän lyhyitä, jotta joukkueet voivat keskittyä vain haluttuihin tuloksiin.

Lopuksi tuotepäälliköt voivat osallistua suunnittelutoimintaan kuuden viikon välein pitäen riittävän ennustettavuuden, jotta tiimit pysyvät tiellä kohti tehtävää. Tämän seurauksena enemmän aikaa voidaan keskittää tuotekehityksen strategisiin ja etsiviin ulottuvuuksiin.

Operaatioon perustuvan kehityksen toteuttaminen

Otetaan esimerkiksi keskivaiheen startup-yritys, jolla on B2B-tuote, joka tarjoaa verkon hinnoittelun optimoinnin, mikä lisää asiakkaiden tuloja tekoälysovellusten avulla. Yritys on äskettäin allekirjoittanut uuden rahoituskierroksen, jonka tavoitteena on vakiinnuttaa itsensä merkittävänä toimijana ja kasvattaa markkinaosuutta 300%.

Tässä skenaariossa on useita tuotekehityshaasteita:

• Kuinka nykyisiltä ja potentiaalisilta asiakkailta voidaan saada palautetta odottavan arvon hypoteesin vahvistamiseksi?
• Mitkä ominaisuudet tulisi rakentaa tai poistaa alustalta pakottavan käyttökokemuksen takaamiseksi?
• Kuinka hallintorakenne voidaan perustaa käsittelemään skaalausta ja hyödyntämään kulttuuriarvoja kasvun nopeuttamiseksi?

Loppujen lopuksi yhtiö päättää soveltaa Mission Driven Development Frameworkia välttääkseen monimutkaiset kehykset. Mission Driven Development -ohjelmassa jokaisen organisaation on määriteltävä viimeisen mailin yksityiskohdat. Tärkeimmät määriteltävät tekijät ovat:

• Tehtävän löytö
• Tehtävän rakenne
• Joukkue kokoonpano
• Tarkastus ja mukauttaminen
• Puskurin iterointi
• Kapasiteettisuunnittelu

Mission Discovery

Lähtökohtana on Mission Discovery. Tim Herbig kuvaa löytö iteratiivisena prosessina ongelman tai idean epävarmuuden vähentämiseksi sen varmistamiseksi, että oikea tuote rakennetaan oikealle yleisölle. Ennen kuin jokainen tehtävä tehdään iterointisyklissä, se on validoitava mahdollisimman kattavasti.

Mission Discovery -prosessia suorittavat erityisesti osoitetut tiimit. Löytötiimiä johtaa tuotepäällikkö, ja se koostuu tuotetutkijoista, liike-analyytikoista ja suunnittelijoista. Kun useita tuotepäälliköitä on, he raportoivat Chief Product Officerille (CPO), joka varmistaa yhteisen näkemyksen tuotteista, tuotteiden sopivuudesta ja globaalista yritysstrategiasta sekä oikea-aikaisen toimituksen.

Suositeltu lähtökohta tehtävän löytämiselle on haasteita, ongelmia tai mahdollisuuksia. Esimerkiksi haasteesta lähteminen auttaa tiimiä tutkimaan enemmän suunnittelutiloja ja lopulta laajentamaan ratkaisumahdollisuuksia.

Tehtävän vahvistus sisältää useita toimintoja, jotka auttavat yritystä ymmärtämään paremmin asiakkaiden tarpeita:

1. Markkinatutkimuksen ja kilpailija-analyysin suorittaminen
2. Ymmärtäminen ongelmatilasta, jossa tehtävä määritellään
3. Suunnittelemme heikkolaatuisia luonnoksia ja prototyyppejä
4. Tehtävän selkeän laajuuden määritteleminen
5. Asiakaspalautteen ja validoinnin kerääminen

Nämä toimet auttavat tehtävää olemaan vankka ohje kehityskeskukselle ja takaamaan, että arvo luodaan käyttäjille.

Seurauksena on, että jotkut tehtävät vahvistetaan pääsemään Mission Backlogiin, joka kehittyy jatkuvasti etsintätoimintojen ja palautteen keräämisen myötä.

Otetaan esimerkissä tämä haaste: Mitkä ominaisuudet tulisi rakentaa alustalta houkuttelevan käyttökokemuksen tuottamiseksi? Vain yksi tuotejohtajan johdolla toimiva etsintäryhmä riittäisi vastaamaan tähän haasteeseen.

Oletetaan, että tällä hetkellä esimerkkiyrityksen foorumi ottaa asiakkaan raakatiedot ja palauttaa optimoidun hinnoitteluverkon käsitellyille tiedostoille. UX-alustaa ei kuitenkaan ole optimoitu kiehtovaan kokemukseen. Tavoitteena on tässä vaiheessa selvittää, tuleeko asiakasarvo UX: n parantamisesta, uusien ominaisuuksien kehittämisestä tai alustapalveluiden parantamisesta.

Ensimmäisen markkinatutkimuksen jälkeen päätetään kehittää uusia ominaisuuksia. Alustan ehdokkaan ominaisuudet ovat:

• Erittäin nopea uudelleenhinnoittelu
• Nopea ja reagoiva käyttöliittymä
• Älykkäät ja edistyneet hinnoittelusäännöt
• Hinnoittelu ja myyntihistoria

Löytötarkoituksia varten yhtiö päättää suorittaa a suunnittelu sprintti lähestymistapa: viiden päivän prosessi kriittisiin yrityskysymyksiin vastaamiseen suunnittelun, prototyyppien tekemisen ja ideoiden testaamisen kanssa käyttäjien kanssa. Hakuprosessi suoritetaan jokaiselle ehdokasominaisuudelle, jotta voidaan nähdä, mikä luo enemmän arvoa nykyisille ja potentiaalisille asiakkaille. Kehitykseen valittu tärkein ominaisuus on älykkäät ja edistyneet uudelleenhinnoittelusäännöt.

Tehtävän rakenne

Vankan tehtävämäärityksen saavuttaminen ei ole triviaali tehtävä. Sen on kuvattava selkeä liiketoimintahaaste ja asetettava rajat tulokseensa, samalla kun se antaa riittävästi tilaa joukkueille innovatiivisen ja tehokkaan ratkaisun löytämiseen. Selkeä ja tarkka tehtävä:

• Ilmaisee selkeästi liiketoiminnan haasteen, kun se on tunnistanut ja määrittänyt ongelmatilan.
• Syntetisoi kaikki edellisissä vaiheissa löydetyt tiedot ja oivallukset.
• Linkit haluttuun liiketoiminnan tulokseen.
• On tuloslähtöinen, mikä osoittaa selvästi kuvan operaation onnistumisesta.
• On realistinen ja saavutettavissa 6 viikon syklimahdollisuuden puitteissa.
• On riittävän kapea tarkennuksen takaamiseksi ja riittävän leveä, jotta se pysyy poissa yksityiskohdista.

Esimerkissä viikon löytämisen jälkeen tiedot ja käyttäjien palaute on kerätty ja syntetisoitu.

Kohdekäyttäjä: Asiakkaan hinnoitteluanalyytikot.

Ongelma tila: Käyttäjät haluavat pystyä asettamaan ja hallitsemaan älykkäitä ja edistyneitä hinnoittelusääntöjä, jotta he voivat säätää hinnoittelua automaattisesti tietyissä olosuhteissa.

Arvokkaimpia sääntöjen ehtoja ovat kilpailijan hinta, toimituksen kiireellisyys, tilausten kokonaismäärä, käytettävissä oleva varasto ja alennus premium-asiakkaille.

Oivalluksia: Sääntöjä tulisi käyttää mukautetuissa prioriteeteissa, ja niitä olisi tarvittaessa muokattava.

Analyytikot haluavat helposti nähdä, mitä sääntöjä sovelletaan tiettyyn aikaan tiettyyn tuotteeseen.

Haluttu liiketoiminnan tulos: Lisää käyttäjän alustan sitoutumista 25% mitattuna alustalla vietetyllä ajalla.

Joukkueen kokoonpano

Joukkueen muodostamisprosessi tehdään tapauskohtaisesti jokaiselle kehitysvaiheelle. Tiimin autonomia ja itseorganisaation periaatteet ovat edelleen keskeisiä. Joukkueen kokoonpanoa ohjaa joukko tekijöitä, jotka vaihtelevat tehtävän monimutkaisuudesta, kehittäjien ja suunnittelijoiden taidoista, kiinnostuksen kohteista ja joukkueiden kemiasta.

Joukkueen muodostumisprosessia helpottavat ketterät valmentajat. Jokaiselle henkilölle kysytään ennen päätöstä minkä tyyppistä työtä he haluaisivat tehdä seuraavan kuuden viikon aikana. Sitten joukkueet rakennetaan kokemuksen, tiedon ja taitojen perusteella varmistaen, että heillä on tarvittavat tiedot ja taidot menestyä tehtävässä.

Ketterät valmentajat työskentelevät useiden joukkueiden kanssa kehitysjakson aikana auttaen heitä nostamaan esteitä ja riippuvuuksia. Kun olemassa on useita ketteriä valmentajia, he raportoivat ketterän johtajalle, joka vastaa joukkueiden kokoonpanosta, jatkuvasta parantamisesta ja ketteristä tuotteiden toimituksista.

Ryhmän suositeltu koko on 2-4 henkilöä: yleensä yksi suunnittelija ja yksi tai kaksi kehittäjää tehtävän monimutkaisuudesta riippuen. Laadunvarmistusinsinöörin katsotaan avustavan yhtä tai useampaa ryhmää haluttujen laatustandardien saavuttamisessa.

Joukkueet sekoitetaan usein jokaisen jakson jälkeen, joten jokainen voi tehdä yhteistyötä eri ihmisten kanssa, levittää tietoa ja työskennellä eri tuotemittojen suhteen, vaikka tehokkaat joukkueet voivatkin toimia yhdessä muutaman jakson ajan.

Esimerkin ryhmän tulee ottaa huomioon käyttäjät, joilla on käyttöliittymän suunnittelu, tietojenkäsittely ja tietojen visualisointi.

Syklin tarkastaminen ja mukauttaminen

Ketterien valmentajien tulisi jatkuvasti kannustaa avoimuutta, tarkastusta ja sopeutumista tavallisten ketterien käytäntöjen avulla.

Lyhyitä viikoittaisia ​​kokouksia pidetään työn organisoimiseksi ja esteiden ja riippuvuuksien lisäämiseksi. Hoito tehdään tarvittaessa sen varmistamiseksi, että joukkueet ymmärtävät täysin tehtävän ja käyttäjätarinat. Lyhyet retrospektiivit tehdään jokaisen viikon lopussa muutosten ja parannusten tunnistamiseksi ja toteuttamiseksi.

Jatkuvia toimitustapoja tulisi ylläpitää koko syklin ajan. Tehtävän tavoite voidaan saavuttaa aikaisemmin, koska 6 viikon sykliaikataulu on poljinnopeuteen perustuva lähestymistapa perussääntöjen asettamiseen ja auttaa samalla ennustamaan joukkueita.

Hyvä käytäntö avoimuuden lisäämiseksi on demo neljännen viikon lopussa, joka perustuu joukkueiden ja tuotepäälliköiden väliseen sovittuun virstanpylvääseen. Näiden demojen tavoitteena on mukauttaa, vähentää tai laajentaa soveltuvuutta tarpeen mukaan.

Esimerkkitehtävässä joukkue ja tuotepäällikkö ovat sopineet julkaisusuunnitelmasta neljässä eri julkaisussa:

1. Julkaisu 1:
   • Uusi sääntöominaisuuden käyttöliittymä
   • Kilpailijan hintaa koskevat säännöt
2. Julkaisu 2:
   • Lähetyksen kiireellisyys
   • Tilaa kokonaissääntö
   • Sääntöjen painopisteet
3. Julkaisu 3:
   • Käytettävissä oleva varastosääntö
   • Visualisointisovellussääntö
4. Julkaisu 4:
   • Alennus premium-asiakkaille

Julkaisu 3 on sovittu demoksi neljännelle viikolle. Koska julkaisut on toteutettu koko kehitysjakson ajan, toivottua liiketoiminnan lopputulosta (tässä tapauksessa käyttäjien sitoutumista) tulisi seurata siitä hetkestä lähtien, kun kehitysjakso alkaa. Graafisesti edistyksen odotetaan olevan seuraava:

Puskurikausi

Yhden tai kahden viikon käyttäminen puskurijaksona on käytäntö, joka toistetaan Mission Driven Development -toteutusten sekä muiden skaalausmenetelmien, kuten SAFe, kautta.

SAFe-ohjelmassa innovaatio ja iteroinnin suunnittelu tehdään jokaisessa kehitysvaiheessa. Se toimii kontekstinvaihtajana, mikä mahdollistaa etsintä- ja innovaatioprosessit ja -toiminnot, jotka yleensä jätetään muiden toimitukseen keskittyvien kehysten ulkopuolelle. Esimerkkejä tällä puskuriviikolla toteutetuista toiminnoista:

• Ratkaisun lopullinen integrointi . Kun laitetta otetaan käyttöön kuuden viikon jakson loppupuolella, on todennäköistä, että integrointi, todentaminen, dokumentointi ja vahvistus ovat edelleen odotettavissa. Erityinen aika auttaa varmistamaan uusien ratkaisujen tehokkaan ja sujuvan integroinnin olemassa oleviin tuotteisiin.
• Tehtävien suunnittelu ja priorisointi . Tehtävät tarkennetaan, luokitellaan pieniin tai suuriin eriin ja priorisoidaan seuraavalle kehitysvaiheelle. Kun priorisoidaan tehtäviä, jotkut yritykset toteuttavat pikipäiviä, joiden aikana tärkeimmät tehtävät esitellään yritykselle ja sitten - yhteistyössä - sitoutuvat seuraavaan kehitysjaksoon.
• Hackatonit . Hackathonit ovat saaneet kasvavaa suosiota startupien ja yritysten keskuudessa, koska ne kykenevät edistämään innovaatioita, luomaan yhteisöä ja rakentamaan uutta tietoa ja taitoja hauskalla tavalla. Tulokset esitellään muille, ja niistä tulee ehdokkaita lähetystyöhön.
• Kokeellinen prototyyppien kehittäminen tai sivuprojektit . On yleistä käytäntöä, että insinööreille ja suunnittelijoille annetaan aikaa työskennellä mitä he päättävät, kunhan he osoittavat tehdyn työn puskuriajan lopussa.
• Suunnittelutyö . Puhtaat suunnittelutyöt, kuten infrastruktuurin kehittäminen, testausautomaatio, teknisen velan vähentäminen ja järjestelmien siirrot, tehdään yleensä.
• Uusien taitojen ja tietojen kehittäminen . Tietämyksen nopea kehitys pakottaa kehittäjät pysymään ajan tasalla globaaleista trendeistä. Puskuriaika soveltuu mm. Paikan päällä tapahtuvan koulutuksen, käytäntöyhteisöjen ja teknologiapajojen pitämiseen.

Puskurikausien tulisi perustua havaittuihin tietovajeisiin, innovaatiotavoitteisiin ja seuraavan syklin tarpeisiin. Esimerkiksi yhden viikon puskurijakso voi näyttää tältä:

	maanantai	tiistai	keskiviikko	torstai	perjantai
OLEN	Lopulliset integraatiot	Edellinen sykli retrospektiivinen	Hackathon	Hackathon-esittely	Lähetyskierrospäivä
P.M	Dokumentointi	Koulutus ja työpajat		Koulutus ja työpajat	Seuraava iterointisuunnittelu

Kapasiteettisuunnittelu

Kun päätetään tehtävän sitoutumisesta seuraavaan kehitysjaksoon, on käytettävä yleistä käytäntöä, mukaan Basecampin perustaja Jason Friedille on ensin tunnistaa pienet tai suuret erät. Suuret erät viittaavat suuriin tuoteominaisuuksiin tai toiminnallisuuksiin, kun taas pienet erät viittaavat pienempiin iteraatioihin tai tehtäviin. Annetussa esimerkissä uuden ominaisuuden valittua tehtävää voidaan pitää suurena eränä.

Suositus on tässä suoraviivainen: aina on sekoitus pieniä ja isoja eriä. Pienet erät ovat tehtäviä, joiden arvioidaan kestävän 3-4 viikkoa, ja suuret erät voivat kestää kuusi viikkoa tai enemmän.

Jos pieni eräjoukkue on suorittanut tehtävänsä viikkoon 3 tai 4 mennessä, sovittu esittely on mahdollisuus arvioida, pitäisikö ryhmän jatkaa työskentelyä toteutetun ratkaisun parantamiseksi, auttaa toista ryhmää, ottaa uusi pieni erä vai aloittaako suunnittelematon työ.

Hyvä sekoitus suuria ja pieniä eriä estää ihmisiä työskentelemästä 100%: n kapasiteetilla, mikä antaa heille mahdollisuuden liikkua ja sopeutua suunnittelemattomaan työhön. Suuret joukkueet keskittyvät syklin aikana mahdollisimman paljon, kun taas pienet joukkueet voivat käsitellä odottamattomasta työstä johtuvia tapauskohtaisia ​​tehtäviä.

Pienten ja isojen erien yhdistäminen vähentää myös riskiä. Vain suuret erät voivat lisätä todennäköisyyttä vaikuttaa kielteisesti käyttäjäkokemukseen. Jos useita uusia ominaisuuksia julkaistaan ​​lähellä toisiaan, niiden mukana tulisi olla hyvä muutosten hallinta. Lisäksi suunnittelemattomissa töissä kapasiteettia on vähemmän. Lopuksi, jos useat isot joukkueet epäonnistuvat, iterointi voidaan pitää tuottamattomana ja demoralisoida joukkueet.

Missioihin perustuvan kehityksen riskit

Operaatioon perustuvan kehityksen toteuttamisesta on monia etuja, mutta kuten kaikilla ohjeellisilla puitteilla, sillä on useita luontaisia ​​riskejä, jotka on otettava huomioon.

Tehtävä

Tehtävien tulisi olla realistisia, ja niillä olisi pyrittävä sopimaan haasteen monimutkaisuuden ja joukkueen taitojen välillä. muutoin vaikutus kehitystuloksiin voi olla merkittävä.

Liian kunnianhimoinen tehtävä voi herättää turhautumista ja ahdistusta, mikä vaikuttaa negatiivisesti joukkueen suorituskykyyn. Toisaalta intohimoinen tehtävä voi aiheuttaa joukkueiden demotivaatiota ja ikävystymistä. Täten vähimmäiskelpoisen tuotteen mentaliteetin tulisi pysyä vakiona kehyksessä.

Mission tehtävä

Vankoilla liiketehtävillä tulisi olla kattava määritelmä ongelmatilasta ja sen suhteesta yrityksen visioon. Jos tämä suhde ei ole selvä, arvokkaita oivalluksia voi menettää, koska ymmärrys puuttuu siitä, miten ongelmanratkaisu vaikuttaa yrityksen tavoitteisiin.

Vesiputousloukku

Putoaminen malliin kuuden viikon aikana on luonnollinen taipumus joukkueille. Tähän on kaksi päätekijää. Ensinnäkin käyttöönottopaine on voimakkaampi syklin lopussa. Toiseksi joukkueet haluavat purkaa mahdollisimman paljon mahdollisuuksia operaation sisällä, mikä johtaa kiireelliseen käyttöön kehitysjakson lopussa. Siksi jatkuvia toimitustapoja tulisi kannustaa ketterien päästöjen saavuttamiseksi koko syklin ajan ja vesiputouksiin liittyvien riskien välttämiseksi.

Tuotteen käyttö

Tuotteiden käyttötehtävät, kuten infrastruktuurin, palvelujen tai komponenttien hallinta, tulisi pitää ryhmien ulkopuolella, koska ne voivat vaikuttaa nopeuteen. Luotetaan kehitysstandardeihin ja käytäntöihin, kuten atomisuunnittelu vähentää kehitystyötä ja siten nopeuttaa skaalausta. Toinen yleinen käytäntö tämän kehyksen puitteissa on keskeinen operatiivinen tiimi, joka hoitaa infrastruktuuria tuotetoimintojen hallinnan ja valvonnan lisäksi.

6 viikon sykli myooppisena kehyksenä

Jotkin skenaariot eivät sovi kehykseen. Tämä tulee erityisen totta käsiteltäessä suuria ja monimutkaisia ​​järjestelmiä, joilla voi olla valtava vaikutus asiakaskokemukseen, kuten tutkimus- ja kehitysprojektit tai kriittisten järjestelmien siirtyminen.

Kevyt vaihtoehto ketterän skaalaus

Ketterän skaalaus tuotekehityksen ja yrityksen kasvun vauhdin ylläpitämiseksi on piilevä haaste ketterille ammattilaisille. Äskettäin kehitetyssä ketterässä lähestymistavassa Mission Driven Development -kehys on saavuttanut suosiota yritysten keskuudessa sen helppokäyttöisyyden ja toteutuksen vuoksi. MDD-kehys käynnistää läpikotaisin, poikittaisen tuoteinnovaatioprosessin keksinnöstä toimitukseen, joka täyttää aukot perinteisissä ketterissä rakenteissa. Mission Driven Developmentilla on potentiaalia olla uusi Scrum kasvaville yrityksille.

Perustietojen ymmärtäminen

Mitkä ovat erilaiset ketterät kehykset?

Eri tilanteisiin sopivia ketteriä kehyksiä on paljon. Yhden tai muutaman joukkueen perinteisiä kehyksiä ovat Scrum, Kanban ja XP. Skaalatut ketterät kehykset sisältävät SAFe, LeSS, DAD, [sähköposti suojattu] , Tehtävälähtöinen kehitys jne.

Mitkä ovat normaalin kehitysvaiheen vaiheet?

Normaali kehitysjakso SDLC: n mukaan koostuu suunnittelusta, analysoinnista, suunnittelusta, toteutuksesta ja ylläpidosta.

Mitkä ovat tuotekehitysprosessin kuusi vaihetta?

Tuotekehitysprosessin kuusi vaihetta ovat ideoiden luominen, markkinatutkimus, konseptikehitys, tuotesuunnittelu ja -kehitys, testaus ja lanseeraaminen.

Mitkä ovat projektisyklin vaiheet?

Projektisyklin viisi vaihetta ovat aloittaminen, suunnittelu, toteutus, seuranta ja päättäminen.

Mitkä ovat projektisyklin elementit?

Projektisyklin elementit ovat laajuus, resurssit, aikataulu, laatu ja riskit.