Co dostarczasz w pierwszych kilku iteracjach w Agile?

22

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?

JohnDoDo
źródło
2
Zbudowanie całego szkieletu lub fundamentu powinno być decyzją podejmowaną możliwie późno w projekcie.
JeffO
@JeffO: co masz na myśli tak późno, jak to możliwe? Czy potrafisz rozwinąć tę odpowiedź?
JohnDoDo
5
W idealnym przypadku decyzja nie powinna być wcale. Ramy nie należy tworzyć, powinny powstać organicznie w wyniku refaktoryzacji. Żadna „dobra” (jak na moją subiektywną definicję „dobrego”) frakcja nigdy nie została zaprojektowana od zera, albo zostały wyodrębnione po fakcie z istniejących aplikacji, albo w oparciu o inne frameworki, które były.
Jörg W Mittag
7
@JohnDoDo budowanie fundacji z góry zakłada, że ​​wiesz, jakie będą wymagania twojej aplikacji, zanim jeszcze ona powstanie. Za każdym razem, gdy widziałem, jak ludzie to robią, kończyli się czymś, co było sztywne i bardzo trudne w obsłudze. Użytkownicy tego „frameworka” częściej niż nie walczą z nim.
Stefan Billiet

Odpowiedzi:

15

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”.

ozz
źródło
6
+1 za ostatni akapit - dobrym pomysłem jest rozpoczęcie programowania od prototypu przeznaczonego do weryfikacji użytkownika.
Konamiman
4
„Może twój pierwszy sprint ma„ Utwórz stronę X z fałszywymi danymi ”, abyś mógł uzyskać coś błyszczącego, by pokazać swojemu klientowi.”: IMO zależy od klienta i skali czasowej projektu: w przypadku projektu 2-miesięcznego klient może chcesz zobaczyć coś w ciągu 1 tygodnia lub 2. W przypadku projektu trwającego 18 miesięcy może się okazać, że pierwsze demo pojawi się za 1 lub 2 miesiące. W każdym razie, chociaż niektórzy klienci mogą chcieć zobaczyć fikcyjną stronę, inni mogą chcieć zobaczyć coś bardziej sensownego i poczuć, że marnujesz ich czas. Myślę, że nie możesz generalizować.
Giorgio
4
+1, ale zawsze pamiętaj o górze lodowej, pokazując części interfejsu użytkownika klientowi joelonsoftware.com/articles/fog0000000356.html
Doc Brown
1
@MatthewFlynn - Scrum może nie mieć prawdziwej fazy „wymagań”, ale to nie znaczy, że są dostępne wymagania ZERO lub dokumentacja. Nigdy nie byłem zaangażowany w projekt, w którym klient powiedział: „po prostu zacznij budować, a my to rozwiążemy po drodze”. Myślę, że istnieje na to termin. Zwykle powinna istnieć jakaś faza pozyskiwania projektu, która obejmuje dyskusję i porozumienie co do tego, co zostanie dostarczone. Zaprezentowałem prototypy na boisku
hanzolo
1
@hanzolo - Bardzo udany projekt, nad którym ostatnio pracowałem, polegał na wdrożeniu rozwiązania mającego na celu spełnienie nowego wymogu prawnego, który był częścią ustawy Affordable Care Act. Podstawowe wymagania były znane, tak, ale nie było nic na drodze do prototypu lub projektu co do tego, jakie może być rozwiązanie. Zespół projektowy (w tym analitycy biznesowi) wymyślił to w kontekście sprintu. W najlepszym razie licencjaci rozmawiali z ludźmi biznesu o historiach sprint lub dwa przed resztą zespołu, ale to było wszystko, z czym musieliśmy pracować. Działa dobrze.
Matthew Flynn
13

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.

Matthew Flynn
źródło
8

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.

Euforyk
źródło
3

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).
użytkownik99561
źródło
„Konfigurowanie procesu dostawy” jest znacznie trudniejsze, niż ludzie myślą.
Frank Shearar
Tak to jest. Dlatego powinieneś to zrobić jak najwcześniej.
user99561
2

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).

BЈовић
źródło
+1 za to, że jako jedyny wspomniał o iteracji zero
crad
Nie rozważam ustawiania procesu kompilacji i wybierania zadań ram dla sprintu zero. Skąd możesz wiedzieć, jakiego szkieletu potrzebujesz, jeśli nie wiesz, co zbudować? Zawsze ograniczam sprint 0 do absolutnego minimum. Zdobądź komputery osobiste i znajdź miejsce, w którym mogą usiąść. Dowiedz się, z kim musisz porozmawiać z firmy. Umów pierwsze spotkanie planistyczne. Stosuję YAGNI do pozostałych.
user99561,
@ user99561 Ramy są dużymi decyzjami i zwykle trudno je zmienić. Na przykład powinieneś wiedzieć, czy zamierzasz używać gtest czy cppunit do testów jednostkowych przed rozpoczęciem pisania kodu. Późniejsza zmiana będzie ogromnym bólem w dupie i stratą czasu.
BЈовић
@ BЈовић: Tak, ramy są dużymi decyzjami, dlatego powinieneś je odłożyć. Nie ma sensu decydować o frameworku, jeśli nie wiesz, co należy opracować i jak będzie wyglądać aplikacja i architektura. Powinieneś zdecydować, jakich ram użyć w ostatnim możliwym momencie. W przeciwnym razie zdecydowanie ryzykujesz, że musisz to zmienić.
user99561,
@ user99561 Jeśli nie wiesz, co należy opracować, nie możesz nawet rozpocząć :) Wymagania i historie użytkowników muszą zostać zapisane, w przeciwnym razie iteracja 1 nawet się nie rozpocznie.
BЈовић
2

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!

Sklivvz
źródło
1

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).

hanzolo
źródło