Czy późno ma jakieś znaczenie w metodologii Agile?

Wynikało to z niektórych odpowiedzi i komentarzy dotyczących innego pytania ( tego ).

Pracowałem przede wszystkim nad projektami z wodospadem i chociaż pracowałem nad projektami ad hoc, które przyjęły zwinne zachowania i przeczytały sporo o zwinności, powiedziałbym, że nigdy nie pracowałem nad „właściwym” zwinnym projektem .

Moje pytanie brzmi: czy pojęcie „późno” ma jakieś znaczenie w zwinności, jeśli tak, to co?

Moje rozumowanie jest takie, że z agile nie masz żadnego planu wstępnego i na początku nie masz szczegółowych wymagań. Możesz mieć na myśli cel na wysokim poziomie i związaną z nim hipotetyczną datę, ale oba mogą się zmienić (potencjalnie masowo) i żadne z nich nie jest pewne.

Więc jeśli nie wiesz dokładnie, co zamierzasz dostarczyć, dopóki nie dostarczysz go, a użytkownik zaakceptuje go, a jeśli nie masz harmonogramu po kolejnym sprincie, jak możesz spóźnić się w jakikolwiek sposób, że faktycznie ma znaczenie?

(Oczywiście rozumiem, że sprint może się skończyć, ale mówię o tym dalej).

Dla jasności jestem (osobiście) zadowolony z założenia, że ​​na czas projekty wodospadów (nawet stosunkowo duże) są możliwe w oparciu o to, że je widziałem i byłem w nie zaangażowany - nie są łatwe ani powszechne, nawet ale są możliwe.

Tu nie chodzi o zwinne poruszanie się, ale o zrozumienie go. Zawsze widziałem korzyść zwinności jako nic wspólnego z terminami lub budżetami (a raczej tylko pośrednio), ma to związek z zakresem - zwinność dostarcza bliżej tego, co jest naprawdę ważne, niż tego, co zespół projektowy uważa za ważne, zanim „ widziałem cokolwiek.

Nie zgadzam się, że projekt Agile nie ma wstępnego planu.

Z mojego doświadczenia wynika, że ​​analitycy biznesowi poświęcili sporo czasu na spotkania projektowe z klientami i programistami, aby opracować szczegółową listę możliwych do spełnienia wymagań, które są przedstawiane jako historie użytkowników. Są one następnie dzielone na zadania z odpowiednimi szacunkami dołączonymi przez doświadczonych programistów.

Po zidentyfikowaniu najważniejszych zadań na początku sprintu / iteracji można rozpocząć kodowanie. Ten proces selekcji określa znaczenie iteracji w całym projekcie („Budujemy proces logowania”). Różni członkowie zespołu zajmują się różnymi zadaniami niezbędnymi do stworzenia historii użytkownika.

Pod koniec iteracji wszystkie historie użytkowników dla tej iteracji powinny być kompletne, inaczej się spóźnisz . Podobnie rozwój powinien być w stanie zatrzymać się na końcu każdej iteracji i produktu wydanego. Może nie być kompletny pod względem wszystkich historii użytkowników, ale historie użytkowników, o które proszono w iteracji, są kompletne i produkt może działać w tych granicach.

„spóźnienie” w zwinnej metodologii oznacza to samo, co w metodologii wodospadu: szacunki były błędne, zakres był zbyt duży na przydzielony czas, pojawiły się nieoczekiwane trudności, klient nie reagował wystarczająco szybko, programiści się lenili, maszyny się zepsuły, twój pies zjadł mój kod bajtowy itp.

uczysz się z niego i dostosowujesz do następnej iteracji

różnica polega na tym, że może się to zdarzać co 2-4 tygodnie, więc lekcje się uczą, a proces dostosowuje się szybko

Tak, ale zajmie to tylko 1 miesiąc, aby wiedzieć, że nie osiągniesz 9-miesięcznej mitycznej ostatecznej daty zakończenia projektu zamiast 9.

Twoje rozumowanie opiera się na założeniu, że możliwe są wstępne plany i szczegółowe wymagania dla dużych projektów. Nie jestem pewien, czy istnieje wiele dowodów na poparcie tego. Może wszystkie horrory są anegdotyczne? Każdy programista chciałby pracować z kompletnymi i nigdy nie zmieniającymi się specyfikacjami, z którymi klient w pełni się zgadza i rozumie.

Za każdym razem, gdy podejmujesz jakieś zobowiązanie, ryzykujesz spóźnienie. Dotyczy to również zwinnych.

Wiemy jednak, że nie można przewidzieć przyszłości i wiemy, że klient będzie stale zmieniać zdanie, i zgadzamy się, że to dobrze. Jeśli to zaakceptujemy, musimy również zaakceptować, że wszystkie zobowiązania są prawie zawsze błędne, co z kolei sprawia, że ​​na pytanie dotyczące spóźnienia łatwo jest odpowiedzieć: zawsze się mylimy (za wcześnie lub za późno). To wszystko kwestia domysłów, bez względu na to, jak dobrze dopracowane. Rzuć monetą.

Jest to coś, co my, programiści, musimy po prostu zaakceptować iz tego punktu widzenia staramy się znaleźć inny sposób pracy, w którym kwestia spóźnienia staje się znacznie mniej ważna. Zmiana perspektywy. Myślę, że sposobem na to jest skupienie się na dostarczeniu działającego oprogramowania tak szybko, jak to możliwe, z opcją rezygnacji, gdy klient będzie zadowolony.

I na tym właśnie polega sprawność. Sprytny sposób radzenia sobie z tym niewygodnym przekonaniem, że spóźnienie jest faktem i po prostu musimy sobie z tym poradzić najlepiej, jak potrafimy.

Na przykład spóźniasz się, gdy nie wywiązujesz się ze zobowiązań podjętych na początku bieżącej iteracji. Jest to oczekiwane i powinieneś wyciągnąć z tego naukę i dostosować swój proces, aby zmniejszyć ryzyko niepowodzenia w następnej iteracji. Najlepszym sposobem, aby sobie z tym poradzić, jest jak najmniejsze iteracje.

W przypadku planowania wielu iteracji, zwanego także planowaniem wydania, należy użyć prędkości obliczonej na podstawie ukończonych iteracji i ekstrapolować dane, aby przewidzieć przyszłą datę wydania. Polecam artykuł Jamesa Shoresa lub własny (krótszy), aby uzyskać więcej informacji na ten temat. Pamiętaj jednak, że nigdy nie jest to solidne zobowiązanie, a bardziej „jesteśmy w 80% pewni, że do tego czasu ukończymy kolejne funkcje”. Może to (w pewnym sensie) spowodować spóźnienie, ale zaangażowanie jest tylko prawdopodobieństwem, a nie faktem.

Teraz zestaw to z podstawową obietnicą zwinności, że zawsze powinieneś być gotowy do wydania działającego oprogramowania, pełnego lub nie. Daje to klientowi swobodę zatrzymania rozwoju, gdy uważa, że ​​system jest wystarczająco dobry, co może nastąpić dużo wcześniej niż oczekiwano. Zachęca również do poprowadzenia projektu w nowych kierunkach w oparciu o prawdziwe informacje zwrotne z najnowszej iteracji.

Powyższe punkty powinny wystarczyć, aby każdy klient miał pełną kontrolę nad rozwojem i mam nadzieję, że to odpowiada na pytanie dotyczące spóźnień w zwinnych metodach.

Istnieją dwa rodzaje „późnych” w Agile SCRUM>

1. Przeniesienie - historie, które nie są „gotowe” na koniec sprintu, programiści „zobowiązują się” do wykonania PBI, więc jeśli nie zostanie zrobione, można to uznać za przeniesienie.

2. Mapa drogowa - Zakładając, że Twoja organizacja ma mapę drogową i zakładając, że ma daty, jeśli główne elementy dostawy dla tych dat zostaną pominięte, można to uznać za „spóźnione”.