Czy zwinność to coś więcej niż małe wodospady?

W swoich projektach najczęściej stosowałem metodologię wodospadu, ale teraz poszerzam swoje horyzonty o metodyki zwinne. Z tego, co przeczytałem do tej pory i być może czytałem złe rzeczy, zwinny oznacza małe wodospady. Zamiast dużego wodospadu rozłożonego na rok lub dwa lata, masz małe wodospady, które trwają tygodnie, a może nawet kilka miesięcy.

Czy moje rozumowanie jest prawidłowe, czy jest w tym coś więcej? Jakie są zwinne filozofie?

Na prostym poziomie tak. Zwykłe wykonywanie Wodospadu co dwa tygodnie nie czyni cię zwinnym , ale jest iteracyjny (co stanowi połowę zwinności).

Model kaskadowy określa fazy - wymagania, architekturę, projekt, implementację, weryfikację (testowanie), walidację (testowanie akceptacyjne) i wydanie. W dowolnej metodologii iteracyjnej przechodzisz przez każdą z tych faz w ramach każdej iteracji. Mogą się one nakładać, ale wywołujesz i wychwytujesz wymagania, dostosowujesz architekturę i projekt systemu, aby umożliwić wdrożenie, rozwijasz nowe funkcje lub naprawiasz defekty, testujesz nowe moduły, a następnie przekazujesz klientowi do akceptacji testowanie i wdrażanie.

Jednak zwinność wymaga znacznie więcej niż tylko iteracji i przyrostu. Najemcy agile zostali schwytani w Manifeście Agile Software Development . W Manifeście wyróżniono cztery kluczowe punkty:

Osoby i interakcje dotyczące procesów i narzędzi

Często angażujesz pojedyncze osoby. Wiele wdrożeń koncentruje się wokół zespołów samoorganizujących się i samokierujących. Prawie wszyscy mają częste interakcje z klientem lub kimś, kto ma głos klienta. Zamiast formalnego zestawu procedur do naśladowania i narzędzi do użycia, pozwalasz osobom pracującym nad projektem określać sposób realizacji projektu, aby mógł on zostać wykonany w najlepszy możliwy sposób.

Działające oprogramowanie w obszernej dokumentacji

W projekcie oprogramowania głównym celem jest dostawa oprogramowania. Jednak w niektórych projektach powstaje marnotrawstwo dokumentów, które nie wnoszą żadnej wartości. Scott Ambler napisał dobry artykuł na temat dokumentacji Agile / Lean . Nie chodzi o nie tworzenie dokumentacji, ale o wybór dokumentacji, która dodaje wartości zespołowi, przyszłym programistom, klientowi lub użytkownikowi. Zamiast tworzyć dokumentację, która nie dodaje wartości, inżynierowie oprogramowania zamiast tego tworzą oprogramowanie i powiązane testy.

Współpraca z klientami w zakresie negocjacji umów

Zamiast z góry określać warunki, harmonogramy i koszty, staje się to ciągłym wysiłkiem z klientem. Na przykład możesz uchwycić swoje wymagania w formie historii użytkowników i przypisać im punkty. Po kilku iteracjach ustalasz prędkość (punkty / iteracja) i możesz określić, ile funkcji Twój zespół może wdrożyć w iteracji. Ponieważ klient przekazuje informacje zwrotne na temat tego, które funkcje stanowią największą wartość, w dowolnym momencie może zdecydować, kiedy projekt zostanie ukończony. Przy częstej dostawie i interakcji z klientem może się zdarzyć wiele rzeczy - wymagania zostały spełnione, a projekt kończy się utrzymaniem, a ostatecznie wycofaniem z eksploatacji, klient dowiaduje się, że nie potrzebuje wszystkiego, o czym myśli, więc postanawia zakończyć projekt, projekt kończy się niepowodzeniem, a klient widzi to wcześnie i może go anulować ...

Reagowanie na zmianę po wykonaniu planu

Nie masz dużego projektu ani ostatecznego planu i musisz wykonać przeróbkę, ilekroć ten projekt lub plan musi się zmienić. Ciągle szacujesz i weryfikujesz prognozy na podstawie posiadanych informacji. Ostrożnie wybierasz swoje dane, aby uzyskać wgląd w kondycję projektu i kiedy wprowadzić zmiany wewnętrzne. Często dodajesz, usuwasz i zmieniasz priorytety wymagań wobec klienta. W końcu rozumiesz, że zmiana jest jedyną stałą.

Zwinność oznacza koncentrowanie się na ludziach i zaspokajanie ich potrzeb poprzez szybkie dostarczanie wysokiej jakości oprogramowania o wartości dodanej. Gdy zmieniają się potrzeby klienta, dostosowujesz się do tych potrzeb, aby skupić się na zwiększaniu wartości. Istnieją konkretne wdrożenia zwinnych metodologii, ale wszystkie koncentrują się na ludziach, terminowym dostarczaniu działającego oprogramowania i dostosowywaniu się do szybko zmieniającego się środowiska.

Tak i nie - rzeczywisty proces może być postrzegany jako seria małych wodospadów, ale różnica polega na tym, że proces ewoluuje i jest ulepszany na podstawie wkładu całego zespołu (deweloperów, qa, firm itp.), W retrospekcjach, które powinny prowadzić do znacznie ciaśniejszej jednostki, która jest w stanie reagować na problemy i dokładnie planować i dostarczać. Rażąco upraszczam to tutaj, jest o wiele więcej, ale nie sądzę, że to zły punkt wyjścia.

Powiedziałbym, że jest to uproszczony sposób. Tak, kiedy się do tego zabierasz, są to małe przepływy wody, ale kryje się za tym o wiele więcej, co sprawia, że ​​działa. Cała metodologia, która zmienia sposób podejścia do projektów ... Nie wspominając o mentalności potrzebnej do tego.

Jeśli poważnie myślisz o Agile, oto dobra (i długa) seria webcastów, które mogą Cię zainteresować:

http://autumnofagile.net/

Zapomnij na chwilę Agile, zastanów się, co należy rozumieć przez „wodospad”.

Istnieje faza wymagań, w której każdy próbuje dowiedzieć się, JAKIE problemy musi rozwiązać produkt końcowy. Ludzie kłócą się o to przez chwilę, a potem podpisują się zgodnie z szeregiem wymagań. W tym momencie Twój zakres jest zdefiniowany, umowy są podpisywane, a klient może odejść i poczekać, aż pojawi się produkt, który spełni te zdefiniowane wymagania.

Następnie jest jedna (a może dwie) fazy projektowania. Projektanci (którzy mogą, ale nie muszą być programistami), spierają się o to, JAK system musi iść w parze, aby spełnić podpisane wymagania. Problemy mogą wystąpić, jeśli nie do końca rozumieją wymagania, co może oznaczać, że muszą wrócić do klienta, potencjalnie ponownie otworzyć fazę wymagań (i uzyskać kolejną rundę podpisania się) lub przynajmniej uruchomić zarządzanie zmianami w działaniu . Często projektanci po prostu starają się zgadnąć. Mogą wymyślić logiczny model danych i mnóstwo UML-a opisującego nowy system i sposób jego działania. Następnie podpisują się.

Teraz programiści mogą zacząć kodować na podstawie podpisanego projektu. Problemy mogą wystąpić, jeśli nie do końca rozumieją projekt, co może oznaczać, że muszą wrócić do projektanta, potencjalnie ponownie otworzyć fazę projektu (i uzyskać kolejną rundę podpisów) lub przynajmniej uruchomić zarządzanie zmianami w działaniu . Projektanci mogą z kolei zdać sobie sprawę z tego, że zamieszanie naprawdę wraca do wymagań, co oznacza, że ​​muszą ponownie otworzyć dyskusje na temat wymagań, podpisania się i dalszego zarządzania zmianami. Często programiści (mający zbliżający się termin) po prostu zgadują. Robią, co mogą, aby stworzyć funkcjonalny kod. Następnie udostępniają go do testowania.

Teraz rozpoczyna się faza testowania systemu. Testerzy testują na podstawie ich zrozumienia wymagań i projektu oraz rejestrują to, co postrzegają jako wady, w systemie śledzenia błędów / zarządzania zmianami, co powoduje, że programiści zaczynają programować od nowa, chyba że widzą problem jako wada projektowa, która odsyła ją z powrotem do projektu itp. W końcu testy systemowe przechodzą pomyślnie i zostają podpisane.

Wreszcie klient wraca i przeprowadza testy akceptacji użytkownika w nowym systemie. Tutaj decydują, czy rozwiązanie, które testowali testerzy, opracowali programiści, a projektanci zaprojektowali, jest tym, czego chcą. Jeśli tak nie jest, potencjalnie musisz wrócić do fazy projektowania lub nawet ponownie sprawdzić wymagania.

Idea stojąca za wodospadem polega na tym, że trudno jest (i bardzo niepożądane) cofnąć się po zakończeniu fazy. Różne osoby są zwykle zaangażowane w różne fazy, więc istnieje wiele przekazań - z których każda wiąże się z dużym ryzykiem błędnej interpretacji i utraty informacji. Istnieje również znaczna luka między momentem, w którym klienci mówią, co chcą, a momentem, w którym zobaczą, co zostało zbudowane, a kiedy rzeczywiste wymagania mogą się bardzo zmienić.

Metodyki zwinne koncentrują się na silnej komunikacji i współpracy między wszystkimi zainteresowanymi stronami. Zasada „Współpraca z klientem podczas negocjacji umowy” oznacza, że ​​nie powinieneś przechodzić przez szereg podpisów i przekazów, ale zamiast tego powinieneś po prostu współpracować z klientem, a każda iteracja określa wymagania dla danego elementu układanki i natychmiastowe tworzenie testów, projektu i działającego kodu - przy czym wszyscy gracze komunikują się tak bezpośrednio, jak to możliwe (eliminując koszty i ryzyko związane z przekazaniem). Działający kod jest szybko testowany przez klienta, co eliminuje ryzyko opóźnienia czasowego. Wszystkie działania odbywają się we współpracy, a nie w dół.

Aby uzyskać doskonały przegląd metodologii zwinnych, gorąco polecam program Agile Software Development: The Cooperative Game firmy Allistair Cockburn .

Tak, to mniej więcej poprawne. Wiele napisano i dyskutowano o tym, jak to zrobić, ale sedno tego stanowi kilka małych wodospadów.

Konkretna implementacja sposobu korzystania z kilku małych wodospadów nie jest jednak trywialna. Na przykład nie zamierzasz przechodzić od robienia dużych projektów za kilka lat do robienia wielu małych projektów. Nadal jest duży projekt, na który trzeba włożyć 1-2 lata pracy. Musisz więc podzielić duży projekt na kilka małych projektów. To może wydawać się dość oczywiste, ale wypełnia strony i strony książek.

Czy to prawda, czy jest w tym coś więcej

Obie. Tak, to dokładne podsumowanie koncepcji, ale podsumowuje się wiele szczegółów. Mam na myśli prawie każdy aspekt planowania zmian, kiedy planujesz tylko na następny tydzień zamiast na następny rok.

Jeśli spojrzysz na strukturę statyczną (definicję procesu) zwinnego projektu, wygląda na to, że wiele małych wodospadów tak. Ale celem zwinnego projektu jest uzyskanie szybszej i lepszej informacji zwrotnej .

• Tworzysz programowanie testowe, aby od razu wiedzieć, czy twoje oprogramowanie nadal działa
• Klient jest na miejscu i przeprowadza testy akceptacyjne, aby wiedzieć, kiedy skończysz
• Masz retrospektywy, aby dostosować swój proces na podstawie tego, co poszło dobrze, a co nie.

W Manifeście Agile podkreśla pewne różnice między zwinny i wodospadu (jak postrzegane przez tych, którzy podpisali).

Naprawdę „zwinny” często oznacza wodospady trwające 1-2 dni, a nie tygodnie. Nie oznacza to, że nie przestrzegasz ogólnego planu, a faktyczne cykle wydawania wynoszą 1-2 dni. Ale powinieneś próbować mieć działający, przetestowany produkt każdego dnia i możesz wypuszczać go - teoretycznie - każdego dnia.

Scrum, na przykład, używa sprintu trwającego 4 tygodnie, ale sprint to nie tylko jeden wodospad (przynajmniej tak nie powinno być). Możesz zmieniać priorytety każdego dnia, gdy tylko zobaczysz, że coś nie idzie zgodnie z planem na początku sprintu.