Co to jest Agile?

Zakończone

Użyliśmy terminu agile w poprzednim module, aby opisać jeden z podstawowych elementów kultury metodyki DevOps, reprezentujących możliwość szybkiego reagowania na opinie i potrzeby klientów. Ten termin pojawił się również kilka razy w lekcji opisującej korelację między metodykami DevOps i cyklem życia aplikacji. Jednak istnieje również inne, bardziej szczegółowe znaczenie metody Agile (w formacie skapitalizowanym), które opisuje podejście do tworzenia oprogramowania i zarządzania projektami. Takie podejście jest często kojarzone z praktykami metodyki DevOps. W naszym przykładowym scenariuszu przejście z tradycyjnego podejścia kaskadowego do metody Agile pomogłoby organizacji zrealizować szereg korzyści z metodyki DevOps. W tej lekcji zapoznasz się z podstawowymi cechami metodyki Agile i zbadaj jej korelację z metodykami DevOps.

Zasady i wartości agile

Agile to podejście do tworzenia oprogramowania, które promuje współpracę zespołową, ciągłe ulepszanie i automatyzację, z ostatecznym celem szybszego, bardziej niezawodnego i skoncentrowanego na klientach dostarczania oprogramowania. Termin pochodzi z Manifestu Agile utworzonego w 2001 roku przez grupę deweloperów oprogramowania, zapewniając zestaw wytycznych dotyczących nowoczesnego tworzenia oprogramowania. Manifest zawierał cztery podstawowe oświadczenia, które priorytetowo określały osoby i interakcje, rozwiązania robocze i współpracę klientów nad sztywnymi procesami i narzędziami. W szczególności te oświadczenia przypisywały większą wartość:

• Osoby i interakcje dotyczące procesów i narzędzi.
• Działające oprogramowanie ponad obszerną dokumentację.
• Współpraca z klientem ważniejsza niż negocjacje kontraktowe.
• Reagowanie na zmiany zamiast ścisłego trzymania się planu.

Metody i praktyki agile

Zasady Manifestu Agile i Agile zapewniają zestaw wartości i wytycznych, ale celowo nie są one normatywne pod względem określonych metod i praktyk. Zamiast tego agile ma być elastyczna i łatwo dostosowywana, umożliwiając organizacjom i zespołom wybór bardziej szczegółowego podejścia zgodnie z ich preferencjami i potrzebami.

Te szczegółowe, kompleksowe podejścia są często określane jako struktury. Ich celem jest uwzględnienie wszystkich faz cyklu życia metodyki DevOps, w tym planowania, programowania, dostarczania i operacji. Niektóre z bardziej popularnych struktur Agile to Scrum i Kanban.

Co to jest Scrum?

Scrum to struktura używana przez zespoły do zarządzania pracą i rozwiązywania problemów wspólnie w krótkim czasie (zwykle między jednym i czterema tygodniami) iteracji nazywanych sprintami. Aby ułatwić współpracę i postęp, struktura sprintów opiera się na zdarzeniach, artefaktach i rolach.

• Events, często określane jako ceremonie, obejmują spotkania odbywające się codziennie (Daily Scrum, zazwyczaj ograniczone do 15 minut, znane również jako codzienne standup) oraz na początku i na końcu każdego sprintu (Sprint Planowanie, Przegląd Sprintu, i Retrospektywa Sprintu).
• Artefakty definiują priorytetową listę funkcji, ulepszeń i poprawek do opracowania. Takie artefakty mogą obejmować zakres projektu lub sprintu (odpowiednio Backlog Produktu lub Backlog Sprintu), lub mogą one pomóc na spotkaniach Daily Scrum (tablice zadań i wykresy spalania sprintu). Tablica zadań udostępnia wizualny sposób śledzenia postępu każdego elementu listy prac. Wyświetla on elementy listy prac podzielone na zadania wymagane do jego ukończenia. Zadania są umieszczane w oddzielnych kolumnach (oznaczonych etykietą Do wykonania, W toku i Gotowe) na podstawie ich stanu. Wykres spalania sprintu służy jako wizualny wskaźnik tego, czy zespół jest na właściwej drodze, aby ukończyć przydzieloną pracę do końca sprintu. Składa się z wykresu, który wyświetla dzienną sumę pozostałych prac, zwykle pokazaną w godzinach.
• Role obejmują właściciela produktu, scrum master i zespół Scrum, z których każdy ma jasno zdefiniowane obowiązki. Właściciel produktu reprezentuje interesariuszy projektu i jest odpowiedzialny za definiowanie, utrzymanie i określanie priorytetów listy prac produktu. Scrum master nadzoruje proces Scrum, szuka obszarów pod kątem ulepszeń, rozwiązywania wszelkich problemów blokujących i zapewnienia, że zasady Scrum są przestrzegane. Zespół Scrum jest odpowiedzialny za budowanie produktu, z własnością jego składników inżynieryjnych i jakościowych.

Podczas wydarzenia planowania sprintu zespół wybiera elementy backlogu do realizacji w nadchodzącym sprincie. Wybór jest dokonywany na podstawie priorytetu i szacowanej ilości pracy wymaganej do ukończenia elementu. Metryka nazywana prędkością służy do oszacowania ilości pracy, którą zespół może wykonać w danym sprincie. Po rozpoczęciu sprintu zespół decyduje, jak pracować nad elementami Backlogu Sprintu. Podczas przeglądu Sprintu zespół demonstruje swoje osiągnięcia przed interesariuszom. Retrospektywa sprintu stanowi element ciągłego uczenia się. Służy ona jako możliwość przejrzenia ostatnio ukończonego przebiegu, zidentyfikowania obszarów pod kątem poprawy i określenia listy akcji na potrzeby następnego przebiegu.

Co to jest Kanban?

Kanban jest japońskim słowem dla tablicy lub billboardu. W kontekście Agile koncepcja Kanbana została pomyślana jako środek do poprawy wydajności procesów produkcyjnych, ale w ostatnich latach stała się powszechna w projektach programistycznych.

Kluczową zasadą tego podejścia jest wizualizacja pracy związanej z projektem w formie tablic Kanban. Mogą to być tablice fizyczne lub aplikacje programowe, które wyświetlają karty ułożone w kolumny reprezentujące stan poszczególnych elementów projektu. Często używane nazwy kolumn to To-Do, Doing i Done, chociaż zespoły mogą dostosować je tak, aby dokładnie odzwierciedlały wszystkie odpowiednie etapy w przepływie pracy dostarczania projektu (takim jak programowanie i testowanie). Wizualizowanie pracy jako kart w różnych stanach na tablicy upraszcza ocenę stanu projektu i identyfikowanie potencjalnych problemów z produktywnością.

Te karty odpowiadają elementom backlogu produktu w ramach Scrum. Karty można dostosować w celu uwzględnienia odwołań do innych elementów w procesie dostarczania produktu, takich jak zadania i przypadki testowe.

Chociaż koncepcja backlogu jest powszechna w Kanban i Scrum, ważne jest, aby pamiętać, że Kanban jest bardziej elastyczny i nie wymaga iteracji. Elementy robocze można dodawać, ponownie zapisywać lub usuwać z listy prac na podstawie pojemności zespołu oraz zmieniających się potrzeb projektu lub usługi zarządzanej za pomocą narzędzia Kanban.

W szczególności Kanban promuje użycie modelu pobierania, w którym interesariusze dodają żądania do listy zadań, elementów lub prac, które należy wykonać. Zespół programistyczny wybiera elementy z listy prac i dodaje je do aktywnego procesu roboczego w zależności od ich priorytetu i dostępności zasobów zespołu. Minimalizuje to problemy z jakością związane z modelem "pull", w którym interesariusze arbitralnie przypisują pracę do zespołów programistycznych, często z nierealistycznymi terminami. Ponadto w celu optymalizacji produktywności Kanban obsługuje nakładanie limitów liczby elementów, nad którymi pracuje obecnie zespół programistyczny, nazywany pracą w toku lub po prostu WIP.

Ramy Kanban opierają się również na czasie realizacji i czasie cyklu w celu mierzenia skuteczności i wydajności pracy. Czas realizacji to całkowity czas potrzebny na przejście elementu roboczego z jego powstania do momentu dostarczenia go do klienta. Czas cyklu reprezentuje czas trwania rzeczywistej pracy nad zadaniem po wprowadzeniu do aktywnego etapu pracy.

Innym często używanym składnikiem kanban jest skumulowany wykres przepływu (CFD). Jest to wykres ilustrujący, jak zmienia się liczba przedmiotów w każdym stanie z upływem czasu, zazwyczaj na przestrzeni kilku tygodni. Przypomina on skumulowany wykres szeregów czasowych z osią poziomą reprezentującą oś czasu i osią pionową reprezentującą skumulowaną liczbę elementów roboczych. Każdy stan jest wyświetlany jako obszar w innym kolorze, co ułatwia identyfikowanie trendów w przetwarzaniu zaległych elementów. Wzrost rozmiaru co najmniej jednego kolorowego obszaru zwykle wskazuje na problem w przepływie pracy, taki jak wąskie gardło lub nieefektywność.

Jakie są różnice między scrum i Kanban?

Zarówno Scrum, jak i Kanban są uważane za struktury Agile o wspólnym celu poprawy wydajności i skuteczności tworzenia oprogramowania. Jednak każdy z nich oferuje inne podejście do osiągnięcia tego celu, w tym ich odpowiednich zasad i praktyk. W szczególności:

• Cykl pracy: Scrum używa przebiegów o stałej długości, podczas gdy Kanban działa na podstawie modelu ciągłego przepływu zadań, a praca jest ściągana przez zespoły programistyczne zgodnie z dostępnością zasobów.
• Role i ceremonie: Scrum ma jasno zdefiniowane role i ceremonie, podczas gdy Kanban nie przepisywać żadnych, zamiast tego pozwala zespołom dostosować je zgodnie z ich konkretnymi potrzebami.
• planowanie pracy: Scrum używa priorytetowego backlogu z pracami zaangażowanymi podczas planowania sprintu. Kanban używa dynamicznego rejestru zadań bez zobowiązań na określony okres. Ponadto Kanban obsługuje koncepcję limitów WIP.
• Adaptacja do zmian: Scrum zniechęca do wprowadzania zmian do zatwierdzonej pracy podczas sprintu. Kanban ułatwia dostosowanie się do zmian w dowolnym momencie.
• Wizualizacje: Scrum używa tablic sprintu i wykresów spadku. Kanban opiera się na tablicach Kanban.
• Metrics: Scrum używa metryk związanych z przebiegami, takich jak prędkość i wykresy spalania. Kanban podkreśla takie metryki jak czas realizacji i czas cyklu.