Twój kompleksowy przewodnik po zwinnym tworzeniu oprogramowania

Zwinna metodyka tworzenia oprogramowania to elastyczne podejście do procesu wytwarzania oprogramowania. Zwinne firmy tworzące oprogramowanie wykorzystują interaktywne metody dostarczania produktów oprogramowania w częściach (ciągłe wydania MVP), z uwzględnieniem opinii interesariuszy.

Jest to elastyczna metodologia, która pomaga zespołom technicznym dostarczać wysokiej jakości usługi tworzenia oprogramowania szybciej i przy minimalnych komplikacjach.

Pierwsza filozofia tworzenia oprogramowania Agile była popularna wśród małych i samokontrolujących się zespołów. Ostatecznie rozwój oprogramowania Agile przejął branżę programistyczną ze względu na łatwość, produktywność i skuteczność.

W Agile zespół programistów dostarcza projekt za pomocą iteracji. W przeciwieństwie do metodologii Waterfall, która podąża określoną ścieżką i są od niej minimalne odchylenia, Agile wyróżnia się szybkością i zdolnościami adaptacyjnymi. Członkowie zespołu i interesariusze mogą swobodnie wprowadzać zmiany podczas iteracji.

W dzisiejszej szybko rozwijającej się i konkurencyjnej gospodarce, elastyczne i regulowane iteracje Agile są idealne.

Ten artykuł jest skompresowaną wersją przewodnika CodeRiders po programowaniu Agile. W CodeRiders stworzyliśmy kompletny praktyczny przewodnik po tworzeniu oprogramowania Agile. Na koniec znajdziesz również 6 najczęściej zadawanych pytań, które należy zadać firmom zajmującym się tworzeniem oprogramowania Agile. Odpowiedzi pozwolą określić, czy Twój przyszły dostawca oprogramowania jest odpowiedni dla Twojego projektu. Gdy przewodnik będzie dostępny, wstawimy poniższy link do pobrania.

Kontynuuj czytanie tego artykułu, jeśli potrzebujesz szybkiego wprowadzenia.

Zasady, wzorce i praktyki zwinnego tworzenia oprogramowania

4 wartości zwinne

W 2001 roku grupa menedżerów oprogramowania i interesariuszy zebrała się, aby zastanowić się, jak ulepszyć SDLC. Na tym spotkaniu stworzyli 4 wartości i 12 zasad Agile.

Oto słynne w historii 4 wartości Agile:

1. Osoby i interakcje nad procesami i narzędziami:

Wartość ta podkreśla relacje członków zespołu nad procesami lub narzędziami używanymi przez dostawcę oprogramowania i interesariuszy. Na przykład w zespole mamy 2 programistów, którzy muszą wchodzić w interakcje lub udostępniać informacje, aby ukończyć i dostarczyć określone rozwiązanie programowe. W Agile nie obchodzi nas, jakich technologii, narzędzi lub metod używają twórcy oprogramowania do udanej interakcji. Zależy nam na prostym przekazywaniu informacji od jednego członka zespołu do drugiego.

Jak być może już zauważyłeś, 4 wartości Agile faworyzują jedną zaletę nad drugą. To może czasami przypominać nam porównanie Agile vs Waterfall.

2. Działające oprogramowanie nad obszerną dokumentacją:

W sekwencyjnych cyklach życia outsourcingu oprogramowania, takich jak Waterfall, przechodzimy przez wiele dokumentacji przed rozpoczęciem partnerstwa outsourcingu oprogramowania. Niektóre z tych dokumentów obejmują SRS lub dokument wymagań użytkownika, diagramy sekwencji, diagramy UML itp. W Agile najważniejsze jest działające oprogramowanie zamiast obszernej dokumentacji.

Na przykład w Agile nie musisz dokumentować wszystkich wymagań dotyczących funkcjonalności logowania przed rozpoczęciem faktycznego procesu rozwoju. Firmy programistyczne Agile będą kładły nacisk na posiadanie działającej i wolnej od błędów funkcji logowania w oprogramowaniu niestandardowym. Oczywiście nie oznacza to, że nie będziemy mieć żadnej dokumentacji. Ideą tego podejścia jest nadanie priorytetu rzeczywistej funkcjonalności, a nie dokumentacji.

Aby pomóc naszym klientom przejrzeć przykładowy dokument SOW, w CodeRiders stworzyliśmy prosty przewodnik po pisaniu szczerego dokumentu SOW z prawdziwą próbką. Już teraz możesz pobrać przewodnik dotyczący pisania dokumentu SOW z prawdziwą próbką.

3. Współpraca z klientem przy negocjacjach umowy:

W modelu zaangażowania w rozwój oprogramowania o stałej cenie (sekwencyjne procesy tworzenia oprogramowania) obie strony przed rozpoczęciem partnerstwa outsourcingowego podpisują umowę z przejrzystą dokumentacją techniczną. Oznacza to, że jeśli interesariusz nie może dokonać zmian po rozpoczęciu procesu outsourcingu oprogramowania. W Agile klient może podejść do połowy projektu i poprosić o pewne poprawki. Firma tworząca oprogramowanie Agile zaakceptuje prośbę i nawiąże pewien rodzaj współpracy z interesariuszem. Nie oznacza to, że zespół programistów zbuduje wszystko od nowa, ale będzie współpracować z interesariuszami, aby zbudować produkt o najwyższej możliwej jakości, odpowiadający wymaganiom klientów.

4. Reagowanie na zmiany zgodnie z planem:

W każdym projekcie outsourcingu oprogramowania mamy plan, co jest ważne, ponieważ jest to podstawa projektu. W sekwencyjnych modelach tworzenia oprogramowania, takich jak Waterfall, twórcy oprogramowania i inni członkowie zespołu technicznego są kierowani przez zespół zarządzający, aby „trzymali się planu”, ale w Agile jest odwrotnie. Plan jest kluczowy, aby stworzyć wizję przyszłego oprogramowania niestandardowego. Jeśli jednak okoliczności ulegną zmianie podczas SDLC i zmiana planu jest bardziej korzystna, zespoły zwinne reagują na zmiany.

Na przykład zespół zarządzający wybiera jedno z popularnych narzędzi wykorzystywanych w tworzeniu oprogramowania Agile, np. Jira, Trello i Asana, ale po chwili zdają sobie sprawę, że narzędzie nie jest tak skuteczne, jak im się wydawało. Ponieważ metodologia tworzenia oprogramowania Agile ceni sobie przejrzyste SDLC, jakość oprogramowania i elastyczną komunikację, zespół nie zawaha się zmienić nieefektywnego narzędzia.

Podsumowując, Manifest Agile twierdzi, że jeśli istnieje sprzeczność między planem a zmianą, zespoły Agile reagują na zmianę.

Główna różnica między modelami Agile a Waterfall lub dowolnymi modelami rozwoju sekwencyjnego

Cykl życia oprogramowania: Waterfall vs Agile

W projektach Wodospad mamy:

• Stałe wymagania
• Przejrzysta dokumentacja techniczna
• Szacowany czas i zasoby

W projektach Agile odwracamy wartości.

Nie mamy ustalonych wymagań, zamiast tego mamy stałe zasoby i czas.

Planowanie projektów w firmach tworzących oprogramowanie Agile

1. Wizja produktu: zespół jasno określa cel swojego niestandardowego oprogramowania. Jaki problem rozwiązuje to oprogramowanie? Czym różni się od innych podobnych rozwiązań programowych? Wizja produktu jest tworzona przez właściciela produktu i powinna być weryfikowana przynajmniej raz w roku, jeśli mówimy o dużych i stabilnych przedsiębiorstwach.
2. Mapa drogowa produktu: Mapa drogowa produktu, podobnie jak wizja produktu, jest rodzajem planowania na wysokim poziomie. Jest to wysokopoziomowy przegląd wymagań produktu, który tworzy wizję produktu. Mapa drogowa produktu powinna być aktualizowana i weryfikowana co najmniej dwa razy w roku.
3. Planowanie wydania: Planowanie wydania jest również zawarte w planowaniu produktu wysokiego poziomu, jednak jest bardziej szczegółowe niż wizja produktu i mapa drogowa produktu. Właściciel produktu wykonuje planowanie wydania, wymieniając kolejność wydania i typ przyrostów produktu (wersje), które powinny zostać wydane na rynek. Planowanie wydania powinno odbywać się co najmniej raz na kwartał.
4. Planowanie sprintu: W Scrumie planowanie sprintu to wspólne działanie członków zespołu Scrum, w tym właściciela produktu. Zespół Scrum tworzy cele, zadania i rezultaty iteracji i powtarza proces co 1 do 4 tygodni.
5. Codzienny Scrum: W zespołach Agile członkowie zespołu odbywają codzienne spotkania stand-up omawiające bieżące zadania, które pomogą w osiągnięciu celu iteracji.

Pod koniec każdej iteracji lub sprintu projekty Agile mają 2 formy planowania:

• Przegląd sprintu: Przegląd sprintu obejmuje demonstrację stworzonego produktu i jest wykonywany przez właściciela produktu i zespół programistów na koniec każdego sprintu.
• Retrospektywa sprintu: Spotkanie retrospektywne sprintu jest organizowane w celu pomiaru postępów zespołu. Podczas retrospektyw sprintów członkowie zespołu Agile omawiają procesy i środowiska oraz opracowują plany usprawnień procesów w kolejnym sprincie.

Uwaga: Nie wszystkie zespoły Agile wykonują wszystkie te kroki planowania projektu, ponieważ w dużym stopniu zależy to od charakterystycznych cech konkretnego projektu rozwoju oprogramowania. Najpopularniejsze plany obejmują planowanie sprintu, retrospektywy, przegląd sprintu i codzienny Scrum. Startupy lub małe zespoły również nie mają wizji produktu ani mapy drogowej, jednak wskazane jest, aby mieć je wcześniej.

Jak powstaje dokumentacja wymagań technicznych w metodyce Agile?

Wymagania użytkownika w Agile są napisane w formie zwanej „historią użytkownika”.

Historyjki użytkownika są pisane w celu uchwycenia wymagań z perspektywy programistów, testerów (specjalistów QA) i przedstawicieli biznesu. Historyjki użytkownika muszą dotyczyć zarówno cech funkcjonalnych, jak i niefunkcjonalnych.

Zwinne metodologie

Istnieją 3 najczęściej używane i popularne metodyki tworzenia oprogramowania Agile. To są:

Scrum

Czym jest metodologia Agile Scrum? Sukces w tworzeniu oprogramowania Agile przy użyciu Scrum.

Scrum to framework do zarządzania projektami Agile, który pomaga zespołom współpracować wydajnie. Scrum opisuje zestaw spotkań, narzędzi i ról, które współpracują ze sobą, aby pomóc zespołom w organizacji pracy i zarządzaniu nią. W metodologii Scrum Agile najczęściej używanym narzędziem jest JIRA Atlassian.

Co to jest narzędzie Scrum Jira? Jira dla firm tworzących oprogramowanie Agile.

Oprogramowanie Jira jest częścią rodziny produktów zaprojektowanych przez korporację Atlassian, aby pomóc zespołom różnej wielkości i typu w zarządzaniu i organizacji pracy. Jira została stworzona jako narzędzie do śledzenia błędów, ale ostatecznie została rozszerzona w potężne narzędzie do zarządzania pracą do różnych celów w SDLC, od zarządzania wymaganiami i przypadkami testowymi po zwinne tworzenie oprogramowania.

Kanban

Czym jest metodologia Agile Kanban? Sukces w rozwoju oprogramowania Agile przy użyciu Kanban.

Kanban to podejście do zarządzania, które jest czasami stosowane w projektach zwinnych. Ogólnym celem Kanban jest wizualizacja i optymalizacja przepływu pracy w łańcuchu wartości dodanej.

Kanban nie jest tradycyjnym podejściem Agile, takim jak Scrum. Zamiast tego jest używany ogólnie w zarządzaniu pracą i zadaniami. W metodologii Kanban najpopularniejszym narzędziem jest Trello.

Co to jest narzędzie Trello Kanban? Trello dla firm tworzących oprogramowanie Agile

Trello jest produktem Atlassian, takim jak Jira. Tak więc, jeśli jesteś już zarejestrowany w Jira, możesz użyć tych samych poświadczeń, aby zarejestrować się w Trello. W przeciwieństwie do Jiry, która jest oparta na Scrumie, Trello opiera się na Kanbanie. Można ją uznać za tablicę Kanban. Trello składa się z oddzielnych tablic. Trello udostępnia szablony do zarządzania projektami Agile, zarządzania produktami i zarządzania zespołem. Zespoły programistyczne Agile używają dowolnego dostępnego szablonu Agile do pracy z zasadami Agile i zarządzania projektami programistycznymi według iteracji/sprintów.

Programowanie ekstremalne (XP)

XP to metodologia Agile, która jest popularna w zespołach programistycznych od lat 90. XX wieku. XP skupia się nie tylko na zarządzaniu projektami (jak Scrum), ale także na budowaniu kodu. Jeśli Scrum koncentruje się na zarządzaniu pracą, identyfikuje określone role w projekcie i dzieli projekt na iteracje, XP koncentruje się również na tworzeniu i testowaniu oprogramowania (nie na zarządzaniu outsourcingiem rozwoju oprogramowania).

Oto najważniejsze definicje w XP:

Cykl kwartalny: Raz na kwartał zespół XP organizuje spotkania w celu planowania i refleksji.

Cykl tygodniowy: Praktyka w cyklu tygodniowym to tygodniowa iteracja, w której zespół wybiera historie i buduje działające oprogramowanie, które jest „gotowe” na koniec tygodnia.

Zarówno cykle kwartalne, jak i tygodniowe są obecnie rzadko wykorzystywane w projektach Agile. Większość zespołów Agile stosuje obecnie Scrum w zakresie zarządzania projektami: wydanie – rejestr produktu – planowanie sprintu – rejestr sprintu.

Slack: Za każdym razem, gdy zespół tworzy plan, zespół dodaje luz, dodając niewielką liczbę opcjonalnych lub pomniejszych elementów.

Podsumowując, Manifest Agile jest obecnie szeroko rozpowszechnionym modelem zaangażowania w tworzenie oprogramowania. Znajduje zastosowanie zarówno podczas outsourcingu rozwoju oprogramowania, jak i wewnętrznych procesów wytwarzania oprogramowania. Manifest Agile jest idealny do elastycznego cyklu życia oprogramowania, w którym zmiana jest preferowana w stosunku do ustalonego planu, osoby i interakcje są ważniejsze niż procesy i narzędzia, a działające na zamówienie oprogramowanie jest celem, a nie kompleksowa dokumentacja rozwoju oprogramowania.