Zwinny lub jak sprawić, by klient był szczęśliwy.

  1. Scrum
  2. Role
  3. Procesy
  4. Kanban
  5. XP (ekstremalne programowanie)

Agile to manifest rozwoju oprogramowania, lub, po prostu, pomysł, podejście do tworzenia produktów poprzez ciągłe dostarczanie cennej funkcjonalności przepływu pracy.

Agile wdraża metodologie:

  • Scrum - struktura zarządzania;
  • XP - praktyka inżynierska;
  • Kanban to organizacja wspierająca.

Istnieje również wiele innych metodologii, które nie są tak popularne, ale nadal są używane w pewnych sytuacjach. Niektóre z nich to: Crystal Clear, Dynamic Systems Development Method (DSDM), Agile Uniided Process, Future-driven development, ICONIX.

Wartości zwinne:

  • Ludzie i ich interakcje są ważniejszymi procesami i narzędziami;
  • Gotowy produkt jest ważniejszą dokumentacją na jego temat;
  • Współpraca z klientem jest ważniejsza niż ścisłe ograniczenia umowne;
  • Reakcja na zmiany jest ważniejsza niż realizacja planu.

Zasady Agile

  1. Naszym najwyższym priorytetem jest zadowolenie klienta z częstego i ciągłego dostarczania mu cennego produktu.
  2. Akceptujemy zmiany wymagań, nawet na późniejszych etapach realizacji projektu.
  3. Elastyczne procesy witają zmiany, które stanowią przewagę konkurencyjną dla klienta.
  4. Zapewnij w pełni działające oprogramowanie co kilka tygodni, w skrajnym przypadku, co kilka miesięcy. Im częściej, tym lepiej.
  5. Przedstawiciele biznesowi i zespół ds. Rozwoju muszą wspólnie pracować nad projektem.
  6. Udane projekty są motywowane przez ludzi. Daj im odpowiednie środowisko, zapewnij im wszystko, czego potrzebują, i zaufaj im, aby wykonali swoją pracę.
  7. Najbardziej skuteczną metodą interakcji i wymiany informacji jest osobista rozmowa.
  8. Oprogramowanie robocze jest główną miarą postępu projektu.
  9. Elastyczne procesy przyczyniają się do ciągłego rozwoju. Wszyscy uczestnicy projektu muszą być w stanie wytrzymać tak stałe tempo.
  10. Ciągła dbałość o doskonałość techniczną i wysokiej jakości architekturę sprzyja elastyczności.
  11. Prostota jest potrzebna jako sztuka maksymalizacji pracy, której nie należy robić.
  12. Najlepsza architektura, wymagania, projekt powstają w samoorganizujących się zespołach.
  13. Zespół nieustannie poszukuje sposobów na zwiększenie skuteczności poprzez dostosowanie i dostosowanie swoich procesów.

Scrum

Scrum

Organizuj pracę w swojej organizacji w małych zespołowych zespołach, które zawierają wszystkich niezbędnych specjalistów. Wyróżnij osobę - oszusta-kreatora, który będzie odpowiedzialny za utrzymanie procesów w zespole i konstruktywną atmosferę.

Wymagania są podzielone na małe, zorientowane na użytkownika, funkcjonalne części, które są tak niezależne od siebie, co skutkuje zapleczem produktu . Następnie uporządkuj elementy zaległości zgodnie z ich znaczeniem i dokonaj względnej oceny wielkości każdej opowieści. Zaznacz jedną osobę - właściciela produktu (właściciela produktu) , która spełni wymagania i ich priorytety, zamykając się na wszystkich interesariuszy.

We wszystkich pracach umieszczamy krótkie (od 1 do 4 tygodni) ustalone iteracje - sprint , dostarczając na końcu każdego z nich kompletną funkcjonalność, którą można wprowadzić na rynek, jeśli to konieczne, przyrost produktu . Polecenie, zgodnie z jego szybkością, wpisuje zadania dla iteracji niezmienionej w czasie - sprint . Każdego dnia odbywa się wiec scrumowy , na którym zespół synchronizuje swoją pracę i omawia problemy. W tym procesie członkowie zespołu przejmują elementy zabezpieczenia wstecznego zgodnie z priorytetem.

Pod koniec każdego sprintu uruchom demo, aby uzyskać informacje zwrotne od właściciela produktu, oraz retro (retro), aby zoptymalizować procesy. Następnie właściciel produktu może zmienić wymagania i ich priorytety oraz rozpocząć nowy sprint.

Role

  • W Scrumie przyjmuje się trzy podstawowe role: właściciela produktu, mistrza i zespołu.
    Właściciel produktu (właściciel produktu, menedżer produktu) jest osobą odpowiedzialną za ustalanie priorytetów wymagań i często za ich tworzenie.
  • Scrum Master jest członkiem zespołu, który jest dodatkowo odpowiedzialny za procesy, koordynuje pracę zespołu i utrzymuje społeczną atmosferę zespołu.
  • Zespół składa się z 7 ± 2 osób, które spełniają wymagania właściciela produktu.

Artefakty

Backlog produktu (Backlog produktu) - Ustal priorytet listy wymagań dotyczących oceny kosztów pracy. Zazwyczaj składa się z wymagań biznesowych, które przynoszą określoną wartość biznesową i są nazywane elementami użytkownika (historie).

Backlog Sprintu jest częścią baccala produktu, o najwyższym znaczeniu i łącznej punktacji, która nie przekracza prędkości zespołu wybranego do sprintu.

Przyrost produktu to nowa funkcjonalność produktu stworzona podczas sprintu.

Procesy

Większość procesów Scrum ma charakter spotkań, ponieważ ta metodologia opiera się na wysokiej jakości komunikacji.

Rajd Scrumowy

Spotkanie Scrum (spotkanie Scrum, Scrum, Daily Scrum, Planck) to spotkanie członków zespołu (z możliwością zaproszenia właściciela produktu) w celu synchronizacji działań zespołu i informowania o problemach. Każdy członek zespołu odpowiada na trzy pytania:

  1. Co zrobiono z poprzednim scrumem?
  2. Jakie są problemy?
  3. Co zostanie zrobione przed kolejnym etapem rajdu?

Planowanie sprintu

W przypadku planowania sprintu musisz mieć jakościowe backdo, co oznacza:

  • wszystkie elementy bocznej uliczki muszą mieć unikalne znaczenie liczbowe;
  • najważniejsze elementy zabezpieczenia wstecznego muszą być określone i zrozumiane przez cały zespół i właściciela produktu;
  • właściciel produktu musi jasno wyobrazić sobie, co zostanie wdrożone w każdym elemencie zaległości.

Przegląd sprintu

Przegląd sprintu (często używany termin „demonstracja” lub skrót „demo”) - wyświetlanie właściciela produktu (i zainteresowanych stron) funkcji operacyjnej produktu przygotowanego do sprintu. Głównym zadaniem przeglądu sprintu jest uzyskanie opinii.

Retrospektywa

Na dłuższą metę retrospektywna (lub w skrócie „retro”) jest najważniejszą praktyką Scrum: pozwala im dostosować i dostosować Scrum, dzięki czemu jest naprawdę elastyczną strukturą do zarządzania projektami.

Również format zbierania danych jest tradycyjny, który polega na odpowiedzi każdego uczestnika na trzy pytania:

  1. Co zostało zrobione dobrze?
  2. Co można poprawić?
  3. �� Jakie ulepszenia zrobimy (elementy działania)?

Kanban

Aby użyć kanban, wystarczy przestrzegać tylko trzech zasad. Zatem kanban jest najbardziej „niedyrektywną metodologią”. Może to być plus lub minus, więc zainstaluj i używaj kanban po Scrumie, a nawet lepiej nie porzucaj przydatnych praktyk tej elastycznej struktury.

Tak więc kanban jest wysoce adaptacyjnym narzędziem, które wymaga zespołu, który zdecydował się go użyć, odpowiedniego poziomu samoorganizacji i dyscypliny:

  1. Wizualizuj proces produkcji - w tym celu zazwyczaj korzystaj z tablicy zaznaczonej podczas etapów pracy. Oczywiście bardziej zaawansowaną opcją będzie użycie plazmy / projektora i wyświetlenie tam statusu trackera.
  2. Ogranicz ilość pracy w toku (WIP, Work In Progress) - dla każdego stanu kolumny polecenie określa maksymalną liczbę zadań, które mogą się w nim znajdować. W ten sposób minimalizuje się przełączanie między zadaniami i związane z tym straty w produkcji.
  3. Zoptymalizuj proces - podstawa optymalizacji produkcji w kanban. Konieczne jest monitorowanie średniego czasu zadania i jego zmniejszenie.

XP (ekstremalne programowanie)

Praktyki inżynieryjne to sprawdzone decyzje, które są bezpośrednio związane z realizacją wymagań klienta.

Podstawowe praktyki:

  • Ciągła integracja (Continuous Integration) to wykorzystanie specjalnego oprogramowania, które otrzymuje nową wersję kodu źródłowego projektu i wykonuje budowę oprogramowania. W przypadku problemów, odpowiedni komunikat zostanie wyświetlony i wysłany. Montaż projektu wiąże się z koniecznością uruchomienia automatycznych testów.
  • Test Driven Development (Test Driven Development) - Najpierw piszemy automatyczne testy, a następnie funkcjonalność, która zapewnia przejście tych testów. O TDD Już napisałem dużo i możesz przeczytać artykuł Test jednostkowy - początek. Część 1
  • Programowanie par (programowanie parami) - kod jest napisany przez dwóch programistów na jednym komputerze, przy czym jeden z programistów odgrywa rolę „pilota”, a druga rola to „nawigator”. Zasadniczo podnosi to jakość kodu.
  • Wspólne posiadanie kodu - zapewnia funkcjonalność wszystkich członków zespołu i pozwala na realizację tej ważnej właściwości Scrum. Ważną zaletą tego podejścia jest szybkie rozpowszechnianie wiedzy wśród członków zespołu. Aby wdrożyć tę praktykę, musisz użyć standardy kodowania aby kod napisany przez różnych członków zespołu był taki sam pod względem projektu. Sprawdzanie zgodności ze standardami najlepiej przeprowadzać na etapie budowy projektu w trybie automatycznym. Ponadto procedura przeglądu kodu pomaga osiągnąć tę praktykę XP.
  • Standard kodowania lub konwencje kodowania to zestaw reguł pisania kodu. Każdy programista w zespole musi ich przestrzegać.
  • 40-godzinny tydzień pracy (Zrównoważone tempo, Czterdzieści godzin tygodniowo) jest gwarancją dla zespołu przeciążeń, jednego z rodzajów strat w produkcji ekonomicznej. Należy bardzo wyraźnie zrozumieć, że liczba przepracowanych godzin nie jest równa ilości funkcji funkcjonalnej, jak w każdej działalności intelektualnej i inżynierskiej.
  • Refaktoryzacja (Design Improvement, Refactor) to zmiana kodu źródłowego bez zmiany funkcjonalności w celu poprawy jakości wewnętrznej (łatwość kodu, elastyczność architektury itd.). Polecam czytanie Czym jest „Pure Code”?

W XP istnieje kilka innych ważnych praktyk, które są powszechnie stosowane w Agile / Scrum: gra planistyczna, pełny zespół, klient na miejscu, częste małe wydania, prosta konstrukcja, Metafora systemu (metafora systemu).

Wikipedia ma dobrze udokumentowane dane praktyczne - Ekstremalne programowanie .

Więcej teorii Agile można zobaczyć w prezentacji Borisa Wolfsona.

Polecam też czytanie „Elastyczne metodologie rozwoju” Wolfson Boris

Jeśli znajdziesz błąd, wybierz fragment tekstu i naciśnij Ctrl + Enter .

Jakie są problemy?
Co zostanie zrobione przed kolejnym etapem rajdu?
Co można poprawić?
?� Jakie ulepszenia zrobimy (elementy działania)?