Co dostarczasz w pierwszych kilku iteracjach w Agile?

Jak rozumiem, w metodologii Agile chodzi o to, że dostarczasz coś funkcjonalnego i często. Aplikacja osiąga ostateczny przyrost kształtu po zwiększeniu.

Ale we wczesnych wersjach możesz zbudować platformę lub fundamenty, na których będzie się opierać aplikacja, więc jest to coś ważnego, ale niewidocznego dla użytkowników.

Co zostaje dostarczone klientowi w tych pierwszych iteracjach? Jak pokazać postęp we właściwym kierunku podczas tworzenia kodu rusztowania?

Typowe są dwutygodniowe sprinty.

Dla mnie pierwszy sprint lub 2 będą prawdopodobnie miały mniej „widocznych” cech niż późniejsze sprinty z tego właśnie powodu (dla pewnego wątłego opisu „mniej”).

To powiedziawszy, z pewnością nie powinno ci zająć 2 tygodni, aby zbudować całe rusztowanie i nie mieć nic widocznego w interfejsie użytkownika.

Może nie wyodrębnisz każdego elementu rusztowania podczas pierwszego sprintu lub 2. Może części mogą poczekać i zostaną dodane później.

Może twój pierwszy sprint ma „Utwórz stronę X z fałszywymi danymi”, abyś mógł uzyskać coś błyszczącego, aby pokazać swojemu klientowi. A następnie następny sprint ma „Zmień stronę X, aby użyć danych z bazy danych”.

Manifest Agile sugeruje, że Oprogramowanie Robocze jest cenniejsze niż obszerna dokumentacja, a środowisko Scrum przyjmuje to pojęcie, sugerując, że dostarczanie sprawdzonego, działającego oprogramowania o wartości biznesowej jest wymogiem przy każdym sprincie.

Czemu? Cóż, między innymi projektanci i programiści często padają ofiarą spędzania dużo czasu na przedmiotach YNNI (nigdy nie będzie to potrzebne). Niestety, ramy, o których mówisz, często stanowią dużą odpowiedzialność w tym obszarze. Deweloperzy zaczynają budować wszystkie elementy, które MUSI obsługiwać, i nagle masz 3 miesiące i nie masz nic wartego swojej wartości biznesowej. Potem okazuje się, że framework nawet nie obsługuje tego, czego w końcu potrzebują.

Sugerowane podejście polega więc na zbudowaniu tylko tego, co jest obecnie potrzebne, i dostarczeniu go teraz.

Nie oznacza to, że nie możesz budować części wielokrotnego użytku i tym podobne, po prostu zawsze robisz to w celu wsparcia bieżącej potrzeby. Co więcej, nie oznacza to, że musisz całkowicie założyć rolety na to, co nadchodzi na drodze - nie buduj rzeczy, aby później nie można było ich zmienić / ulepszyć. Ale kluczem jest zawsze dostarczanie wartości biznesowej.

Często są pewne kluczowe rzeczy, które absolutnie muszą zostać ustalone przed dostarczeniem czegokolwiek, takie jak konfigurowanie środowisk i tym podobne. W przypadku tych rzeczy wiele zespołów uważa, że ​​przydatne jest „Sprint 0”, w którym kładziony jest fundament. Sprint 0 może być nieco dłuższy niż inne sprinty, ponieważ nie jest stosowany do zaległości lub wypalenia produktu, ale nadal powinien być ograniczony czasowo do rozsądnego czasu.

Co zostaje dostarczone klientowi w tych pierwszych iteracjach?

Co ma najwyższą wartość biznesową dla użytkownika. Na przykład, jeśli aplikacje mają złożone reguły biznesowe, pierwsze iteracje będą zawierały tylko te reguły biznesowe zakodowane w formie kodu. Klient powinien być usatysfakcjonowany, o ile masz kod dla tych reguł biznesowych. (Problem z przekonaniem klienta do zaakceptowania takiej rzeczy jest zupełnie inną sprawą.) Na przykład możesz pokazać ekspertom biznesowym klienta swoje testy jednostkowe / akceptacyjne, które wyrażają, co powinna zrobić domena, a ten kod przekazuje go z zielonym wynikiem. Lub jeszcze lepiej, spraw, aby eksperci biznesowi pomogli w stworzeniu tych testów.

Jest także kwestia

możesz zbudować ramy lub fundamenty

Które moim zdaniem jest znacznie ważniejsze niż to, co faktycznie zostało dostarczone. Projekt ewolucyjny ma dużą zaletę , mówiąc, że należy tworzyć architekturę z czasem, zamiast próbować ją tworzyć na początku. Jeśli chodzi o podstawy, zwykle oznacza to pewien rodzaj bazy danych lub interfejsu użytkownika. W takim przypadku pojawia się pomysł: „ Dobra architektura to taka, która pozwala odłożyć ważne decyzje ”. Wybór bazy danych lub interfejsu użytkownika jest ważną decyzją. Na przykład, może być w porządku po prostu przechowywanie danych w pamięci zamiast próbowania użycia DB od pierwszej iteracji.

Staramy się dostarczać w pierwszych iteracjach najprostszą możliwą aplikację (wersja hello-world tego, co dostarczamy). Widzimy w tym 3 ważne korzyści:

• Skonfiguruj procedurę dostawy (zawsze jedną z najtrudniejszych części imho) (uruchom środowiska, serwery, zaktualizuj zabezpieczenia tego środowiska). Ponieważ często dostarczamy, ważne jest, aby jak najszybciej to zrobić.
• Daj użytkownikom pierwsze spojrzenie, jak będzie wyglądać aplikacja. Pomaga to użytkownikom i programistom zrozumieć, czego naprawdę chcą i potrzebują.
• Mieć podstawowe pojęcie o tym, jak będzie wyglądać architektura aplikacji (aplikacja powinna obejmować podstawowe „warstwy” lub komponenty aplikacji).

Ale we wczesnych wersjach możesz zbudować platformę lub fundamenty, na których będzie się opierać aplikacja, więc jest to coś ważnego, ale niewidocznego dla użytkowników.

To źle, ponieważ nie musisz budować frameworka, którego możesz użyć w przyszłości. Chodzi o to, aby budować tylko to, co jest potrzebne (patrz także YAGNI ).

W zerowym sprincie musisz przygotować się do prawdziwej pracy. Wiele osób spiera się o to, co należy zrobić w tym sprincie, ale moim zdaniem jest to zakończone, kiedy możesz zacząć pracę nad elementami w zaległościach. Ten krok obejmuje konfigurowanie komputerów, proces kompilacji, wybieranie ram itp.

Po zakończeniu zerowania sprintu (lub iteracji zero) możesz rozpocząć pracę z aplikacją. Weź przedmioty z zaległości i dokończ je jeden po drugim. Po zakończeniu pierwszej iteracji będziesz mieć coś pożytecznego. Pierwsza iteracja zazwyczaj zawiera niektóre z najważniejszych funkcji.

Co zostaje dostarczone klientowi w tych pierwszych iteracjach? Jak pokazać postęp we właściwym kierunku podczas tworzenia kodu rusztowania?

Po iteracji zero oczywiście nie masz nic do dostarczenia. Produkt dostarczany jest po pierwszej. Zawiera funkcje ustawione dla iteracji.

Jeśli masz pytanie „jak wybrać, co wchodzi w iterację X?”, Zapoznaj się z tymi wideokastami (filmy z iteracją 0 A i częścią B).

Możesz dostarczyć prawie wszystko, co chcesz. Budowanie idei infrastruktury jest po prostu złe / niestabilne / niezrównoważone.

Na przykład: zbudowanie w pełni funkcjonalnej aplikacji Hello World można zbudować w kilka godzin. Uruchamianie serwera (nawet tymczasowo) w chmurze lub jako maszynę wirtualną można wykonać w ciągu kilku godzin.

To wystarczy, aby zacząć się rozwijać . Następnie, jeśli potrzebujesz CI, możesz dodać historię CI, jeśli potrzebujesz fizycznego serwera, oczywiście, dodaj historię do tego.

Ale zacznij dostarczać w dniu 1 i nigdy nie przestawaj!

Wczesne iteracje, zwłaszcza pierwsza, będą zawierać lub powinny przynajmniej planować skoki architektoniczne, które obejmują pewien czas odkrycia i być może architektoniczne prototypowanie.

Jak powiedziałeś, ogólnie rzecz biorąc, istnieją wymagania strukturalne, które mogą nie mieć większego znaczenia dla interesariusza / klienta, ale są wymagane do stworzenia silnej orientacji na platformę lub wzór. Nie możesz tego obejść, ponieważ nie możesz zacząć budować B, dopóki A nie zostanie ukończone.

Częścią zwinnego podejścia jest zamknięcie klienta, więc dokumentacja nie jest potrzebna, ponieważ wszystko, co musisz zrobić, to odebrać telefon / wysłać wiadomość e-mail i jest to oczekiwane. Oczekiwania klientów powinny być odpowiednio ustawione, a wszelkie wykonane prace powinny być bardzo zwięzłe i POTRZEBNE . Bez złocenia, nie „możesz go potrzebować” itd. Zbuduj to, czego potrzebujesz w A, aby przejść do B.

W zależności od tego, w jaki sposób atakujesz projekt, możesz tylko zbudować wymagany fundament, aby ukończyć określony moduł, więc podczas spotkania dotyczącego planowania sprintu opracowujesz plany dotyczące bieżącego sprintu w oparciu o priorytety określone przez klient, w zależności od tego, co jest potrzebne do tego sprintu, mogą istnieć pewne fundamentalne wymagania, więc to idzie do sprintu 1. Po zakończeniu pierwszego sprintu i zbudowaniu A, a następnie zaplanowaniu ukończenia B.

Jeśli uzgodniłeś z klientem harmonogram, tak długo, jak będziesz dotrzymywać tej umowy, klient prawdopodobnie nie będzie dbał o to, co robisz na 1. lub 2. miejscu. Zawsze możesz pokazać im wyniki testu jednostkowego, ale jeśli powiesz, że będziemy mieli coś do zobaczenia po sprincie 2 (lub 3), a ty dostarczysz, ustawi to silny priorytet. Oczekuje się, że klienci będą rozsądni tak samo jak programiści i obaj pracują nad tym samym celem. Zrealizowany projekt, który spełnia potrzeby klienta i działa zgodnie z oczekiwaniami. Tak niepokojące, że po sprincie 1 nie ma nic do zobaczenia, jest kwestią sporną, ponieważ klient chce tylko upewnić się, że po sprincie 20 projekt zostanie zakończony (-ish).