Olen käyttänyt SCRUMia kolmessa eri projektissa viimeisen neljän vuoden aikana. Yksi SCRUMin eduista näyttää olevan sen joustavuus ja sopeutumiskyky, esim. Muuttuvien asiakkaiden vaatimusten mukaan. Toinen etu on, että johto voi helposti seurata projektin etenemistä.
SCRUMin joustavuus voi olla etu esimerkiksi toteuttaessaan verkkosovellusta, jossa vaatimukset muuttuvat hyvin nopeasti ja asiakkaat todella ymmärtävät mitä haluavat nähtyään prototyypin.
Toisaalta on olemassa muunlaisia ohjelmistoprojekteja (esim. ilmailuteollisuudessa teollisuus), jossa vaatimukset ovat melko kiinteät: saat vaatimusten määrittelyasiakirjan ja sinun on palattava kuuden kuukauden kuluttua toimivan ohjelmiston ja täydellisen dokumentaation kanssa. Tällaisiin projekteihin epäilen, että SCRUMin tarjoamaa joustavuutta tarvitaan (siinä mielessä että sinun ei tarvitse rakentaa prototyyppejä ja näyttää niitä asiakkaalle saadakseen palautetta vaatimuksista): tarvitset pikemminkin hyvin jäsennellyn ja järjestelmällisen lähestymistavan, joka todennäköisesti toistetaan uudestaan ja uudestaan jokaiselle projektille, jolla ei ole juurikaan yllätysmahdollisuutta. / p>
Onko SCRUM sen kannattajien mielestä yleiskäyttöinen ohjelmistokehitysmenetelmä vai sopiiko se erityisen sopivaksi tietyille hankeryhmille tai sovellusalueille?
Katsoin äskettäin ilmailu- ja avaruusteollisuuden ohjelmistoja tuottavan yrityksen verkkosivustoa ja huomasin, että ne käyttävät V-mallia. Voisiko SCRUM-kannattaja sanoa, että SCRUM soveltuu vähemmän tällaisiin projekteihin, vai ehdottaako se, että tämän yrityksen pitäisi yrittää siirtyä SCRUM-palveluun?
Huomaa että en pyydä tämän foorumin lukijoiden mielipidettä, mutta haluan tietää, mikä on vakiintunut mielipide SCRUM-ehdokkaiden keskuudessa: onko SCRUM yleiskäyttöinen vai pikemminkin sopiva tietyille luokille vain hankkeista? Minkätyyppisille projekteille viimeksi mainituissa tapauksissa?
Kommentit
- Katso stackoverflow.com / questions / 596916 / milloin-ei-sinun-pitäisi ryöstää ja eweek.com/c/a/IT-Management/…
- Että ” saa vaatimusmäärittelyasiakirjan ja sinun on palattava kuusi kuukautta myöhemmin toimivan ohjelmiston kanssa ” -juttu on myytti. Silloinkin kun rakennat jotain kääntäjää muodollisesti määritetylle kielelle (jossa toiminnalliset vaatimukset näyttävät olevan todella selkeät ja kiinteät), sinun on päätettävä ja asetettava etusijalle toteutettavat asiat, ei-toiminnallisia vaatimuksia on keskusteltava käyttäjän kanssa , ja sinulla on useita vapausasteita, jotta yhden on päätettävä, miten ratkaista asiat. Ketterällä lähestymistavalla on siis jopa järkevää tällaisissa projekteissa.
- ” Joten ketterällä lähestymistavalla on jopa merkitystä tällaisissa projekteissa. ”: Vaikka ketterä voi olla joustavampi, myös muut menetelmät ovat joustavia. Voi olla, että muut menetelmät ovat riittävän joustavia, ja ketterä on liian joustava tietyille projekteille. Aivoriihi vain täällä.
- ” Että ” saa vaatimusmäärittelyasiakirjan ja sinun on palattava takaisin kuusi kuukautta myöhemmin toimivien ohjelmistojen kanssa ” asia on myytti. ”: En usko ’ . Vaikka voit vaihtaa nopeasti verkkosivun painikkeen merkinnän, koska asiakkaat ovat muuttaneet mieltään tarkastellessaan sitä, et voi yhtä helposti muuttaa lentokoneen liikkuvaa osaa ohjaavan ilmailun ohjelmiston kriittistä osaa. Ehkä tarvitaan myöhäisiä muutoksia, mutta ihmettelen, onko ketterä menetelmä oikea tapa hallita niitä vai tarvitsetko jonkin muun menetelmän (esim. V-mallin) monimutkaisempaa iterointia.
vastaus
SCRUM on yleiskäyttöinen menetelmä, joka voi toimia hyvin useimmissa projekteissa ja ryhmäkokoissa, mutta on vähemmän hyödyllinen suurille ryhmille, jotka tekevät hyvin suuria hankkeita. Joissakin hankkeissa mukana olevien ihmisten lukumäärä tekee ketterästä menetelmästä äärimmäisen vaikeaa lähes mahdottomaksi, koska järjestyksen pitämiseksi tarvitaan jäykempi rakenne. Ilmailu- ja avaruusteollisuus on hyvä esimerkki teollisuudesta, jolla on yleensä valtavia projekteja, joissa ketterät lähestymistavat eivät aina ole mahdollisia.
Kommentit
- Onko Huomioi esimerkiksi 18 kuukauden projekti 15 hengen tiimille: voisiko tällainen joukkue hyötyä SCRUM: sta vai sopisiko jokin muu malli, kuten V-malli Syy miksi kysyn, on se, että yli 18 kuukauden ajan vaatimuksilla ja toteutuksella on riittävästi aikaa kypsyä ja vakiintua, ja ehkä SCRUMin tarjoamaa joustavuutta ei todellakaan tarvita.Pikemminkin keskipitkän ja pitkän aikavälin lähestymistapa sopii tähän. Onko tästä kirjallisuutta?
- @Giorgio projektin aika ei ’ ole väliä, mutta 15 ihmistä riittää, että hyötyisit moninkertaisen rummun tekemisestä ryhmät, mutta se on edelleen hallittavissa olevalla alueella SCRUM: lle. kun viestinnänhallinnasta alkaa tulla kokopäiväinen työ tiimillesi, on aika alkaa tarkastella V-mallia
- Oletko tosissasi? Käytimme aiemmin V-mallia ja vaihdoimme SCRUM: iin. Itse asiassa meillä on tunne, että ’ olemme hitaampia juuri tästä syystä: liikaa kirjanpitoa.
- @Giorgio, joka pätee kaikkiin kytkimiin, olet tuntuu aluksi hitaammalta, koska sen uusi, kuten Pierre 303, sanoi, että saat paremman idean muutaman sprintin jälkeen.
- @Giorgio – että ’ on totta, monet ” ketterät ” menetelmät ovat raskaampia kuin raskaat prosessit, joita niiden ’ oletetaan olevan Korvata! Ilmeisesti tämä tarkoittaa, että he ’ ovat väärässä – ketterän oletetaan olevan kevyt ja vapaa ja näyttävän kaoottiselta ulkopuolisilta. Se tarkoittaa, että tiimisi on oltava hyvin järjestäytynyt ja kurinalainen, mutta siitä ’ on yleensä hyötyä. Kokeile sen sijaan Alistair Cockburnin (yksi Agile-yrityksen perustajista) Crystalia.
Vastaa
Kaikentyyppinen projekti ! Se toimii hyvin sekä suurissa että pienissä projekteissa.
Ihmiset ovat käyttäneet sitä häiden suunnitteluun, muuttoon jne. Joten, ei edes pelkästään ohjelmistoprojekteihin.
Olen vakaasti sitä mieltä, että on monia liiketoimintoja, jotka voisivat hyötyä Scrum-tyyppisestä lähestymistavasta.
Kommentit
- Onko oma mielipiteesi jaettu kirjoittanut SCRUM-ehdokkaat, ts. tekijät, jotka ovat koodanneet ja edistäneet SCRUMia?
- Kyllä – Cheryl Hammond ( blog.bsktcase.com ), ALM-konsultti Luoteis-Cadencella puheesta, jonka hän antoi otsikolle ” Scrum Masters Day In The Life: The New Visual Studio ”. Voit katsella sitä täältä: msevents.microsoft.com/CUI/…
Vastaus
Huomaa, että Scrum ei ole metodologia, vaan kehys.
Scrum toimii parhaiten c: ssä ross-toiminnallinen -tiimi 5-9 kehittäjältä työskentelee keskisuuri tai suuri -kokoinen projekti (4 kuukaudesta useisiin vuosiin). Jos projektisi on suurempi, voit skaalata Scrum of Scrums -toiminnolla.
En keskustele toiminnallisuudesta täällä, mutta täällä ovat mitä virallinen Scrum Guide kertoo joukkueen koosta:
Optimaalinen kehitys Joukkueen koko on riittävän pieni pysyäkseen ketteränä ja riittävän suurena merkittävän työn suorittamiseen. Alle kolme kehitystiimin jäsentä vähentää vuorovaikutusta ja johtaa pienempään tuottavuuden kasvuun. Pienemmät kehitystiimit saattavat kohdata taitorajoituksia sprintin aikana, minkä vuoksi kehitystiimi ei pysty toimittamaan mahdollisesti vapautettavaa lisäystä. Yli yhdeksän jäsenen jäsenyys vaatii liikaa koordinaatiota. Suuret kehitystiimit tuottavat liian paljon monimutkaisuutta empiirisen prosessin hallitsemiseksi. Tuotteen omistaja- ja Scrum Master -roolit eivät sisälly tähän määrään, elleivät he myös suorita Sprint Backlog -työtä
Sprintti on noin kuukausi.
Sprintit on rajoitettu yhteen kalenterikuukauteen. Kun Sprintin horisontti on liian pitkä, rakennettavan määritelmä voi muuttua, monimutkaisuus ja riski kasvaa. Sprintit mahdollistavat ennustettavuuden varmistamalla tarkastuksen ja edistymisen sovittamisen kohti tavoitetta ainakin joka kalenterikuukausi. Sprintit rajoittavat riskin myös yhteen kalenterikuukauteen.
Mielestäni ei ole järkevää käyttää iteratiiviseen prosessiin perustuvaa kehystä pienempien projektien kanssa yli 4 kuukautta. 4 kuukautta = 4 sprinttiä. Sinun on myös otettava huomioon, että saat tarkemman nopeuden kolmen sprintin jälkeen.
Se sanoi , Henkilökohtaisesti käytän rajoitettua versiota Scrumista pienempiin projekteihin, mutta et voi sitä silloin kutsua Scrumiksi. Siinä tapauksessa käytät joitain Scrumin perusperiaatteita omassa kehyksesi toteutuksessa.
Vastaus
aloittelijoille , ajattele SCRUMia vain yhtenä kokonaisuutena ketterien käytäntöjen toteuttamiseksi. Älä koskaan ajattele sitä ”pyhänä kirjana” siitä, miten projektit tehdään. Esimerkiksi monille projekteille, joissa vaaditaan tasaista tehtävävirtaa, Kanbam on sopivampi.
Ketterät projektit kaatuvat yleensä sinne, missä teet projekteja, jotka edellyttävät kiinteää päättymispäivää tai kiinteitä kustannuksia. Vaikka voit silti tehdä nämä projektit ketterillä menetelmillä, tarve suunnitella kaikki etukäteen selvittää, oletko todennäköisesti osumassa tavoitteeseen, ei ole tavallinen ketterä tapa – ketterässä sinulla on tapana jatkaa työtä, kunnes loppuu tekemistäsi tai loppuu aika tehdä se. Useimmissa projekteissa tämä on ok koska vaatimukset muuttuvat joka tapauksessa projektin aikana.
Kommentit
- Tapa, jolla toimimme ketterästi tiimissämme, on antaa asiakkaalle asettaa prioriteetti tarinoille. (tärkeimmistä vähiten tärkeisiin), arvioimme käyttäjien tarinoita pokerikorttien avulla ja suunnittelemme niin monta tarinaa kuin pystymme toteuttamaan umpikujaan saakka. Jos osoittautumme nopeammaksi, ajoitamme enemmän tarinoita prioriteettiluettelossa seuraavien asioiden mukaan.
- Luin vastauksesi uudelleen muutaman kuukauden kuluttua ja se on todella valaisevaa. +1