„Więc chcę ci opowiedzieć o Agile i Scrumie ”.
„Na początku XXI wieku sposób, w jaki ludzie myśleli o programowaniu, został wywrócony do góry nogami”.
„Wszyscy byli przekonani, że planowanie długoterminowe nie działa, więc postanowili całkowicie z niego zrezygnować”.
— Jak oni to zrobili?
"Oto jak."
„Wynaleźli najbardziej elastyczne podejście do zarządzania projektami, jakie było możliwe”.
Oto główne idee stojące za zwinnym rozwojem :”
- ludzie i komunikacja są ważniejsze niż procesy i narzędzia;
- działający produkt jest ważniejszy niż wyczerpująca dokumentacja;
- współpraca z klientem jest ważniejsza niż dotrzymanie warunków umowy;
- chęć zmiany jest ważniejsza niż trzymanie się pierwotnego planu.
Oto zasady szybkiego rozwoju:
- usatysfakcjonować klienta dostarczając wartościowe oprogramowanie wcześnie iw sposób ciągły;
- mile widziane zmiany wymagań nawet pod koniec rozwoju (może to zwiększyć konkurencyjność produktu końcowego);
- często dostarczać działające oprogramowanie (co miesiąc lub co tydzień lub częściej);
- ścisła codzienna komunikacja między klientem a programistami przez cały czas trwania projektu;
- nad projektem pracują zmotywowane osoby, którym zapewnione są niezbędne warunki pracy, wsparcie i zaufanie;
- preferowaną metodą przekazywania informacji jest rozmowa osobista (twarzą w twarz);
- działające oprogramowanie jest najlepszą miarą postępu;
- sponsorzy, programiści i użytkownicy powinni mieć możliwość utrzymania stałego tempa przez czas nieokreślony;
- ciągły nacisk na doskonalenie doskonałości technicznej i projektowania przyjaznego dla użytkownika;
- prostota to sztuka unikania zbędnej pracy;
- najlepsze wymagania techniczne, projekt i architektura pochodzą od samoorganizującego się zespołu;
- ciągłe dostosowywanie się do zmieniających się warunków.
„Głównym problemem związanym z tworzeniem oprogramowania było to, że na żadnym etapie żaden z uczestników nie miał pełnej informacji o tym, co robić”.
„Klient może powiedzieć, jak wyobraża sobie program, ale coś pominie lub uzna coś za pewnik”.
„Kierownik generalnie musi tłumaczyć wymagania z żargonu programistycznego na język klienta iz powrotem”.
"Jest za dużo niepewności"
„Często wymagania klienta są takie: zrób to w jakiś sposób, a potem mi pokaż – jeśli mi się to nie podoba, możesz to przerobić”.
– Uch… to okropne.
„Zgodnie z nowym paradygmatem programiści nie rozwijają już produktu ani programu. Zamiast tego wdrażają funkcjonalność, której potrzebuje klient”.
"Co za różnica?"
„No cóż, załóżmy, że opracowanie programu zajmowało kiedyś rok. I musiało upłynąć sześć miesięcy, zanim było na co patrzeć. To jak budowanie dużego domu: najpierw kopie się dół pod fundament, potem wylewa się fundament, zbudować ściany, dach, wykończenia itp.”
„Ale teraz programiści starają się udostępnić potrzebną funkcjonalność tak szybko, jak to możliwe. To tak, jakby najpierw zbudować chatę, potem przyczepę mieszkalną, potem mały dom, a dopiero potem duży dom – na raty”.
„Biorąc pod uwagę , że klient prawdopodobnie nie wie dokładnie, czego chce, jest to bardzo rozsądne podejście”.
„Załóżmy, że klient chce duży domek myśliwski”.
„Deweloperzy budują mu taki mały. Mieszka w nim przez zimę. Potem stwierdza, że nie lubi drewnianych domów. Zróbmy murowany”.
„Latem mieszka nad jeziorem, ale komary zjadają go żywcem. Słyszał gdzieś, że jeziora są fajne, więc marzył o jednym. Ale teraz nie chce jeziora. I będzie łatwiej budować dom w ten sposób: brak jeziora to brak zagrożenia powodziowego, a dom można postawić na ziemi zamiast na palach, co będzie o 25% szybsze”.
„Ciekawa analogia. Czy klienci naprawdę tak często zmieniają swoje wymagania?”
„Tak, ale problemem nie jest klient”.
„Po pierwsze, bardzo trudno jest sobie wyobrazić, jak sprawy potoczą się w przyszłości. Menedżerowie, testerzy i programiści też to robią. Zmieniają też zdanie w zależności od tego, jak potoczą się sprawy”.
„Po drugie, czy wymagania klienta nie są najważniejsze? W końcu celem całej tej pracy jest stworzenie tego, czego potrzebuje klient , a nie tego, co początkowo powiedział ”.
„Rzeczywiście kiedyś to działało tak: analitycy biznesowi robili listę wszystkich wymagań. Wpisywali tę listę do umowy, podpisywali ją i pracowali tylko według listy”.
„Gdyby na liście brakowało czegoś, czego klient naprawdę potrzebował , ale zapomniał, nikt by nic z tym nie zrobił”.
„Rozumiem. Łatwiej jest postępować zgodnie z planem, ale nie wszystko da się zrobić zgodnie z planem!”
"Dokładnie."
„Dlatego wynaleziono zwinne metody programowania”.
„A dzisiaj opowiem wam o Scrumie — najpopularniejszym z nich.
„Podstawową cechą Scruma jest podział rozwoju projektu na małe iteracje — zwykle trwające 2-4 tygodnie. Każda iteracja nazywana jest sprintem”.
„Na początku sprintu odbywa się spotkanie planistyczne sprintu. Trwa ono 3-4 godziny.”
„Na koniec następuje pokaz wszystkich w pełni wykonanych zadań”.
„Oto, jak wszystko zwykle działa:”
„Przed pierwszym sprintem klient (lub przedstawiciel klienta) tworzy listę wymagań, czyli zestaw rzeczy, które program powinien być w stanie wykonać. Te wymagania są zwykle nazywane historiami użytkowników, a klient zwykle zwany właścicielem produktu ”.
„Nazywa się go właścicielem produktu , ponieważ produkt jest dla niego napisany. On i tylko on określa listę wymagań — co, kiedy iw jakiej kolejności”.
„Dodatkowo właściciel produktu zazwyczaj wyznacza priorytety zadaniom. Zadania o najwyższym priorytecie będą realizowane w pierwszej kolejności. Cała lista wymagań nazywana jest też backlogiem produktu ”.
„Kiedy rozpoczyna się sprint, wszyscy zbierają się na spotkanie. Scrum master , zwykle członek zespołu, zwykle prowadzi spotkanie. Celem spotkania jest wybranie zadań ( historia użytkownika ) do bieżącego sprintu (iteracja rozwoju). "
„Najpierw zespół przypisuje każdemu zadaniu przybliżone oszacowanie w abstrakcyjnych osobodniach, zwanych również punktami fabularnymi. Następnie zespół decyduje, ile zadań będzie miał czasu na wykonanie podczas sprintu”.
„Znowu to zespół sam decyduje, ile zadań będzie miał czas na wykonanie w trakcie sprintu”.
„Powiedzmy, że właściciel produktu oczekiwał, że zespół wybierze 7 pierwszych zadań, ale wybrał tylko 5, następnie zadania 6 i 7 są odkładane na następny sprint. Jeśli właścicielowi produktu to nie odpowiada , może podnieść priorytet zadań 6 i 7, aby upewnić się, że zostaną wybrane, ale wtedy niektóre inne zadania wypadną ze sprintu”.
„ Mistrz scrum może również zaproponować podzielenie niektórych zadań na mniejsze i ustalenie dla nich różnych priorytetów, aby właściciel produktu był jak najbardziej zadowolony”.
„O to właśnie chodzi w spotkaniu: zadania można zmieniać i dzielić, zmieniać priorytety itp. To jest praca, której na początku nie było widać, ale która wnosi wiele wartości”.
„Rozumiem. To jak prowadzenie samochodu. Nawet jeśli początkowo wydaje ci się, że wystarczy jechać prosto, w rzeczywistości musisz stale unikać dziur, skręcać w prawo i lewo oraz wyprzedzać innych lub pozwalać im się wyprzedzić”.
— Tak, coś takiego.
„Lista zadań wybranych do sprintu nazywana jest backlogiem sprintu ”.
„Programiści decydują, kto co będzie robił i dopiero wtedy zabierają się do pracy”. Aby poprawić efektywność, Scrum sugeruje, aby codziennie odbywało się 5-15 minutowe spotkanie, na którym każdy może opowiedzieć sobie, co robili wczoraj i jakie są zamierza zrobić dzisiaj”.
„Praca zespołowa. Szanuję to!”
„Aby ułatwić wizualizację, zwykle zaleca się wyświetlanie aktualnego statusu sprintu na specjalnej tablicy:”
„Zwróć uwagę na trzy kolumny po lewej stronie”.
„Skrócone nazwy zadań są zapisywane na karteczkach samoprzylepnych. Karteczki są umieszczane w różnych kolumnach w zależności od ich statusu (planowane, w toku, wykonane)”.
„Po prawej stronie możesz zobaczyć wykres wypalania . Dla każdego dnia ten wykres zawiera listę zadań, które nadal pozostają niewykonane. W idealnej sytuacji liczba nieukończonych zadań spada do zera podczas sprintu”.
„Kiedy sprint się kończy, scrum-master daje demo , aby pokazać listę wszystkiego, co zostało całkowicie ukończone”.
„Następnie organizuje spotkanie podsumowujące sprint , które również trwa kilka godzin. Podczas tego spotkania uczestnicy zwykle próbują dowiedzieć się, co poszło dobrze, a co (i jak) można było zrobić lepiej”.
„Zwykle po 2-3 sprintach można zidentyfikować i wyeliminować główne problemy uniemożliwiające wydajniejszą pracę zespołu. Prowadzi to do większej produktywności bez zwiększania obciążenia zespołu. Nie było to możliwe przed erą zwinnych metodologii. ”
„Czasami podczas sprintu odbywa się również spotkanie groomingowe. Ma ono na celu zaplanowanie kolejnego sprintu. Na tym spotkaniu uczestnicy zwykle ustalają priorytety zadań. Mogą też podzielić niektóre zadania na części i/lub dodać nowe zadania do backlogu produktu . ”
„Cóż, w zasadzie to wszystko, co mam. To tylko przegląd. Nie da się tego wszystkiego wyjaśnić w kilku słowach, ale tutaj możesz przeczytać dobry artykuł na ten temat:”
GO TO FULL VERSION