Story-Splitting-b-agile

on siis enemmän tai vähemmän makuasia, haluaako graafisen käyttötapauskaavion vai (tekstimuotoisen) käyttäjätarinoiden luettelon.

haluan tiivistää keskustelun vaatimusten jäsentämisestä suuressa: notaatiosta riippumaton suuren ongelman hajoaminen ulkoisesti käynnistyväksi prosessiksi on neutraalein tapa saavuttaa tämä erittely. Se ei perustu mihinkään järjestelmien sisäiseen rakenteeseen (ei sen toimintoihin, ei sen alijärjestelmiin, ei sen objekteihin, .,,) mutta puhtaasti ympäristön tarpeisiin.

tämä ei tarkoita, etteivätkö muut edellä mainitut hajoamisstrategiat toimisi, vaan ainoastaan vihjaus siitä, ettei sisäisiin rakenteellisiin keskusteluihin jäisi jumiin.

jakaminen pieneen

kuten näette yksinkertaisesta esimerkkitapauksesta navigointijärjestelmästä tämän prosessin yläpuolella (riippumatta siitä, mitä merkintää haluatte) näyttää edelleen olevan liian monimutkainen toteutettavaksi yhdellä iteraatiolla. Sinun täytyy ehdottomasti jakaa se pienempiin osiin. Lawrence (https://agileforall.com/resources/how-to-split-a-user-story/) ehdotti monia keinoja isompien palasten käsittelemiseksi ja niiden jakamiseksi tarinoiksi, jotka ovat tarpeeksi pieniä yhteen iteraatioon.

vaikka klassiset menetelmät ehdottivat lähinnä monimutkaisen prosessin ymmärtämistä paremmin tarkastelemalla sen vaihejärjestystä, ketterässä maailmassa on nyt toinenkin ongelma: haluamme luoda arvoa jokaisessa iteraatiossa eli keksiä mahdollisesti siirrettäviä tuotekorotuksia. Ei ole tarpeeksi hyvä vain hajottaa iso prosessi (käyttötapaus tai suuri tarina) ymmärtää sitä paremmin. Hajoamisen jälkeen jokainen osa vielä pitäisi antaa jonkin verran arvoa käyttäjälle riippumaton muista osista.

tämä estää teknisiä jaotteluja, kuten jakautumista sen teknisiin kerroksiin, kuten käyttöliittymään, toimialueen toiminnallisuuteen ja pysyvyystasoon, koska pysyvyystason toteuttaminen ensin (eli joidenkin tietokantataulukoiden luominen) ei tuota liikearvoa ennen kuin voit täyttää ja näyttää ne. Sama pätee usein puhtaan liiketoimintaprosessin hajoamiseen sen vaiheisiin: monimutkaisen prosessin yhden vaiheen 7 toteuttaminen ei välttämättä tuota mitään arvoa niin kauan kuin edeltäjä-ja seuraajavaiheita ei ole.

(vain mielenkiintoinen historiallinen sivuhuomautus metodologien välisistä terminologiasodista: Mike Cohn valitti, että käyttäjätarinat eivät ole käyttötapauksia pelkästään argumentin avulla: ne saattavat olla liian suuria toteutettavaksi yhdellä iteraatiolla. Ivar Jacobson hyväksyi väitteen koosta, mutta aivohalvaus takaisin väittämällä “käytä tapauksissa viipaleet” ovat paljon parempi tapa ajatella sitten työskennellä tarpeeksi pieni Käyttäjä tarinoita, koska käytä tapauksessa viipaleet antaa päästä päähän-arvo.)