Scrum ja Extreme Programming (XP) ovat ehdottomasti hyvin linjassa. Itse asiassa, jos kävelit joukkue tekee yksi näistä prosesseista sinulla voi olla vaikea nopeasti päättää, oletko kävellyt sisään Scrum joukkue tai XP joukkue. Erot ovat usein varsin hienovaraisia, mutta ne ovat tärkeitä. Mielestäni on olemassa neljä tärkeimmät erot Scrum ja XP:
- Scrum-tiimit toimivat tyypillisesti toistojen (kutsutaan kiri), jotka ovat kahdesta viikosta yhteen kuukauteen pitkä., XP-tiimit toimivat tyypillisesti yhden tai kahden viikon mittaisissa iteraatioissa.
- Scrum-joukkueet eivät salli muutoksia sprintteihinsä. Kun sprintin suunnittelukokous on valmistunut ja sitoumusta toimittaa tuotteen kehitysjonon kohdat, että joukko kohteita pysyy muuttumattomana loppuun asti sprint. XP-joukkueet ovat paljon halukkaampia muuttamaan iteraatioissaan. Niin kauan kuin joukkue ei ole aloittanut työnsä tietty ominaisuus, uusi ominaisuus vastaa kokoa voidaan vaihtaa osaksi XP-tiimin iteraatio vastineeksi unstarted ominaisuus.,
- Extreme-Ohjelmatyöryhmät toimivat tiukassa prioriteettijärjestyksessä. Asiakas (Scrumin tuoteomistaja) priorisoi kehitettävät ominaisuudet ja tiimin on työskenneltävä niiden parissa siinä järjestyksessä. Sen sijaan Scrum-tuotteen omistaja priorisoi tuotteen takaiskun, mutta tiimi määrittää, missä järjestyksessä ne kehittävät backlog-kohteita. En ole koskaan nähnyt Scrumin tiimiä, joka ei halua työskennellä tärkeimmän kohteen parissa. Scrum-ryhmä valitsee todennäköisesti toiseksi tärkeimmän., Kuitenkin, jossain vaiheessa yksi korkean prioriteetin kohteita voi olla hyvä sovi sprint suunnitteilla—ehkä keskeinen henkilö, joka pitäisi toimia sen tulee olla hukkua by työskennellä korkeamman prioriteetin kohteita. Tai ehkä on järkevää työskennellä hieman pienempi prioriteetti tuote (sanotaanko #10 tuotteen kehitysjonoon sen sijaan, että #6), koska joukkue toimii koodi, jossa #10 olisi toteutettu.
- Scrum ei määrää mitään insinöörikäytäntöjä, XP määrää., Rakastan XP teknisiä käytäntöjä, erityisesti asioita, kuten test-driven development, keskittyä automatisoitu testaus pariohjelmointi, yksinkertainen suunnittelu, refaktorointi, ja niin edelleen. Mielestäni on kuitenkin virhe sanoa tiimille ” olet itseorganisoituva, luotamme sinuun, mutta sinun täytyy tehdä nämä erityiset tekniset käytännöt….”Tämä lähettää sekavan viestin joukkueelle, joka aiheuttaa hämmennystä. Rakastan XP-käytäntöjä, mutta en pidä niiden mandatoinnista. Haluan joukkueiden selvittävän arvon itse.
– Nämä ovat pieniä ja usein hienovaraisia eroja Scrum ja XP., Niillä voi kuitenkin olla syvällinen vaikutus joukkueeseen. Tyypillinen neuvoni tiimeille on ” aloita Scrumista ja keksi sitten oma versiosi XP: stä.”XP-käytännöt ovat ihana, mutta ne toimivat parhaiten, ja joukkueet sitoutuvat niitä eniten äänekkäästi, jos ne löytää ne itse sen sijaan, että heidät on valtuutettu. Autan joukkueita tekemään tämän valmennuksessani kysymällä, että olisiko tämä bugi tapahtunut, jos olisimme tehneet testivetoista kehitystä?”ja” olisimmeko tehneet sen virheen, jos olisimme pareja?”True XP on pieni kohde matkan päässä., Jos joukkue voi tähdätä siihen ja osua napakymppiin, hienoa. Jos ei, ne ovat kuitenkin todennäköisesti hakkerointi (esim.refactoring ilman automaattista testausta tai TDD). Scrum on iso napakymppi, että omasta tuo suuria parannuksia yksinkertaisesti kautta lisää huomiota ja timeboxed toistojen. Se on hyvä lähtökohta sitten lisäämällä XP käytäntöjä.