Jotain, mikä on minusta ollut ärsyttävää jo jonkin aikaa, on se, kuinka yleistä monilla alalla on käyttää termejä kuten ”Scrum mutta …” pejoratiivisessa merkityksessä, mikä viittaa siihen, että tiimien tulisi noudattaa vain sitä pientä joukkoa käytäntöjä, jotka ovat osa Scrumia. Todellisuudessa Scrum ei yksinään riitä siihen, että ketterät tiimit pystyvät toistuvasti toimittamaan toimivia ohjelmistoja merkittävän ajanjakson ajan. Tajusivat he sitä tai eivät, valtaosa Scrum-tiimeiksi itseään kutsuvista tiimeistä toimii Scrum-XP-hybridinä tai Scrum-Kanban-XP-hybridinä, jossa ne käyttävät ainakin osajoukkoa XP:stä peräisin olevista teknisistä käytännöistä.
Sallikaa minun sanoa, että tiimit, jotka noudattavat vain Scrum-käytäntöjä, eivät todennäköisesti menesty pitkällä aikavälillä, koska ainakin osa XP:n teknisistä käytännöistä on välttämätön edellytys jatkuvalle menestykselle ketteränä toimitustiiminä.
Olen havainnut, että liian harva ymmärtää, mitä Scrum sisältää ja mitä se ei sisällä, joten aloitetaan siitä.
Mitä Scrum on – joukko johtamiskäytäntöjä
Scrum on empiirisen prosessinohjauksen soveltamista, mikä on hieno tapa sanoa, että meidän pitäisi tehdä päätöksiä kokemukseen perustuen, eikä joidenkin hypoteettisten olettamusten perusteella, joilla ei ole todellisuuspohjaa.
Lyhyesti sanottuna Scrum koostuu pienestä joukosta johtamiskäytäntöjä, joiden tarkoituksena on auttaa tiimejä tekemään tehokasta yhteistyötä ja toimittamaan työtä iteratiivisesti (korostan vielä kerran – Scrumissa ei ole yhtään teknistä käytäntöä).
Kiinnitän lyhyesti yhteen Scrum-oppaan sisällön:
- On olemassa Scrum-tiimi, joka koostuu kehittäjistä, tuoteomistajasta (Product Owner) ja Scrum Masterista.
- On Scrum-tapahtumat, jotka koostuvat Sprintistä, Sprintin suunnittelusta, Daily Scrumista (eli Daily Standupista, XP:ssä), Sprint Reviewista ja Sprint Retrospectiveista.
- On olemassa Scrum-artefakteja, jotka koostuvat Product Backlogista, Sprint Backlogista ja Inkrementistä, jossa Inkrementti on olemassa heti, kun yksi kohde Sprint Backlogista täyttää Määritelmän Valmis.
- On olemassa Määritelmä Valmiiksi, jossa jokaisella Scrum-tiimillä on jaettu käsitys siitä, mitä ”valmis” tarkoittaa minkä tahansa Product Backlogin kohteen osalta. Huomaa, että toisin kuin Hyväksymiskriteerit, Määritelmää Valmis sovelletaan globaalisti, kun taas Hyväksymiskriteerit koskevat yksittäisiä Product Backlog -kohteita.
Mitä Scrum ei ole
Kansanuskon vastaisesti mikään seuraavista asioista ei kuulu Scrumiin:
- Käyttäjätarinat. Minkä tahansa Scrum-tiimin Product Backlogin tai Sprint Backlogin työkohteet kirjoitetaan käyttäjätarinoiksi (usein muodossa ”As a <persona/role>, I want <goal>, so that <desired outcome>”), mutta Scrum ei määrää mitään tiettyä konstruktiota tai muotoa. Huomaa, että käyttäjätarinat ovat osa XP:tä.
- Arviointi. Vaikka valtaosa Scrum-tiimeistä suorittaa arviointia jollain tasolla, arvioinnin harjoittaminen ei ole osa Scrumia.
- Nopeus. Myöskään nopeus ei ole osa Scrumia; projektin nopeuden käsite on osa XP:tä.
- Tekniset käytännöt. Kuten edellä todettiin, Scrumissa ei ole teknisten käytäntöjen (CI, CD, pariohjelmointi, TDD jne.) käsitettä. Valtaosa teknisistä käytännöistä, joita tiimit tyypillisesti noudattavat, on peräisin XP:stä.
Mitä on Extreme Programming?
On kulunut yli kaksi vuosikymmentä siitä, kun ensimmäinen Extreme Programming (XP) -tiimi perustettiin, jossa työskenneltiin Chrysler Comprehensive Compensation (C3) -nimisen projektin parissa. Menetelmät, joita tuo tiimi käytti, ovat peräisin suurelta osin 1980-luvulta, jolloin Kent Beck ja monet muut kokeilivat parempia tapoja kehittää ohjelmistoja eli vaihtoehtoa siihen mennessä vallitsevaksi tulleelle ”vesiputous”-lähestymistavalle.
Työn visuaalistaminen on aina ollut tärkeä keino antaa tietoa siitä, miten ketterät tiimit toimivat. Siksi XP:n johdantona suosittelen, että kaikille, jotka haluavat oppia lisää, olisi hyvä aloittaa näistä kaavioista:
- Extreme Programming Project (päästä päähän -kaavio)
- Iteraatio (kaavio, jossa keskitytään siihen, mitä iteraation sisällä tapahtuu; huomaa, että se, mitä XP kutsuu iteraatioksi, on käsitteellisesti samankaltainen kuin se, mitä Scrum kutsuu sprintiksi)
- Kehitys (kaavio, jossa keskitytään kehitystyön vuorovaikutussuhteisiin ja aktiviteetteihin) Jos haluat visuaalisen esityksen, jossa on yhdistetty monia edellä mainittujen kaavioiden elementtejä yhdelle sivulle, katso Bill Waken Extreme Programming Overview.
Lisälukemista XP:stä
Jos yllä olevat visualisoinnit kiehtovat sinua niin paljon, että haluat lukea lisää XP:stä, tutustu seuraaviin tietolähteisiin, jotka on lueteltu suurin piirtein järjestyksessä lyhin luettava > pisin luettava:
- Don Wells, Extreme Programming: a gentle introduction
- Martin Fowler, BeckDesignRules (ks. myös Xp Simplicity Rules)
- Kent Beck, Ward Cunningham, et al., Extreme Programming Core Practices (aka the 12 XpXtudes)
- Don Wells, The Rules of Extreme Programming
- Ward Cunningham, et al.,Extreme Programming (aka the WikiWikiWeb)
- Ron Jeffries, What is Extreme Programming?
- Kent Beck & Cynthia Andres, Äärimmäinen ohjelmointi selitetty: Embrace Change (2nd Ed.)
Lisäviitteet
Kaikki tämän osion viitteet ovat Don Wellsin XP-verkkosivuilta, ellei toisin mainita.
- Ketterät mallit ovat maalauksia, eivät valokuvia (kaikki mallit ovat väärin; jotkut ovat hyödyllisiä)
- Ketterän prosessin sananlaskut (sanoja, joiden mukaan minkä tahansa tiimin kannattaa elää)
- Bill Wake, Arrange, Act, Assert (malli yksikkötestien kirjoittamiseen)
- Bill Wake, Sudoku Solver (mielenkiintoinen variaatio TDD:stä)
- Bill Wake, Tests from a Hat (luova lähestymistapa yksikkötestien kirjoittamiseen)
- Rehelliset suunnitelmat (miltä estimointi näyttää käytännössä)
- Manage Your Goals Instead of Activities (vesiputous- ja ketterän kehityksen tärkeimmät erot)
- The Values of Extreme Programming (Yksinkertaisuus, Viestintä, palaute, kunnioitus, rohkeus)
- XP ja tietokannat (malli, joka perustuu kultaisiin > hopeisiin > pronssisiin tietokantoihin )