#1: Scrum vs Kanban
Scrum i Kanban, co wy w sobie skrywacie... ;)
No właśnie. Zarówno pierwsza jak i druga technika pracy (należąca do rodziny Agile) ma jeden cel - dowieźć oprogramowanie/produkt przy jednoczesnym udoskonalaniu procesu developmentu. W firmach IT na pewno spotkasz się z jednym lub drugim podejściem. A czasami nawet z obydwoma na raz - zależnie od projektu w danej firmie. Warto zatem znać różnice pomiędzy Scrumem a Kanbanem.
I tak oto ten pierwszy cechuje się:
- podziałem ludzi na małe, samoorganizujące się zespoły,
- podziałem całej pracy na niewielkie, konkretne zadania, określając ich priorytet/ważność oraz estymując je (szacując czas lub trudność realizacji),
- podziałem całego czasu developmentu na równej wielkości iteracje - najczęściej dwutygodniowe sprinty,
- omówieniem i podsumowaniem każdej iteracji po jej zakończeniu,
- zoptymalizowaniu procesu podczas organizowanych po każdej iteracji retrospektyw (retro).
Kanban z kolei cechuje się:
- podzieleniem zadań na mniejsze taski i umieszczeniu ich w konkretnych kolumnach (to do, done by dev, ready for qa itd),
- limitem pracy (ile zadań może być realizowanych jednocześnie),
- określeniem czasu realizacji (im krótszy czas wykonania zadania tym lepiej).
W praktyce praca w obu metodykach jest bardzo podobna, przy czym Kanban daje nam większą elastyczność - nie ma przeszkód, by w trakcie iteracji dobrać zadania czy wymienić je, planowanie nie jest też takie szczegółowe - przedstawiamy mniej więcej wizualizację postępu prac i nadajemy pewne reguły. Scrum jest w tym temacie bardziej zasadniczy - bardzo dokładne i szczegółowe planowanie, brak możliwości (lub mocno ograniczona możliwość) zmiany wybranych zadań czy priorytetów podczas trwającej iteracji, a tego wszystkiego pilnują specjalistyczne role, których nie spotkamy w Kanbanie - chodzi o Scrum Mastera (czuwa nad realizacją prac) czy Product Ownera (określa wizję projektu i nadaje priorytety). Są też spotkania, których oficjalnie w Kanbanie nie uświadczymy. Również iteracje są dość ścisłe, tj. wybierając dwutygodniowe sprinty, powinniśmy się dość skrupulatnie ich trzymać i realizować plan. W Kanbanie jest to luźniejsze - nie nakazuje on sztywnych zasad, zatem można w dowolnym momencie zakończyć iterację, zrobić planning i rozpocząć kolejną, całkowicie zmieniając "styl gry" (priorytety zadań).
Która zatem z tych technik jest lepsza? No właśnie - nie ma jednoznacznej odpowiedzi. Jeden powie, że Kanban, drugi wskaże na Scruma. Warto wiedzieć, że wiele firm nieco luźniej podchodzi do tych wszystkich zasad. To znaczy wybierając Kanbana, wprowadzają role czy spotkania rodem ze Scruma. I w drugą stronę - pracując w Scrumie, naginają pewne zasady dotyczące sztywności zmian podczas sprintu, wymieniając zadania czy zmieniając priorytety. To wszystko ma nam pomóc w organizacji i dowiezieniu produktu, a nie sprawić, że nie będziemy spać po nocach, obawiając się tego, że znaleźliśmy krytyczny defekt, a jest dopiero początek sprintu.
Na ten moment, istotne jest dla Ciebie poznanie różnic i podstawowa wiedza o wspomnianych technikach - po szczegóły odsyłam do podlinkowanych w pierwszym zdaniu witryn.
Na koniec jeszcze przykład z życia QA. Wyobraź sobie, że znajdujesz defekt na stronie, którą testujesz. W przypadku Scruma, powinieneś stworzyć taska (z ładnym opisem i krokami do odtworzenia defektu, pamiętaj 😉) i dodać go do backloga. Następnie taki task powinien zostać wyestymowany, ewentualnie omówiony podczas refinementu, po czym wyciągnięty (do "active sprint") podczas jednego z przyszłych planningów. Chodzi o to, aby zaplanowana iteracja (sprint) nie została naruszona. W przypadku Kanbana nic nie stoi na przeszkodzie, aby dodać ładnie opisanego taska i zająć się nim od razu, jeżeli sytuacja na to pozwoli, przerywając na moment inne zadania. Ot, dużo luźniejsze podejście, nie? 😉
#2: Nowa premiera na YouTube
Chciałbym tylko przypomnieć, że kilka dni temu odbyła się premiera nowej części z serii "Problemy w pracy i jak im zaradzić". W drugiej części omawiam kolejne problemy, z którymi prędzej czy później przyjdzie się zmierzyć w branży Quality Assurance. Temat jest o tyle interesujący, że czasami tego typu rozważania pojawiają się na rekrutacjach. Warto zatem przemyśleć jak rozwiązalibyśmy problem uciekających terminów, konieczności nadgodzin czy zmieniających się dizajnów podczas testowania aplikacji. O tych i kilku innych sytuacjach opowiadam na YouTube. Zapraszam serdecznie 🙂
|