Ohjelmistotuotanto ei ole nykyään sama kuin 20 vuotta sitten. Ohjelmisto on tullut yhä monimutkaisemmaksi, sillä hajautetut tiimit ovat kirjaimellisesti ympäri maailmaa ja riippuvaisia ihmisistä, jotka ovat erikoistuneet vain tiettyyn prosessin osaan. Lisäksi käyttöliittymästä / käyttöjärjestelmästä on tullut erittäin tärkeä asia, kun kilpailu uusien käyttäjien vangitsemisesta ja nykyisten käyttäjien säilyttämisestä lisääntyy.
Kuluneen vuoden aikana olen työskennellyt tusinan verran projekteja ja melkein kaikki niistä käyttivät projektia projektinhallintatyökalu (PMT). En aio antaa sinulle myyntipistettä yhdelle tietylle työkalulle tänään, vaan annan sinulle kehittäjän näkökulmasta sisäpiirin siitä, miten näitä työkaluja käytetään tosielämässä, sekä yleiskatsauksen kahdesta edustajasta työkalut. Toivottavasti tämä artikkeli auttaa päättäjiä ja kehittäjiä selvittämään, mikä on mukavinta heille, heidän tiimilleen ja projektille, jolla he työskentelevät.
Kun aloitin, suurin osa projekteistani ei ollut riippuvainen projektinhallintatyökalusta, joten saatat kysyä, tarvitsetko sitä todella. Eivätkö kehittäjät voi vain luoda ohjelmistoja ilman niitä? Vastaus on, että se riippuu useista tekijöistä, joten analysoimme joitain niistä.
Useimmissa projekteissa työskentelen ihmisille ympäri maailmaa, ja vaikka se on todella mahtavaa, se asettaa myös useita haasteita, joita toimistotiimi ei kohta. Aikavyöhykkeistä tulee todellinen ongelma, kun yrität saada kollegan korjaamaan tai muokkaamaan jotakin järjestelmän osaa, jossa et ole riittävän taitava.
On myös skenaarioita, joissa et ehkä voi puhua toisen kehittäjän kanssa useammin kuin kerran tai kahdesti viikossa. Projektinhallintatyökalut auttavat tekemään tällaisista yhteistyöprosesseista helpompia, koska niistä tulee virallinen (ja käytännön syistä joskus ainoa) kanava tiimin jäsenille viestimään tarpeistaan edestakaisin.
Kyse ei tietenkään ole pelkästään hajautetun tiimin yksittäisten jäsenten välisestä viestinnästä. PMT: t tarjoavat myös enemmän tietoa ja näkyvyyttä kaikille tiimin jäsenille, jolloin he voivat seurata muiden tiimin jäsenten edistymistä ja suunnitella toimintaansa sen mukaan.
Saatat ajatella, että saat samat tulokset yksinkertaisesti tekemällä yhteistyötä sähköpostitse tai muilla viestintäkanavilla. Minun asiakkaani teki sen projektissa, jossa työskentelin muutama kuukausi sitten, ja se oli painajainen. Ihmiset käyttivät useita sähköpostiviestejä viestintään, joten oli vaikea seurata eri ketjuja. Myös viestinnästä yksittäisestä numerosta tulee palapeli, joka on jaettu eri paloihin, jotka elävät eri sähköpostikeskusteluissa. Useimmat sähköpostikeskustelut koskettivat useita asioita, mikä vaikeutti ja vaikeutti jäljittää tehtävää.
Projektinhallintatyökalut ratkaisevat tämän siten, että jokaiselle numerolle on omistettu yksi keskustelu, mikä helpottaa elämääsi, koska niiden avulla löydät kaiken tarvitsemasi (mallit, sovellusliittymät ja palaute) yhdellä napsautuksella. Yhteistyön näkökulmasta tämä voi olla valtava ero, koska projektinhallintatyökalut antavat kaikille mahdollisuuden käyttää ja tarkastella kaikkia projektin segmenttejä ja vaiheita, mikä vähentää jatkuvan viestinnän ja päivitysten tarvetta.
Yksi suurimmista ongelmista, joita kohtaavat tiimit, jotka eivät käytä projektinhallintatyökalua, johtuu ohjelmiston luonnosta. Ehkä työskentelet käynnistysvaiheessa ja olet kääntänyt enemmän kuin pari kertaa. Ehkä tavoitteet ja vaatimukset muuttuvat jatkuvasti, kun työskentelet projektissa.
Tässä yhteydessä meidän pitäisi ajatella ohjelmistoja elävänä olentona. Riippumatta siitä, kuinka hyvin alkuperäinen suunnitelma laadittiin, on aina hyvät mahdollisuudet muuttaa sitä. Joskus näitä muutoksia ei kuitenkaan ilmoiteta kaikille tiimin jäsenille. Johtajat voivat keskustella uudesta ominaisuudesta, joka antaa sinulle edun kilpailijoihisi nähden, mutta jos johtaja ei ilmaise tätä muulle joukkueelle, niin ei käy.
Jos sitä ei kirjoitettu ylös, myös johtaja ja toimitusjohtaja saattavat unohtaa sen. Jos sinulla ei ole paikkaa, jossa sinulla on uusimmat ja viralliset vaatimukset, menetät paljon aikaa ja rahaa. PMT: t tarjoavat yhden totuuspisteen, yhden paikan, jossa kaikki vaatimukset ja tiedot tallennetaan projektin ajaksi. Kyse ei ole vain ominaisuuksista, joita ei lisätä, ja voit lisätä ne myöhemmin - olen kehittänyt kokonaisia ominaisuuksia vain huomatakseen, että minulle ei kerrottu, ettemme enää tue kyseistä ominaisuutta.
Halvin muste on luotettavampi kuin tehokkain muisti. - Sananlasku
Voimme käsitellä vain niin paljon päämme kerrallaan. Kun sinulla on puhelu johtajien kanssa, ja he ottavat keskustelun aikana esiin tusinaa erilaista ongelmaa, jossain vaiheessa jotain menetetään. Voit yrittää kirjoittaa tärkeimmät kohdat itse, mutta silti jotain voi pudota halkeamien läpi.
Vaatimusten kirjoittaminen sen sijaan, että puhuisit niistä puhelussa, on hyvä tapa saada kiinni mahdolliset puuttuvat elementit virtauksesta tai havaita asioita, jotka saattavat estää sinua toteuttamasta kyseistä ongelmaa tällä hetkellä. Ohjelmistokehitys ei ole lineaarista, joten voit alkaa työskennellä jonkin ominaisuuden kanssa tänään, mutta sinulla on jotain kiireellisempää työtä tuotteessa ja palaat pari viikkoa tai kuukautta myöhemmin vain huomataksesi, että olet unohtanut, mitä tarkalleen vaaditaan.
Siksi vaatimusten kirjoittaminen muistiin voi säästää aikaa joko välttämättä muistaa tai välttämällä saman ominaisuuden uudelleen keskustelua. Aikatehokkuus on erittäin tärkeää, koska ohjelmisto on monimutkaisempi, joten voit hyödyntää vain asioiden kirjoittamista muistiin, lyhentää kokousaikasi puoleen tai enemmän keskittymällä vain ongelmiin, jotka sinun on selvitettävä.
Tämä liittyy edelliseen kysymykseen, joka koskee seurattavaa ongelmaa koskevaa viestintää ja vain tulevaisuuden vaatimusten ominaisuuksien seuraamista ilman, että sinun tarvitsee puhua näistä asioista.
Tämä auttaa kehittäjää pitämään keskittymän luomaan tällä hetkellä tarvittavia asioita ja oppimaan, mitä seuraavaksi tulee. Kyse ei ole vain tietojen mukavuudesta ja helposta saatavuudesta. Lisätty näkyvyys antaa jokaiselle tiimin jäsenelle mahdollisuuden nähdä kokonaiskuvan ja suunnitella sitä eteenpäin.
Joten, mitä etsimme PMT: stä, on työkalu, joka auttaa hallitsemaan keskustelua pitämällä keskustelun eri asioista erillisinä ja hyvin järjestettyinä. Se auttaa viestintää eri aikavyöhykkeillä olevien ihmisten ja eri tiimien välillä ja toimii samalla ohjelmiston virallisen vision arkistona, mikä auttaa sinua pitämään keskittymisen ja säästämään aikaa vähentämällä kitkaa kehittäjän, projektipäällikön , ja kaikki, jotka ovat mukana tämän päivän ohjelmistokehityksessä.
Jira on erittäin tehokas PMT, joka on suunniteltu erityisesti ohjelmistokehitykseen. Kaikki eivät kuitenkaan tiedä kaikkia Jiran ominaisuuksia, ja se voi olla ylivoimainen, jos olet yrityksen omistaja ja yrität hallita ensimmäistä projektiasi. Jos luet tätä henkilöä, joka päättää eri vaihtoehtojen välillä, mutta et ole vielä käyttänyt Jiraa, suosittelen ensin katsomaan joitain oppaita, jotta voit todella hyödyntää sen voimaa.
On kolme sanaa, joilla voin määritellä suurimman osan kokemuksestani Jirasta, ja yksi niistä on sprintti . Sprintti on ajanjakso, jonka aikana joukkue pyrkii saavuttamaan tietyt tavoitteet, jotka voivat olla läheisesti yhteydessä toisiinsa. Se on täysin joustava. Jira-sprintit kestävät tyypillisesti viikon, mikä on mielestäni optimaalinen kesto.
Kehittäjän näkökulmasta tämä antaa sinulle joustavuuden antaa sinulle useita asioita ja työskennellä sinulle parhaiten sopivassa järjestyksessä, joka voi olla vaikea työ ja sitten helppo rentoutua tai ehkä työskennellä 2 -3, jotka liittyvät läheisesti samaan aikaan. Tämä antaa kehittäjille mahdollisuuden tehdä joitain päätöksiä samalla kun keskitytään samalla toimitukseen ajoissa.
Vaikka pikajuoksi ryhmätehtäviä ajallisessa valtakunnassa, eepot osaa ryhmitellä tehtäviä aiheen mukaan. Voit esimerkiksi jakaa tehtävänsä sprintteihin viikossa, mutta voit myös ryhmitellä tehtävät samanaikaisesti käyttöliittymään ja loppupäähän. Kun jaat tehtäviä aiheen mukaan, voit määrittää kehittäjän aiheeseen.
Sinulla voi olla esimerkiksi eepos tietojen siirtämiseksi olemassa olevasta tietokannasta, joten voit kutsua sitä eeppistä DB Migration -palvelua, ja koska kaikki eepoksen tehtävät liittyvät toisiinsa, yksittäinen kehittäjä voi olla siitä vastuussa kaikkien ohjelmien aikana. sprintit. Näin vältetään kahden kehittäjän viettämästä aikaa vanhan tietokannan oppimiseen, mikä tekee kehityksestä tehokkaampaa.
Kysymykset Toisaalta on tehtävä asioita, jotka voivat kuulua eepokseen ja sprinttiin. On olemassa useita erityyppisiä asioita ja ne ovat tarina , tehtävä ja vika . Tarinalla on erityispiirre siitä, että sillä on alitehtäviä, joita voidaan käyttää ongelman hajottamiseen pienempiin paloihin, jotka muodostavat kokonaiskuvan yhdessä otettuna - tämä välttää suuren määrän tehtävien luomista sen sijaan, että keskitytään yhteen suoritettavaan kohteeseen.
Jiran tehtävät ovat asioita, jotka ovat hyvin tarkkoja ja joilla ei ole alitehtäviä. Kun jokin tehtävä on hyvin suoraviivaista ja sitä ei ole järkevää yrittää hajottaa, se on tehtävä. Virheet ovat korjattavia asioita - virheiden pitäminen erityisluokana auttaa sinua ymmärtämään, kuinka paljon korjaat, verrattuna projektien etenemiseen.
Viestintä on iso osa yhtälöä, kun työskentelet globaalissa tiimissä, joka toimii useilla aikavyöhykkeillä. Työskentely 'ympäri maailmaa' ei ole metafora, vaan todellisuus, jossa monet kehittäjät elävät. Yksi asioista, joita on vaikea kommunikoida johtajilta kehittäjille, on tehtävän ensisijainen taso. Kuvittele seuraava skenaario käyttämällä todoluetteloa:
Kehittäjä näkee, että tällä viikolla heillä on seitsemän tehtävää. Jotkut niistä ovat vaikeita ja toiset helppoja. Yksi kriittinen tehtävä johtajalle on kuitenkin hyvin monimutkainen, mutta todelistaluettelon kehittäjälle kaikki tehtävät ovat tasa-arvoisia - he saattavat päättää siirtyä ensin helpompiin, jättäen kriittisen tehtävän loppuun. Jos tapahtuu jotain odottamatonta ja luettelo ei pääse loppuun, se on tärkein tehtävä, joka leikataan tai se valmistuu nopeasti (todennäköisesti laadun uhraaminen prosessissa). Tämä on helppo ratkaista Jirassa painopisteet , jonka avulla kehittäjät ymmärtävät tärkeämmän tai kriittisemmän suoritettavan.
Yksi niistä asioista, joita todella arvostat Jirassa, on sisällön määrä, jonka voit sijoittaa kuhunkin numeroon; Voit lisätä kuvia tai linkkejä sekä merkitä muita ryhmän jäseniä - vaikka tämä pätee myös Trelloon, käyttöliittymä todella houkuttelee sinua sijoittamaan enemmän sisältöä, mikä auttaa saamaan enemmän tietoja kustakin tehtävästä.
Jira on erittäin vakiintunut työkalu, jolla on paljon ominaisuuksia, jotka on sisällytetty nimenomaan ohjelmistokehitykseen. Se tarjoaa joukon integraatioita muihin järjestelmiin ja auttaa pitämään hyvin järjestäytyneenä. Se on erityisen hyvä (erittäin) suurille joukkueille.
Jira, koska hän on kykenevä, monipuolinen PMT, voi olla hieman pelottava aloittelijoille. Kokemus voi olla ylivoimainen - sprintit, eepot ja ongelmat voivat sulautua yhteen. Tämä pätee erityisesti, jos johtaja on asiakas, jolla on vähän kokemusta ohjelmistokehityksestä ja joka yrittää hallita kehittäjäryhmää. Suosittelen Jiraa suurille ryhmille ja suurille projekteille, joiden kehittäminen kestää jonkin aikaa (yli pari kuukautta), sekä kokeneille esimiehille (asiakkaille) ja kehittäjille.
Trello voidaan tiivistää yksinkertaisella lauseella: 'kortit sisältävä lauta', alias. Kanban . Ensi silmäyksellä se voi jopa olla liian yksinkertainen kouluttamattomalle silmälle; yksinkertaiset asiat voivat kuitenkin olla erittäin hyödyllisiä.
Yksinkertaisuus on tehokas käsite. Tämä on osa syytä, miksi iPhone ja Mac tulivat niin suosituiksi, koska niiden käyttöjärjestelmä oli yksinkertainen ja iloinen käyttää. Vaikka Jiralla tuntuu siltä, että hänellä on jokainen ajateltava asia, Trellolla tuntuu siltä, että hänellä on vain tarpeeksi saadaksesi sinut läpi. Ei eeposia, ei tarinoita, ei sprinttejä - työskentelet yksinkertaisesti kortilla ja siirrät sen läpi eri vaiheiden (sarakkeiden).
Ottaen huomioon, että kaikki nämä ovat olemassa myös Jirassa, selitän muutamia ominaisuuksia, jotka loistavat eniten Trellossa.
Trello tekee määritelmän Tasot erittäin helppoa - luo vain sarake ja aloita sen käyttö. Yleisimmät ovat Tehtävä, Tehtävä, Tarkastus ja Valmis. Yksinkertaisuutensa vuoksi voit lisätä muita sarakkeita, kuten On Hold (Jira voi myös tehdä tämän, mutta tuntuu siltä, että ne ovat kadonneet, ellet etsi nimenomaisesti näitä asioita) tai luoda sarakkeita järjestelmän eri osille, kuten Todo Front-end tai Todo Back-end. Tämä on erinomaista, kun joukkue ja projekti ovat pieniä, kuten yksinkertainen verkkosivusto, widget tai laajennus, jossa ei ole paljon jäseniä tai tehtäviä, joita voidaan hallita samanaikaisesti.
Voit määrittää kortin jäsenille ja näin voit antaa kortin kehittäjälle - siellä se on hyvin yksinkertaista. Voit merkitä myös muita jäseniä kommentteihin, mikä auttaa kaikkia asiaan osallistuvia kommunikoimaan asiasta jatkuvasti.
Yhdellä napsautuksella käyttäjät voivat helposti suodattaa korttinsa tai muille tiimin jäsenille kuuluvat kortit, mikä on erityisen kätevää Kalenterinäkymässä.
Trellon yksinkertaisuuden vuoksi Kanban on näkyvissä aina, kun avaat kortin sisällön. Se on hyvin visuaalinen lähestymistapa, koska et voi välttää tätä näkymää. Korteissa voi myös olla kuvia, jotka näkyvät taululla.
Tätä Jiralla ei ole (tai ainakaan en ole nähnyt sitä käyttävän todellisessa projektissa). Koska kuva voi sanoa enemmän kuin sanoja, voit helposti nähdä, mitä tapahtuu avaamatta jokaista lippua.
Lisäksi Trellon värikkäillä tunnisteilla voidaan lisätä vielä enemmän tietoja korttia laajentamatta. Hieman hyvällä organisaatiolla nämä Kanban-vastaavuudet Post-It-tarroista voivat osoittautua erittäin hyödyllisiksi ja säästää paljon turhaa napsautusta.
Luontaisesta yksinkertaisuudestaan johtuen Trello ajaa sinut pitämään asiat yksinkertaisina ja tarkoituksenmukaisina, välttäen tuntemusta, että tietovuoret ovat ylikuormitettuja. Monta kertaa työskentelet projektissa, jossa sinua jatkuvasti pommitetaan ilmoituksilla kohteista, joihin et edes ole tekemisissä.
Tämä ylimääräinen melu näyttää olevan jonkin verran vähentynyt Trellossa, ainakin kokemukseni mukaan. Koska Trello ei ole niin käyttäjäystävällinen tietojen lisäämiseen, huomasin, että ongelmat ovat yleensä pienempiä, mikä tarkoittaa, että tehtävät on jaettu pienempiin paloihin kuin Jirassa. Suunnittelussa nämä pienet tehtävät eivät saisi aiheuttaa liikaa melua.
Pelillistämisen käsite on osittain yksinkertaisen tehtävän ottaminen ja sen muuttaminen peliksi käyttämällä palkintoja. 'Vaikeus ei lykätä sinua, jos sitä täydennetään palkinnoilla' kuten tässä artikkelissa todetaan Trello-blogi .
Adrenaliinia (tai dopamiinia) lisätään aina, kun lippua siirretään vaiheesta toiseen. Koska korttia ei voi siirtää toiseen vaiheeseen vetämättä sitä Trellossa (kun taas Jirassa on helpoin muuttaa vain ongelman tilaa), saat fyysisen yhteyden edistymiseen. Jossakin vaiheessa, tajuamatta sitä, sinusta tuntuu, että kilpailet itseäsi vastaan lyödäksesi enemmän asioita sinä päivänä kuin edellisenä päivänä (toivottavasti en ole yksin täällä tämän tunteen kanssa) tai haluat vain taistella tehdäkseen todensarakkeen tyhjennä mahdollisimman nopeasti. Monet ohjelmistotuotteet käyttävät pelaamista nykyään suuremman sitoutumisen, kuten näkemysten ja tykkäysten, luomiseen useimmilla sosiaalisilla alustoilla - tämä toimintapalkkiomekanismi pitää ihmiset sitoutumassa alustoihin.
Olen edelleen hämmästynyt siitä, kuinka Trellon käyttö tuntuu iloiselta, ja varmasti, sen yksinkertaisuus on ratkaisevan tärkeää kokemuksen kannalta. Tehtävät ovat yleensä pienempiä - vaikka saatkin saman työn tehtyä, on parempi siirtää kolme tehtävää Tarkistettavaksi-sarakkeeseen kuin muuttaa yhden Jira-tarinan tila Valmis-tilaan. (Minusta tuntuu, että yhden Jira-tarinan muuntokurssi koskee kolmea korttia Trellossa.)
Tämä on ihanteellinen uusille kehittäjille tai yrityksen omistajille, jotka yrittävät hallita projektia, koska pääsyn este on hyvin alhainen. Kuka tahansa, ohjelmistoinsinööri tai joku muu hallitsee Trellon helposti. Ongelmana on, että Trello voi olla liian kevyt tietyille projekteille ja valtaville ryhmille. Vaikka voit helposti luoda lisää levyjä, monet kehittäjät työskentelevät yhdellä levyllä voivat aiheuttaa ongelmia. Se ei vain ole laadullisesti sama kuin Jiran jaettu työtila.
Kyllä - luulen, että nykypäivän tyypillisessä tilanteessa, jossa johtaja tai yrityksen omistaja ei ole käytettävissä vastaamaan kysymyksiin 24/7, sinun pitäisi todella miettiä työkalun käyttöä vain tapana saada arkisto, jossa kaikki vaadittu on kirjoitettu ylös selkeällä tavalla. Tämä auttaa sinua välttämään sekaannusta tai vastaamatta jääneitä kohteita, koska ne unohdettiin Skype-keskusteluun tai haudattiin satojen sähköpostien alle. Jos projekti on pienempi, kuten harrastussivusto, PMT voi olla ylivoimainen.
Vastaus tähän vastaa parhaiten tarpeitasi. Jos joukkueessasi on yli neljä ihmistä ja projekti kestää yli vuoden, menisin Jiran puoleen. Jos näin on, suosittelen, että luet lisää Jiran käytöstä ja käytöstä ohjelmistokehitysmenetelmät .
Jos joukkueessasi on vähemmän kuin neljä ihmistä ja projekti on yksinkertainen verkkosivusto tai ehkä lisää joitain ominaisuuksia olemassa olevaan projektiin, suosittelen Trelloa sen yksinkertaisuuden vuoksi. Kuten aina, työkaluilla molemmat voivat saada työn päätökseen, mutta se ei tarkoita, että paras on sama kaikille.
Jira-lippu on kuin atomi on yksi pienimmistä yksiköistä johtoryhmässä. Lippu voi olla erilainen asia Jiran tapauksessa, se voi olla tehtävä, tarina tai vika. Pohjimmiltaan sinun on suoritettava tehtävä, joka on lueteltu Jirassa yhtenä tuotteena.
Jira toimii helpottamalla suurten kehittäjäryhmien organisointia, antamalla sinun seurata toimintoja ja kunkin toiminnan nykytilaa. Tätä tarkoitusta varten se sisältää monia ominaisuuksia, kuten prioriteetit ja sprintit, ja se on ketterä.
Eepos on joukko tarinoita, tehtäviä, jotka liittyvät tarkoitukseen, jonka he yrittävät saavuttaa. Kuvittele, että teet sosiaalisen median alustaa: eepos voi olla verkkosivusto, joka sisältää kaikki verkkosivustoon liittyvät tehtävät, toinen voi olla sovellus, joka sisältää sovellukseen liittyviä asioita jne.