Informacje ogólne Ge Gdf520pgdww

Ludzie często utożsamiają Scrum z Agile, ponieważ Scrum koncentruje się na ciągłym doskonaleniu, które stanowi podstawową zasadę metodyki Agile. Jednak Scrum to ramy postępowania, dzięki którym realizuje się prace, podczas gdy Agile to sposób myślenia. Nie można tak po prostu stać się Agile, czyli „zwinnym”, ponieważ wymaga to zaangażowania całego zespołu w zmianę podejścia do dostarczania korzyści klientom. Można jednak wykorzystać ramy postępowania, takie jak Scrum, aby ułatwić przejście na taki sposób myślenia oraz wdrożenie zasad Agile w codziennej komunikacji i pracy.

Ramy postępowania Scrum są heurystyczne. Opierają się na ciągłym uczeniu i dostosowywaniu do zmiennych czynników. Wychodzi się w nich z założenia, że na początku projektu zespół nie wie wszystkiego i w miarę zdobywania doświadczenia będzie się rozwijał. Scrum jest skonstruowany tak, aby pomóc zespołom w naturalny sposób dostosować się do zmieniających się warunków i wymagań użytkowników, z uwzględnieniem modyfikacji priorytetów będącej częścią procesu oraz krótkich cykli wydawania, dzięki którym zespół może stale się uczyć i doskonalić.

Choć Scrum jest ustrukturyzowany, nie jest całkowicie sztywnym sposobem pracy. Sposób jego realizacji można dostosować do potrzeb każdej organizacji. Istnieje wiele teorii na temat tego, jak powinny pracować zespoły Scrum, aby odnieść sukces. Jednak ponad dziesięć lat doświadczenia we wspieraniu w realizacji zadań zespołów Agile w Atlassian wskazuje, że jasna komunikacja, przejrzystość i zaangażowanie w ciągłe doskonalenie powinny zawsze znajdować się w samym centrum wybranych wybranych ram postępowania. A reszta zależy od Ciebie.

Zespół Scrum

Zespół Scrum wymaga trzech konkretnych ról: product ownera, scrum mastera i zespołu tworzącego oprogramowanie. Z uwagi na to, że zespoły Scrum obejmują różne działy, w skład zespołu tworzącego oprogramowanie wchodzą nie tylko programiści, ale również testerzy, projektanci, specjaliści ds. UX i inżynierowie eksploatacji.

Product owner w Scrum

Product ownerzy są mistrzami w dziedzinie swojego produktu. Skupiają się oni na zrozumieniu wymagań biznesowych, klienta i rynku, a następnie ustalają priorytet prac, które będą realizowane przez zespół inżynierski. Skuteczni product ownerzy:

• Tworzą backlog produktu i nim zarządzają.
• Ściśle współpracują z firmą i zespołem, zapewniając, aby elementy prac zawarte w backlogu produktu były dla wszystkich zrozumiałe.
• Udziela zespołowi jasnych wskazówek dotyczących funkcji, które należy dostarczyć w następnej kolejności.

• Decyduje, kiedy dostarczyć produkt, skłaniając się przy tym w kierunku częstszych dostaw.

Product ownerem nie zawsze jest menedżer produktu. Product ownerzy koncentrują się na zapewnieniu, aby zespół tworzący oprogramowanie dostarczał najwyższą wartość dla firmy. Ponadto ważne jest, aby product owner był pojedynczą osobą. Żaden zespół tworzący oprogramowanie nie chce otrzymywać sprzecznych wskazówek od wielu product ownerów.

Scrum master

Scrum masterzy są mistrzami Scrum w swoich zespołach. Szkolą członków zespołu, product ownerów oraz inne osoby w firmie w zakresie procesu Scrum i poszukują możliwości doskonalenia swojej praktyki.

Skuteczny scrum master posiada dogłębną wiedzę na temat prac realizowanych przez zespół i może pomóc zespołowi w zoptymalizowaniu jego przejrzystości i przepływu dostaw. Jako główny koordynator, planuje zasoby (zarówno ludzkie, jak i logistyczne) wymagane na potrzeby planowania sprintu, spotkania standup, przeglądu sprintu i retrospektywy sprintu.

Zespół tworzący oprogramowanie w Scrum

Zespoły Scrum „odwalają całą robotę”. To mistrzowie zrównoważonych praktyk programistycznych. Najbardziej efektywne zespoły Scrum są zwarte, znajdują się w jednym miejscu i zazwyczaj składają się z pięciu do siedmiu członków. Przy określaniu rozmiaru zespołu najlepiej kierować się zasadą dwóch pizz Jeffa Bezosa, dyrektora generalnego Amazon (zespół powinien być na tyle mały, aby móc podzielić się dwoma pizzami).

Członkowie zespołu mają różne umiejętności i uczą się od siebie nawzajem, dzięki czemu nikt nie staje się wąskim gardłem w procesie dostarczania pracy. Mocne zespoły Scrum samodzielnie organizują swoją pracę i podchodzą do projektów z wyraźnym nastawieniem na „my”. Wszyscy członkowie zespołu pomagają sobie nawzajem, aby zapewnić skuteczne ukończenie sprintu.

To zespół Scrum wyznacza plan każdego sprintu. Jego członkowie prognozują ilość pracy, jaką ich zdaniem są w stanie wykonać w trakcie iteracji, biorąc pod uwagę prędkość osiąganą w dotychczasowych iteracjach. Stosowanie iteracji o stałej długości daje zespołowi tworzącemu oprogramowanie ważną wskazówkę na temat jego szacunków i procesu dostarczania, co z kolei przekłada się na rosnącą z czasem dokładność prognoz.

Artefakty Scrum

Zacznijmy od wskazania trzech artefaktów w Scrum. Artefakty to coś, co tworzymy, na przykład narzędzie do rozwiązania problemu. W Scrum te trzy artefakty to backlog produktu, backlog sprintu oraz przyrost zgodny z przyjętą definicją stanu „gotowe”. Są to trzy stałe w zespole Scrum, do których ciągle sięgamy i w które inwestujemy z biegiem czasu.

• Backlog produktu to podstawowa lista prac do wykonania prowadzona przez product ownera lub menedżera produktu. Jest to dynamiczna lista funkcji, wymagań, ulepszeń i poprawek, która stanowi zestaw danych wejściowych backlogu sprintu. Jest to w zasadzie lista zadań do wykonania dla zespołu. Backlog produktu jest w ciągłym użyciu. Product owner prowadzi go, modyfikując priorytety zawartych w nim zadań, ponieważ w miarę zdobywania nowych informacji i pojawiania się zmian na rynku poszczególne elementy mogą być nieadekwatne, a problemy można rozwiązać w inny sposób.
• Backlog sprintu to lista elementów, historyjek użytkowników lub poprawek błędów wybranych przez zespół programistyczny do implementacji w bieżącym cyklu sprintu. Przed każdym sprintem w trakcie spotkania dotyczącego planowania sprintu (omówionego w dalszej części artykułu) zespół wybiera, które elementy backlogu produktu będzie realizował w trakcie sprintu. Backlog sprintu może być elastyczny i ewoluować w trakcie sprintu. Nie może jednak doprowadzić do odejścia od podstawowego celu sprintu, czyli tego, co zespół chce osiągnąć w trakcie bieżącego sprintu.
• Przyrost (lub cel sprintu) jest zdatnym do użycia produktem końcowym sprintu. W Atlassian zwykle prezentujemy „przyrost” podczas demonstracji na koniec sprintu, w trakcie której zespół pokazuje, co zostało ukończone podczas sprintu. W praktyce możesz nie spotkać się ze słowem „przyrost”, ponieważ często określa się go mianem tego, co zespół rozumie pod pojęciem stanu „Gotowe”, kamienia milowego, celu sprintu, a nawet pełnej wersji lub wydanego epiku. Wszystko zależy od sposobu, w jaki zespoły definiują pojęcie stanu „Gotowe” oraz cele sprintu. Przykładowo niektóre zespoły decydują się na wydawanie czegoś dla klientów pod koniec każdego sprintu. W związku z tym w ich rozumieniu stan „gotowe” będzie tożsamy ze stanem „wydane”. Takie podejście może być jednak nierealne w przypadku innych typów zespołów. Załóżmy, że pracujesz nad produktem serwerowym, który możesz wysyłać do klientów tylko co kwartał. Wówczas nadal możesz zdecydować się na pracę w dwutygodniowych sprintach, ale stan „gotowe” może w tym przypadku oznaczać ukończoną część większej całości, która zostanie wysłana w jednej turze. Należy jednak pamiętać, że im dłuższy okres do wydania oprogramowania, tym większe ryzyko przekroczenia terminu.

Jak widać, istnieje wiele wariantów, nawet w obrębie artefaktów, które zespół może definiować po swojemu. Dlatego ważne jest zachowanie otwartości na rozwój sposobu prowadzenia działań, nawet pod względem artefaktów. Może się zdarzyć, że przyjęte rozumienie terminu „gotowe” będzie powodowało w zespole stres i konieczne będzie cofnięcie się oraz wybranie nowej definicji.

Porada eksperta:

W odniesieniu do ram postępowania powinno się przyjąć takie samo, zgodne z nurtem Agile podejście, jak do produktu. Warto poświęcić chwilę, aby sprawdzić, jak przebiegają działania, w razie potrzeby wprowadzić korekty i nie starać się forsować niczego tylko dla zachowania zgodności.

Spotkania lub wydarzenia w Scrum

Jednym z lepiej znanych elementów ram postępowania Scrum jest zestaw następujących po sobie wydarzeń lub spotkań, które zespoły Scrum regularnie organizują. Największe różnice między zespołami uwidaczniają się w ich podejściu do tego typu wydarzeń. Niektóre zespoły uważają je za uciążliwe i powtarzalne, podczas gdy dla innych stanowią niezbędny element odprawy. My radzimy zacząć od zastosowania wszystkich wydarzeń w trakcie dwóch sprintów, aby sprawdzić, jaki będzie ich odbiór. Następnie można przeprowadzić szybką retrospektywę, aby stwierdzić, w których obszarach warto wprowadzić poprawki.

Poniżej znajduje się lista wszystkich kluczowych wydarzeń, w jakich może uczestniczyć zespół Scrum:

1. Porządkowanie backlogu: czasami nazywane również pielęgnowaniem backlogu, to wydarzenie należące do obowiązków product ownera. Głównym zadaniem product ownera jest kierowanie pracami nad produktem w sposób zgodny z wizją produktu oraz ciągłe monitorowanie rynku oraz klienta. W tym celu taka osoba prowadzi tę listę, wykorzystując informacje zwrotne od użytkowników oraz zespołu programistycznego do ustalania priorytetów, porządkowania elementów listy i utrzymywania jej w gotowości do podjęcia prac w dowolnej chwili. Więcej informacji na temat prowadzenia dobrego backlogu znajdziesz tutaj.

2. Sprint planning: The work to be performed (scope) during the current sprint is planned during this meeting by the entire development team. This meeting is led by the scrum master and is where the team decides on the sprint goal. Specific user stories are then added to the sprint from the product backlog. These stories always align with the goal and are also agreed upon by the scrum team to be feasible to implement during the sprint.

   At the end of the planning meeting, every scrum member needs to be clear on what can be delivered in the sprint and how the increment can be delivered.

3. Sprint: sprint to konkretny przedział czasu, w trakcie którego zespół Scrum współpracuje nad ukończeniem przyrostu. Zazwyczaj sprinty trwają dwa tygodnie, jednak niektórym zespołom łatwiej opracować zakres dla okresów tygodniowych, a innym dostarczanie wartościowych przyrostów ułatwiają miesięczne sprinty. Dave West ze Scrum. org radzi, aby sprinty były tym krótsze, im bardziej złożona praca i im więcej niewiadomych. Jednak tak naprawdę wszystko zależy od Twojego zespołu. Jeśli taki model nie działa, nie obawiaj się wprowadzania zmian! W trakcie tego okresu product owner i zespół tworzący oprogramowanie mogą w razie potrzeby renegocjować zakres. W tym tkwi istota empirycznego charakteru Scrum.

   Wszystkie wydarzenia — od planowania po retrospektywę]— odbywają się w trakcie sprintu. Po ustaleniu konkretnego przedziału czasu dla sprintu nie powinno się go zmieniać w trakcie procesu tworzenia produktu. Dzięki temu zespołowi łatwiej będzie się uczyć na dotychczasowych doświadczeniach i zastosować wyciągnięte wnioski do przyszłych sprintów.

4. Codzienny scrum lub spotkanie standup: jest to bardzo krótkie, codzienne spotkanie, które, żeby było prościej, odbywa się o tej samej porze (zazwyczaj rano) i w tym samym miejscu. Wiele zespołów stara się zakończyć to spotkanie w ciągu 15 minut, jednak to jedynie wskazówka. Bywa ono również nazywane „codziennym standupem”, co podkreśla krótki czas jego trwania. Celem codziennego scrumu jest bieżące informowanie wszystkich członków zespołu, upewnienie się, że dążą do realizacji celu sprintu i zaplanowanie działań na kolejne 24 godziny.

   W trakcie spotkania standup zgłaszane są wszelkie obawy w zakresie realizacji celów sprintu oraz blokery.

   Powszechną praktyką podczas przeprowadzania spotkań standup jest poproszenie każdego członka zespołu o udzielenie odpowiedzi na trzy pytania w kontekście dążenia do osiągnięcia celu sprintu:

   • Co udało mi się zrobić wczoraj?
   • Co mam zamiar zrobić dzisiaj?
   • Czy istnieją jakieś przeszkody?

   Widzieliśmy jednak spotkania, które szybko zamieniały się w odczytywanie notatek z kalendarza na dzień poprzedni i kolejny. Ideą spotkania standup jest sprowadzenie rozpraszającej gadaniny do codziennego spotkania, aby zespół mógł skoncentrować się na pracy przez resztę dnia. Jeśli więc zamieni się on w codzienne odczytywanie kalendarzy, nie bój się wprowadzić zmian i iść w bardziej kreatywnym kierunku.

5. Przegląd sprintu: pod koniec sprintu zespół zbiera się na nieformalną sesję w celu przeprowadzenia demonstracji lub kontroli przyrostu. Zespół tworzący oprogramowanie przedstawia elementy backlogu oznaczone jako „Gotowe”, aby interesariusze i inni członkowie zespołu mogli się do nich ustosunkować. Product owner może zdecydować, czy taki przyrost zostanie wydany, i w większości przypadków tak właśnie się dzieje.

   Takie spotkanie przeglądowe odbywa się również w sytuacji, gdy product owner modyfikuje backlog produktu w oparciu o bieżący sprint w sposób, który wpływa na przebieg sesji planowania kolejnego sprintu. W przypadku sprintów miesięcznych warto ograniczyć czas przeglądu sprintu do maksymalnie czterech godzin.

6. Retrospektywa sprintu: retrospektywa polega na zebraniu zespołu w celu udokumentowania i omówienia sukcesów i porażek w kontekście sprintu, projektu, ludzi lub relacji, narzędzi, a nawet konkretnych wydarzeń. Chodzi o stworzenie okazji, aby zespół mógł pochylić się na tym, co poszło dobrze i co trzeba poprawić następnym razem, a mniej na tym, co poszło nie tak.

Zacznij korzystać bezpłatnie z szablonu Jira Scrum

Scrum, Kanban i Agile

Scrum stanowi tak popularne ramy postępowania Agile, że często Scrum i Agile są mylnie ze sobą utożsamiane. Istnieją jednak i inne ramy postępowania, takie jak Kanban, który jest popularną alternatywą. Niektóre firmy decydują się nawet na przyjęcie modelu hybrydowego Scrum i Kanban funkcjonującego pod nazwą „Scrumban” lub „Kanplan”, który jest po prostu modelem Kanban z backlogiem.

Zarówno w Scrum, jak i w Kanban do monitorowania postępów prac wykorzystuje się metody wizualne, takie jak tablica Scrum czy tablica Kanban. W obydwu przypadkach nacisk kładzie się na wydajność i podział złożonych zadań na mniejsze fragmenty łatwiejszych w zarządzaniu prac, jednak ich sposoby osiągnięcia tego celu są różne.

Scrum koncentruje się na mniejszych iteracjach o stałej długości. Po ustaleniu okresu przewidzianego na sprint wskazuje się historyjki lub pozycje backlogu produktu, które można wdrożyć w trakcie danego cyklu sprintu. Z kolei w Kanban liczba zadań lub prac w toku (limit WIP) do wdrożenia w ramach bieżącego cyklu jest na początku stała. Następnie oblicza się wstecznie czas potrzebny do zaimplementowania tych funkcji.

Kanban nie jest tak ustrukturyzowany jak Scrum. Poza limitem prac w toku ten model pozostawia stosunkowo duże pole do interpretacji. Natomiast w Scrum implementacja opiera się na kilku kategorycznych koncepcjach, takich jak przegląd sprintu, retrospektywa, codzienny scrum itp. W tym modelu kładzie się również nacisk na interdyscyplinarność, czyli zdolność zespołu Scrum do działania w taki sposób, aby osiągnięcie celu było możliwe niezależnie od członków zewnętrznych. Zebranie zespołu interdyscyplinarnego nie jest proste. Pod tym względem Kanban znacznie łatwiej zastosować, natomiast Scrum uważa się za fundamentalną zmianę w sposobie myślenia i funkcjonowania zespołu tworzącego oprogramowanie.

Commitment

Because scrum teams are small and agile, each team member plays a significant role in the team’s success. Therefore, each team member should agree to commit to performing tasks they can complete and not overcommit. There should be frequent communication regarding work progress, often in stand-ups.

Courage

Courage for a scrum team is simply the bravery to question the status quo or anything that hampers its ability to succeed. Scrum team members should have the courage, and feel safe enough, to try new things. A scrum team should have the courage and feel safe to be transparent about roadblocks, project progress, delays, and so on.

Focus

At the heart of the workflow for scrum teams is the sprint, a focused and specified period of time where the team completes a set amount of work. The sprint provides structure but also focus to complete the planned amount of work.

Openness

The daily stand-up fosters an openness that allows teams to talk openly about work in progress and blockers. At Atlassian we often have our scrum teams address these questions:

• What did I work on yesterday?
• What am I working on today?
• What issues are blocking me?

This helps to highlight progress and identify blockers. It also helps to strengthen the team when everyone shares progress.

Respect

The strength of an agile team lies in its collaboration and recognizing that each team member contributes to work in a sprint. They celebrate each other’s accomplishments and are respectful to one another, the product owner, stakeholders, and the scrum master.

Scrum, kanban, and agile

Scrum is such a popular agile framework that scrum and agile are often misunderstood to be the same thing. But there are other frameworks, like kanban, which is a popular alternative. Some companies even choose to follow a hybrid model of scrum and kanban, which has acquired the name of "Scrumban" or "Kanplan, " which is Kanban with a backlog.

Both scrum and kanban use visual methods such as the scrum board or kanban board to track the progress of work. Both emphasize efficiency and splitting complex tasks into smaller chunks of manageable work, but their approaches towards that goal are different.

Scrum focuses on smaller, fixed-length iterations. Once the time period for a sprint is finalized, the stories or product backlog entries that can be implemented during this sprint cycle are then determined. In kanban, however, the number of tasks or the work in progress (WIP limit) to be implemented in the current cycle is fixed at first. The time taken to implement these features is then calculated backward.

Kanban is not as structured as scrum. Other than the WIP limit, it is fairly open to interpretation. Scrum, however, has several categorical concepts enforced as part of its implementation such as sprint review, retrospective, daily scrum, etc. It also insists on cross-functionality, which is the ability of a scrum team to not depend on external members to achieve their goals. Putting together a cross-functional team is not straightforward. In that sense, kanban is easier to adapt whereas scrum can be considered as a fundamental shift in the thought process and functioning of a development team.

Ale dlaczego Scrum?

Same ramy postępowania Scrum są proste. Reguły, artefakty, wydarzenia i role są łatwe do zrozumienia. Przyjęte w nich częściowo nakazowe podejście faktycznie pomaga wyeliminować niejasności w procesie tworzenia oprogramowania, pozostawiając jednocześnie wystarczająco dużo przestrzeni, aby firmy mogły nadać im własny, indywidualny charakter.

Możliwość porządkowania złożonych zadań w łatwe do zarządzania historyjki użytkowników sprawia, że rozwiązanie to doskonale sprawdza się w przypadku trudnych projektów. Ponadto wyraźne rozgraniczenie ról i planowanych wydarzeń zapewnia przejrzystość i zbiorową odpowiedzialność na każdym etapie cyklu programistycznego. Szybkie wydania podtrzymują wysoki poziom motywacji zespołu, a użytkownicy są zadowoleni, ponieważ widzą postępy w krótkim czasie.

Jednak dogłębne zrozumienie Scrum może zająć sporo czasu, zwłaszcza jeśli zespół tworzący oprogramowanie jest przyzwyczajony do typowego modelu kaskadowego. Koncepcje mniejszych iteracji, codziennych spotkań Scrum, przeglądów sprintów i wyznaczenie scrum mastera mogą stanowić trudną zmianę kulturową dla nowego zespołu.

Jednak długoterminowe korzyści znacznie przewyższają czas poświęcony na początkową naukę. Powodzenie, z jakim stosuje się Scrum w tworzeniu złożonych produktów sprzętowych i programowych w różnych branżach, sprawia, że te ramy postępowania są atrakcyjnym rozwiązaniem dla Twojej organizacji.

Jeśli chcesz nauczyć się korzystania z metodyki Scrum w Jira Software, zapoznaj się z tym samouczkiem.

Claire Drumond jest specjalistką od strategii marketingu, mówczynią i autorką tekstów w firmie Atlassian. Ma na koncie liczne artykuły opublikowane na blogach Trello i Atlassian, jak również udział w tworzeniu różnorodnych publikacji w portalu Medium, takich jak HackerNoon, Art+Marketing czy PoetsUnlimited. Udziela się na konferencjach na całym świecie, poruszając tematy metodyk zwinnych, znoszenia barier komunikacyjnych w przedsiębiorstwach oraz budowania empatii.