Ketterät menetelmät ja menetelmät aloittelijoille - Ketterän ohjelmistokehityksen ja ketterän projektinhallinnan esimerkit

Ketterä on menetelmä lähestyä ohjelmistokehitystä. Se koostuu erilaisista kehyksistä, kuten SCRUM tai Kanban, jotka auttavat kehitystiimejä jatkuvasti rakentamaan, testaamaan ja keräämään palautetta tuotteestaan.

Ketterä koostuu neljästä perusperiaatteesta:

  1. Yksilöt ja vuorovaikutus prosessien ja työkalujen suhteen
  2. Toimiva ohjelmisto kattavan dokumentaation avulla
  3. Asiakasyhteistyö sopimusneuvotteluissa
  4. Suunnitelman noudattamiseen vastaaminen

Tarkastelen näitä periaatteita myöhemmin ja ymmärrän niitä paremmin. Tätä varten on tärkeää ottaa askel taaksepäin ja ymmärtää aiemmin käytettyjä ohjelmistokehityskäytäntöjä.

Vesiputous

Vesiputouskehitys on hyvin lineaarinen lähestymistapa tuotteen rakentamiseen. Siinä on vähän tai ei lainkaan palautetta tai iterointia, ennen kuin tuote on rakennettu ja testattu kokonaan.

Näin se toimii: tiimit käyttävät viikkoja (ja joskus kuukausia) tuotevaatimusasiakirjojen laatimiseen.

Ennen kuin mitään koodia kirjoitetaan, tuotepäälliköt, analyytikot ja suunnittelijat laativat yhden massiivisen asiakirjan, joka kuvaa tuotevaatimukset erittäin yksityiskohtaisesti.

Liioittelematta tämä on pitkä ja työläs prosessi, jossa väistämättä jotkut asiat jäävät väliin.

Tässä on yksinkertainen ajatuskokeilu. Ajattele Google-hakua tai asiakkaan sähköpostihakua.

Yritä nyt yrittää kuvata näiden tuotteiden vaatimuksia koskeva asiakirja.

Epäilemättä tärkeät asiat jäävät väliin. Yksinkertaisesti ei voida kuvitella käyttötapaa, mittakaavaa tai laajuutta siitä, miten nämä tuotteet kehittyvät ajan myötä.

Jos olet rakentanut tuotteen - yksinrakentajana tai tiimin jäsenenä, voit todennäköisesti liittyä tähän väitteeseen.

Kun kaikki on sovittu, tekniset tiedot luovutetaan suunnittelutiimille, joka sitten rakentaa tuotteen määrittelemään, hyödyntämään laadullista ja määrällistä tietoa ja panoksia.

Kun kaikki on koodattu, testaus alkaa.

Jos kyseessä on monimutkainen tuote, testaaminen ja virheenkorjaus voi viedä viikkoja tai kuukausia, koska koko tuote on tarkistettava perusteellisesti. Kun testaajat ja tuotepäälliköt allekirjoittavat testivaatimukset, tuote on valmis lähetettäväksi tuotantoon.

Vesiputouksen kehittämisessä on useita puutteita, ja tässä on muutamia.

Sisäänrakennettujen palautemekanismien puute

Entä jos kehitystiimi noudattaa tarkasti määrityksiä ja käy ilmi, että sen eloon tuleminen ei vain ole niin houkuttelevaa kuin tuotetiimi luuli sen olevan? Tai vielä pahempaa, entä jos erittelyasiakirjassa olisi virhe?

Vesiputouskehityksessä et tiedä vastausta näihin kysymyksiin, ennen kuin tuote on jo rakennettu.

Tuotekehitys voi johtaa suuriin kiinteisiin kustannuksiin. Jos tuote ei toimi, näistä kustannuksista voi tulla kustannuksia.

Upotetut kustannukset ovat rakentajan vihollinen, koska uppoamat kustannukset ovat jo aiheutuneita kustannuksia, joita ei voida korvata.

Entä jos tiekartta muuttuu?

Tätä tapahtuu koko ajan. Se tapahtuu tietokoneella, jota käytät tämän artikkelin lukemiseen, se tapahtuu yrityksessäsi ja se tapahtuu suurissa ja pienissä teknologiayrityksissä.

Entä jos tiekartta muuttuu ja tiimin on kiinnitettävä huomionsa johonkin muuhun? Vesiputouksen alla jää käyttökelvoton tuote. Ajattele: jäykkyys.

Jälleen kerran, jos et pysty muuttamaan kiinteitä kustannuksiasi joustaviksi, sinulle jää suuri lasku eikä paljon näytettäväksi.

Kaikki omistautunut työ, stressaavat määräajat, taulun kalanterointi ja myöhäiset illat eivät johda toivottuihin tuloksiin projektin alussa.

Tuote kerää pölyä, kunnes se lopulta lähetetään

Sen sijaan, että tuotannolle toimitettaisiin tietyn ajanjakson aikana lisäparannuksia, vesiputousmenetelmä odottaa koko tuotteen toimittamista loppuun asti.

Vaikka tämä on kohtuullinen lähestymistapa auton rakentamiseen, se ei ole hyvä lähestymistapa ohjelmistoihin.

Ohjelmistot, toisin kuin autot, ovat joustavia suunnittelussa.

Ihmiset eivät voi käyttää puolet tuotetuista autoista. Mutta käytämme puoliksi rakennettuja ohjelmistoja koko ajan.

Syötä ketterä

Ketterä auttaa ratkaisemaan nämä ongelmat antamalla tuotekehitystiimien rakentaa jatkuvasti lisäarvoa tuottavia ominaisuuksia. Se antaa myös ryhmille mahdollisuuden saada jatkuvasti palautetta työstään ja tehdä muutoksia tarvittaessa.

Ketterien menetelmien avulla tiimit lähettävät jatkuvasti ja ennakoitavasti pieniä koodinpaloja tuotantoon nopeasti.

Kun he ovat suorittaneet kaikenlaisen lisäarvoa tuottavan ominaisuuden, he testaavat ja julkaisevat sen maailmalle. Tämä on iteratiivinen lähestymistapa tekniikan rakentamiseen.

Sen sijaan, että kestäisi kuukausia lopputuotteen rakentamiseen ja end-to-end-testin suorittamiseen, Agile-kehitys antaa ryhmille mahdollisuuden rakentaa jatkuvasti pienempiä kappaleita lopputuotteesta ja lisätä ne tuotantoon ajan myötä.

Tämä tarkoittaa, että testaus menee nopeammin, koska testaat vain viimeisimmän koodin yhteensopivuutta. Tämä tarkoittaa myös sitä, että käyttäjät ja sidosryhmät ovat onnellisempia, koska he saavat nähdä ja käyttää uusimpia tuoteparannuksia jatkuvasti.

Harkitse molempia lähestymistapoja todelliseen sanaesimerkkiin keittiön uudistamisesta. Sanotaan, että remonttityön tekeminen kestää kuusi kuukautta.

Vesiputous ehdottaa, että urakoitsija ja hänen miehistönsä rakentavat koko keittiön ja paljastavat sitten koko keittiön asiakkaalle kuuden kuukauden kuluttua.

Vaikka työ tehdään samassa ajassa, omistaja jätetään pimeään. Yksinkertaiset kysymykset, kuten miten se menee, jää suurelta osin vastaamatta. Pahinta on, että omistajat eivät voi käyttää mitään keittiön osia loppuun asti.

Agilen kanssa urakoitsija selvittäisi sen sijaan, mitä heidän tiiminsä voisi tehdä muutaman viikon välein, ja antaisi sitten asiakkaalleen mahdollisuuden nähdä sen ja käyttää sitä samalla kun he uudistivat loput.

Ehkä he voivat vaihtaa kaapit ensimmäisen kuukauden aikana, työtasot toisessa kuussa, ja kolmanneksi kuukaudeksi he asentavat uuden jääkaapin ja lieden. Ei huono lopputulos molemmille osapuolille!

Toisessa lähestymistavassa omistaja saa edun käyttää keittiön osia ennen kuin kaikki on valmis. Sen sijaan, että uusi liesi vain istuisi siellä ja keräisi pölyä, sitä todella käytetään heti, kun sitä voidaan käyttää.

Ja ehkä keittiön omistaja haluaa vaihtaa yhden kaapin hyllylle?  

Urakoitsija voi nyt ainakin suunnitella muutoksen ennen kuuden kuukauden päättymistä ja ilmoittaa omistajalle, miten se vaikuttaa projektin aikatauluun.

Näennäisesti molemmat osapuolet voivat työskennellä yhdessä ja kommunikoida avoimesti varmistaakseen oikeat tulokset ja työn.

Nämä ovat joitain ketterän monista eduista. Molemmat osapuolet ovat paremmin.

Yritä viedä tämä oppitunti eteenpäin, kun opit uusia kehitystaitoja freeCodeCampissa ja soveltavat taitojasi projekteihin.

Tarkastellaan joitain muita esimerkkejä ohjelmistomaailmassa

Tarkastelemalla ketterää neljää periaatetta voimme nyt etsiä esimerkkejä Agilen soveltamisesta todellisessa ja digitaalisessa maailmassa.

Toivon, että näet nyt, kuinka nämä periaatteet hyökkäävät suoraan vesiputousprosessiin.

Periaate # 1: Yksilöt ja vuorovaikutus prosessien ja työkalujen suhteen

Vankka prosessi ja työkalut ovat erittäin tärkeitä ketterässä. Yksilöiden ja vuorovaikutuksen arvostaminen työkalujen avulla mahdollistaa kuitenkin suuremman arvonluonnin ja tuotoksen.

Yksittäiset tiimin jäsenet voivat innovoida.

Sen sijaan, että pakottaisit ihmisiä noudattamaan tiukkoja ajatuksia ja määrityksiä, voit antaa heille enemmän kaistanleveyttä kokeilemiseen.

Osa yksilöiden asettamisesta työkalujen päälle on kokeilua uusilla työnkulkuilla. Yksi esimerkki ketterän ohjelmistokehityksen innovaatioista on koodekki, tietokoneohjelma, joka koodaa tai purkaa digitaalisen datavirran tai signaaleja.

H266 / VVC-koodekki käyttää noin puolta datasta 4K-videoiden suoratoistoon. Ja se on tunnustettu tehokkaimmaksi tulevaisuuden 4K- ja jopa 4K VR-reaaliaikaisen suoratoiston koodausratkaisuksi.

Kuinka tämä löytö tehtiin? Sen tekivät ihmiset, jotka käyttivät ketterää ratkaisemaan videon pakkausongelmia.

Erityisesti se tehtiin, koska yksilöille annettiin vapaus rakentaa, testata, kokeilla ja innovoida tietyn ajanjakson ajan. Heitä ei käsketty rakentamaan keittiötä tyhjästä ja palata takaisin kuuden kuukauden kuluttua.

He ottivat pieniä askelia oikeaan suuntaan. Tämä tulos on opettavainen.

Tässä on toinen esimerkki: kun LogMeIn osti Lastpassin, LogMeIn oli kiinnostunut tekniikasta yhtä paljon kuin suunnittelukulttuuri, jonka Lastpass oli toteuttanut tuotteiden rakentamiseksi.

Millaista kulttuuria se oli? Yksi, joka priorisoi ketterän.

Ketterä ei vain tuo tuotteita markkinoille nopeammin, vaan se luo luovia ja synergistisiä tuloksia, jotka ovat arvokkaita.

Arvon luominen on upotettu ketterään kulttuuriin.

Periaate # 2: Toimiva ohjelmisto kattavan dokumentaation yli

Tämän pitäisi olla ilmeinen jo. Kirjoita tarkkojen spesifikaatioiden ja suunnittelun sijaan vain muutama toimiva koodirivi.

Testaa se. Hanki palautetta siitä. Lähetä se.

Sitten, tee se uudelleen.

Toistaa.

Erittäin merkityksellinen esimerkki tästä toistoprosessista löytyy Forms on Fire -lehdestä.

He loivat ohjelmiston mobiilidatan keräämisen helpottamiseksi. He eivät kirjoittaneet koko yritystään ennen perustamista; he kirjoittivat muutaman rivin koodia, testasivat sen ja lähettivät sen.

Saatuaan vauhtia he nopeuttivat testaustaan ​​ja iteratiivisia vaiheitaan.

Ja he toistivat, mikä toimi, ja heittivät, mikä ei. Tulokset puhuvat puolestaan.

Periaate # 3: Asiakasyhteistyö sopimusneuvotteluissa

Ketterä edistää nopeaa palautesilmukkaa asiakkaiden ja sidosryhmien palautteen saamiseksi.

Mikä voisi olla parempaa kuin työskennellä taaksepäin siitä, mitä todelliset käyttäjät ja asiakkaat haluavat?

Minulla on liike-elämän mentori, joka neuvoi, että sen sijaan, että analysoitaisiin liikaa asiakkaiden haluamia loputtoman suunnittelun avulla, pidä se yksinkertaisena. "Lievitä häiriötekijöitä", hän sanoi.

Olen kirjoittanut KISS-periaatteesta freeCodeCampissa, ja neuvo pitää varmasti paikkansa ketterässä: rakenna jotain pientä ja katso, pitävätkö asiakkaasi siitä.

Jos he tekevät, jatka.

Periaate # 4: Suunnitelman noudattamiseen vastaaminen

Nopeat palautesilmukat synnyttävät nopean muutoksen ja säädöt. Tämä tekee Agilesta niin suuren kehitystiimille.

Siksi sinun pitäisi omaksua se.

Tiekartat muuttuvat aina, tämä on tunnettu vakio. Ketterien menetelmien avulla tiimit voivat vastata muutokseen kuuntelemalla asiakkaiden palautetta ja tekemällä tarvittavat muutokset.

Joskus muutoksiin vastaaminen tarkoittaa tuotteen mukauttamista tai ajattelua käyttäjistä tai kilpailijoista.

Klassinen esimerkki, jota ketterät opiskelijat voivat tarkastella verkkokaupan alueella, on Amazonin myynti. Kuinka sopeudut nopeasti kilpailuun? Yksi tapa on rakentaa porteilla olevia yhteisöjä tai kokeilla erilaisia ​​tuotejulkaisustrategioita.

Taktisten ja muovattavien ratkaisujen käyttöönotto on suositeltavaa.

On hieno sananlasku: ”Emme voi muuttaa tuulen suuntaa. Voimme vain säätää purjeitamme. "

Kun ajattelen ketterää, ajattelen tätä sanomaa.

Ketterä on oppimista, ketterä opettaa. Ketterä on joustavuutta.

Voit harjoitella ketterää päivittäisessä työssäsi tai käydä verkkokursseilla kehittyäksesi edelleen.

Jotkut ihmiset ovat tarpeeksi älykkäitä ennustamaan, mitä heidän asiakkaansa haluavat. He tietävät, mihin suuntaan tuuli puhaltaa.

Mutta meille, kuolevaisille, Agile on menetelmä, jonka avulla voimme selviytyä puutteistamme ymmärtääksemme, mitä asiakkaat haluavat.

Järjestelmän avulla voimme säätää purjeitamme jatkuvasti.