Kaikki ovat projektipäälliköitä. Olitpa sitten hallinnassa uuden sovelluksen kehittämistä ja kasvattanut aloitustasi, työskentelet uuden miljardin dollarin yritysprojektin parissa tai yrität vain piristää pihasi DIY-maisemoinnilla, hoidat projektia aina.

Projektisi menestys riippuu monista tekijöistä, mutta yksi yleisimmistä syistä, miksi projektit epäonnistuvat, on hallinnon puute tai suoraa huono projektinhallinta. Riippumatta siitä kuinka pieni tiimisi on tai kuinka selkeästi vaatimukset on dokumentoitu, jos et hallinnoi tiimiäsi oikein, projektisi epäonnistuu.

Jokainen minuutti, jonka viet projektisi hallintaan, on hyvin käytetty aika. Se tuo sinut lähemmäksi projektisi onnistunutta loppuun saattamista.

Ketterä projektinhallinta on yleisesti hyväksytty tapa lähestyä nykyaikaisia ​​ohjelmistokehitysprojekteja. Mutta mitä tekee Ketterä todella tarkoittaa?

Ketterät projektit hyväksyvät usein laajuuden ja vaatimusten muutoksen olennaisena osana prosessia.

Jos haluat syvemmälle sukeltaa ketteriin periaatteisiin, suosittelen lukemaan meidän Lopullinen opas ketterään projektiin Johto.

Tässä viestissä selitämme ketterän projektinhallinnan perusteet Kanbanin kanssa.

Vaikka olisit kokenut projektipäällikkö, joka ymmärtää ketterät periaatteet sisään ja ulos, sinun tulisi päivittää muistisi ja muistuttaa itseäsi keskeisistä käsitteistä. Innovaatiojaksot vuonna ohjelmistokehitys nopeutuvat jatkuvasti, mikä tekee projektinhallinnasta monimutkaisempaa jokaisen iteraation kanssa. Paluu takaisin ketterän toiminnan perusperiaatteisiin ja vahvistaminen on aina tärkeää. Loppujen lopuksi toistaminen on kaiken tiedon äiti.

Kanban on yksi helpoimmista tavoista hallita kaikkia ketteriä ohjelmistokehitysprojekteja. Voit helposti käsitellä paikallista kehitystiimiä, joka työskentelee samasta toimistosta tai hajautetusta tiimistä jaettuna useille aikavyöhykkeille.

Kanban ei ole prosessi. Se on tapa hallita kaikkia prosesseja muuttamalla mahdollisimman vähän tiimin vakiintunutta operatiivista toimintaa.

Kanban-periaatteiden soveltamiseksi työssäsi on noudatettava kahta yksinkertaista sääntöä:

1. Visualisoi prosessi.
2. Rajoita keskeneräisiä töitä.

Visualisoi prosessi

Tietojen visualisointi on nopea, helppo tapa välittää tietoa universaalilla ja helposti ymmärrettävällä tavalla. Kun katsot kuvia, ihmisen aivot voivat käsitellä useita tietoja samanaikaisesti. Jotkut tutkimukset sanovat, että tämä voi olla jopa 60 000 kertaa nopeampi kuin tekstin lukeminen.

Visuaalisen havaintomme aivohermosolujen osuus on 30 prosenttia aivojen harmaasta aineesta.

Suosituin tapa visualisoida prosessi on Kanban Board. Kanban Board on lauta, joka on jaettu pystysuunnassa useaan sarakkeeseen, ja kukin sarake edustaa yhtä tilaa prosessissasi.

Katsotaanpa, miltä yksinkertainen ohjelmistokehityskortti näyttäisi. Ensinnäkin meidän on määriteltävä tilat kehitysominaisuuksillemme:

1. Tehdä - ominaisuus odottaa kehitystä
2. Kehitys - ominaisuus on osoitettu kehittäjälle ja hän työskentelee sen parissa
3. Laatuvakuutus - ominaisuus on tarkistuksessa
4. Käytössä - ominaisuus hyväksytään ja sisältyy sovelluksen julkaisuun

Tämän perusteella taululla tulisi olla seuraava asettelu:

Yksittäisten tehtävien visualisointi on yhtä helppoa kuin sellaisen yksinkertaisen kortin luominen (aivan kuten Post-it), joka edustaa tehtävää työtä. Voit nimetä tehtävän, lisätä määritetyn kehittäjän nimen, eräpäivän ja kaikki muut asiaankuuluvat tiedot tälle kortille.

Kun lisäät kyseisen kortin Kanban Boardin sarakkeeseen, olet havainnut, että esimerkiksi tietty kehittäjä työskentelee tietyn tehtävän kanssa, joka erääntyy tiettynä päivänä ja on parhaillaan kehitteillä.

Rajoita keskeneräisiä töitä (WIP)

Ihmisen moniajo on harhaa. Sen sijaan, että kiinnittäisimme huomiota yhteen tai kahteen asiaan samanaikaisesti, aivomme vaihtavat niiden välillä hyvin nopeasti.

Tämä näkyy paremmin ohjelmistokehityksessä kuin missään muualla. Kehittäjät voivat työskennellä vain yhden koodikappaleen kanssa kerrallaan, ja vaihtaminen toiseen ominaisuuteen aiheuttaa viivästyksiä ja vaikuttaa niiden keskittymiseen ja suorituskykyyn.

Tämä ei tarkoita, että sinun on rajoitettava tehtävien lukumäärä vain yhteen kerrallaan. Kehitys on monimutkaista ja luovaa työtä, joidenkin tehtävien suorittaminen vie enemmän ja toisten suorittaminen vie vähemmän aikaa, ja aina viivästyy, kun kehittäjä odottaa jotain tai jotakuta. Tärkeää on rajoittaa osoitetut tehtävät kohtuulliseen määrään, joka ei tuota kaaosta (tämä on yleensä kolmesta viiteen tehtävää kerrallaan).

Olettaen, että kehitystiimisi koostuu kahdesta kehittäjästä ja laadunvarmistusinsinööristä, laudallasi voi olla seuraavat WIP-rajoitukset:

• Tehtävät - rajoittamaton
• Kehitys - kuuden kortin raja (kaksi kehittäjää, rajoitettu enintään kolmeen tehtävään)
• Laadunvarmistus - kolmen kortin raja (yksi laadunvarmistusinsinööri rajoitettu enintään kolmelle kortille)
• Käytössä - Rajoittamaton

Älä odota kehittäjien olevan viisaita, ja rajoita WIP: tä yksin. Jos heität kaiken tehtäväluettelosta kehittäjille, se on kuin antaa liian monta lelua lapselle. Yhden lelun kanssa pelaamisen sijaan he vain heittävät heidät ympäri, luoden kaaoksen siistissä kodissasi, ja silti he eivät ole onnellisia ja voit odottaa kiukkuja.

Teidän tehtävänne on projektipäällikkönä varmistaa, että tehtäväluettelo on priorisoitu oikein ja että tehtävät osoitetaan kehittäjille mahdollisimman pian.

Oikein hoidettu Kanban-hallitus antaa sinulle selkeän kuvan projektisi tilasta yhdellä silmäyksellä. Voit nähdä, että kehittäjilläsi on tarpeeksi työtä, että olet valmistellut uusia tehtäviä, jotka he voivat ottaa haltuunsa tehtävien suorittamisen jälkeen ja että laadunvalvontasuunnittelijasi odottaa uusien tehtävien tarkistamista.

Käytä Trelloa Kanban-korttisi hallintaan

Trello on verkkopohjainen Kanban-projektinhallintasovellus. Se mahdollistaa helpon, reaaliaikaisen yhteistyön tiimin jäsenten ja jopa useiden tiimien ja projektien välillä.

Luo taulu Trelloon napsauttamalla 'Luo uusi lauta ...' -valikkokohtaa ja aseta taululle otsikko.

Aloitat tyhjällä laudalla. Luo sarakkeita Kanban-korteillesi Lisää luettelo… -ruudun avulla.

Klikkaamalla minkä tahansa luettelon alaosassa olevaa Lisää kortti… -kohtaa voit luoda tehtävän helposti. Jokaisen luomasi kortin tulee edustaa tehtävää, jonka joukkueen jäsen suorittaa.

Trellon kortteja voidaan mukauttaa monin tavoin:

• Määritä ryhmän jäsenet, jotka vastaavat tehtävän suorittamisesta
• Väri koodaa ne riippuen lisättävistä ryhmistä
• Aseta eräpäivät
• Lisää liitteitä
• Lisää mukautettuja kenttiä, kuten tarkistuslista, jossa voit seurata tehtävän sisältävien pienempien elementtien etenemistä
• Tiimin jäsenet voivat kommentoida korttia, ja kaikille ilmoitetaan kaikista tehdyistä muutoksista.

Visualisointi on kaikkea Kanbanissa, joten kortti näyttää taululta seuraavasti:

Pelkästään katsomalla korttia, avaamatta yksityiskohtaista näkymää näet, että:

1. Tehtävä GitHub-koodivaraston määrittämiseksi odottaa suoritusta tehtäväluettelossa.
2. Tehtävä on määrä suorittaa 27. tammikuuta mennessä.
3. Tehtävä on kuvaus.
4. Tehtävään on yksi kommentti.
5. Kahdesta tuotteesta on tarkistuslista, eikä yksikään näistä ole tällä hetkellä valmis.
6. Tehtävä on osoitettu käyttäjälle DS, joka noutaa sen seuraavaksi.
7. Tehtävä kuuluu vihreiden värikorttien ryhmään, mikä tarkoittaa, että se vaaditaan ennen projektin aloittamista.

Arvioi kehitystyön aika ja monimutkaisuus

Projektin suunnittelu ja hallinta on mahdotonta ymmärtämättä tietyn tehtävän suorittamiseen tarvittavia vaivoja ja aikaa. Yksi vaikeimmista tehtävistä ohjelmistokehityksessä on kuitenkin määrittää, kuinka kauan uuden ohjelmistotuotteen tai ominaisuuden toimittaminen kestää.

Scrum , yksi suosituimmista ketteristä periaatteista, luottaa suuresti arvioihin, perustuvatko ne aikaan tai 'monimutkaisuuteen'.

Joukkueen tulisi käyttää paljon aikaa tehtävän selvittämiseen.

Tämä johtuu siitä, että Scrum perustuu aikarajoitettuihin aikaväleihin, jolloin tietyn tehtäväryhmän odotetaan valmistuvan. Toimituksen suunnittelua varten sinun on ymmärrettävä kaikki kyseiseen aikaruutuun suunnitellut työt.

Kanban ei luota aikarajoitettuihin toimituksiin, ja voit suunnitella päivittäisen toimituksen, jos haluat. Se perustuu työnkulun optimointiin, mikä tarkoittaa, että joukkue pyrkii täyttämään ja tyhjentämään WIP-sarakkeen mahdollisimman pian.

Tiimi ei viettää aikaa työn arviointiin paljon etukäteen. Kehittäjä hakee seuraavan kohteen tehtävälistalta; viimeistellä se mahdollisimman pian; ja poimi toinen tehtävä.

Tämä ei tarkoita, että ryhmän ei pitäisi arvioida työmääränsä määrää.

Voit päivittää ja vahvistaa eräpäivät viikoittaisten tai päivittäisten puheluidesi avulla.

Pienelle tiimille on kuitenkin tärkeämpää varmistaa, että kehittäjät työskentelevät tärkeimmän tehtävän suhteen milloin tahansa ja että pullonkauloja ei ole, mikä pakottaa kehittäjän keskeyttämään työnsä.

Lopulta projektisi kasvaa ja sinun on aloitettava arviointi kehitystyön määrästä tarkemmin. Kun pääset tähän tilanteeseen, viettää aikaa lukemaan oppaamme Ohjelmistokustannusten arviointi ketterässä projektinhallinnassa .

Pakolliset hallintokäytännöt

Toistaiseksi olet oppinut prosessin visualisoinnin ja WIP: n rajoittamisen tärkeydestä sekä siitä, miten Trelloa käytetään projektin hallintaan.

Ohjelmistoprojektia ei kuitenkaan voida hallita vain korteilla ja sarakkeilla. Siksi on tärkeää ottaa käyttöön myös ketterät parhaat käytännöt:

• Järjestä säännöllinen tiimikokous.
  Tee tämä vähintään viikoittain tarkistaaksesi, mitä on tehty, ja tarkenna ja priorisoi tarvittaessa myöhästyminen (tehtävälista). Tällä tavalla koko tiimi saa päivityksiä samanaikaisesti, ja ideoita voidaan jakaa. Näissä kokouksissa on tärkeää, että projektin sidosryhmä (asiakas, yrityksen tekninen johtaja tai joku tuotetiimistä, joka voi tehdä päätöksen ja vastata kysymyksiin) antaa lopulta muuta kuin teknistä palautetta.

• Varmista jatkuva yhteydenpito yksittäisten tiimin jäsenten kanssa.
  Tämä helpottaa jokapäiväistä työtä paljon. Pidä nämä kokoukset tai synkronoinnit hyvin lyhyinä ja yksinkertaisina, vain nopea päivitys suosikki chat-ohjelmaasi. On hyödyllistä pitää päivittäisiä sisäänkirjautumisia, mikä voi olla ~ 15 minuutin päivittäinen tapaaminen, jonka olet käynyt tiimisi kanssa. Tässä kokouksessa jokainen tiimin jäsen puhuu muutaman sekunnin ja toteaa:

• Mitä he työskentelivät eilen.
• Mitä he aikovat työskennellä tänään.
• Mitä haasteita tai pullonkauloja he kohtaavat.

Tee muistiinpanoja puhelun aikana ja kiinnitä huomiota mahdollisten ongelmien löytämiseen (estäjät, väärä keskittyminen tehtävään, odottamattomat tekniset haasteet) ja työskentele niiden kanssa tiimin kanssa.

Käynnistä ohjelmistokehitysprojekti

Vaikka jokainen ohjelmistokehitysprojekti on erilainen, on melkein kaikissa tiettyjä tehtäviä. Tässä on joitain tehtäviä, jotka sinun tulisi suunnitella aloittaessasi ohjelmistokehitysprojektia:

• Määritä koodiversio ja arkisto.
  Muutosten seuraaminen ja koodin seuranta ovat erittäin tärkeitä, varsinkin kun tehdään yhteistyötä projekteissa, joissa useat ihmiset päivittävät samaa koodia.
  
  Yksi suosituimmista koodiversiopalveluista on GitHub . GitHub on verkkopohjainen Git- tai versionhallintavarasto, joka tarjoaa kaikki Gitin hajautetut versionhallinta- ja lähdekoodihallintatoiminnot (SCM).
  
  Se tarjoaa kulunvalvonnan ja useita yhteistyöominaisuuksia, kuten virheenseurannan, ominaisuuspyynnöt, tehtävien hallinnan ja wikit jokaiselle projektille.

• Määritä tietokannan varmuuskopiointikäytäntö.
  GitHubin kaltaisten palvelujen käyttäminen varmistaa, että koodisi varmuuskopioidaan säännöllisesti.
  
  Tietokannat eivät yleensä ole osa versiojärjestelmääsi, ja sinun on määritettävä myös säännölliset varmuuskopiot.
  
  Kehitysprosessi on virheiden altis, ja on helppo tehdä virhe ja päivittää väärät tiedot kehityksen aikana. Varmuuskopion käyttäminen säästää ongelmia, jos sellainen ilmenee.

• Määritä yhteistyötyökalut ja tiedostojen jakaminen.
  Projektiasiakirjoja, toiminnallisia eritelmiä, suunnittelutiedostoja ja muita projektin kehittämisen aikana käytettyjä asiakirjoja ja tiedostoja päivitetään jatkuvasti ja ne tulisi jakaa tiimillesi.
  
  Voit käyttää useita eri palveluja näiden tiedostojen jakamiseen. Google antaa yksinkertaisen ja kustannustehokkaan ratkaisun tähän ongelmaan. Käytä tiedostoja jakamiseen ja yhteistyöhön Google Driven, Google Docsin, Google Sheetsin ja muiden Google-sovellusten avulla.

• Määritä erilliset kehitys- ja testauspalvelimet.
  Kehitysprosessin on jatkuttava koko ajan.
  
  Kehittäjien ei pitäisi odottaa sovellustestauksen tuloksia, ja heidän tulisi jatkaa tehtäviensä tekemistä, kun laadunvarmistus tarkistaa suoritetut toiminnot.
  
  Samalla asiakkaan tulee pystyä tarkistamaan sovelluksen nykytila ​​milloin tahansa odottamatta kehitystiimeä. Omistetun testipalvelimen päivittäminen säännöllisesti poistaa tämän prosessin kaikki pullonkaulat ja varmistaa, että tiimisi toimii keskeytyksettä.

• Määritä kiinteä aika viikoittaisille tiimipuheluille ja kiinteä aika päivittäisille tiimipuheluille tai keskusteluille.
  Pyydä kaikkia tiimisi jäseniä aikatauluttamaan aika kalenterissaan puheluita ja kokouksia varten. Tämä antaa tiimillesi vakaan aikataulun ilman keskeytyksiä.

Ottaa mukaan

Projektinhallinta on monimutkaista ja aivan liian usein erittäin stressaavaa toimintaa. Rakenteen lisääminen siihen ja projektin tilan tekeminen näkyväksi ja tarkaksi koko ajan lievittää suurta osaa tästä stressistä. Kanban-menetelmän ja ketterien periaatteiden käyttö yhdessä asianmukaisten työkalujen kanssa säästää paljon aikaa.

Tästä huolimatta ei ole mitään työkalua tai menetelmää, joka korvaisi ajan, jonka sinun, projektipäällikkönä, on omistettava projektin hallintaan.

Ja se, että projekti on pieni, ei tarkoita, että se vaatii välttämättä vähemmän aikaa. Tämä mentaliteetti on hieno resepti suurelle päänsärkylle.

Tässä on yksinkertainen tarkistuslista, jonka avulla voit tarkistaa, hallitaanko projektiasi oikein vai ei:

1. Onko prosessi oikein visualisoitu?
2. Onko jokaisen tiimin jäsenen WIP rajoitettu ja minimoitu?
3. Onko tiimillesi johdonmukainen kokous - joko viikoittain tai päivittäin?
4. Päivitetäänkö Kanban-korttisi säännöllisesti?
5. Onko sinulla koodivarasto paikallaan?
6. Oletko suunnitellut tietokannan varmuuskopiot?
7. Oletko asettanut tiimin viestintä- ja yhteistyövälineitä?
8. Onko kehitysympäristösi erotettu testauksesta, hyväksynnästä ja tuotannosta?

Pidä mielessä, että tämä luettelo on kaukana lopullisesta ja valmiista; Se on vasta alkua.

Jätä kommenttisi ja jaa vinkkejä ja käytäntöjä projektipäälliköiden kanssa, jotka ovat vasta aloittamassa loputtoman matkansa ohjelmistokehitystiimien voimaannuttamisesta.