Zwinne, wodospad i zmiany wymagań

Czy ktoś miał problem z definicją projektu zwinnego, który został przekroczony przez zmiany wymagań? Pracuję nad projektem deweloperskim, który jest realizowany za 4 tygodnie Sprint, ale między tymi Sprintami zawsze występują zmiany. Czy nadal jest to zdefiniowane jako Agile? Wydaje mi się, że jest to proces podrzędny - wymagania procesu zwinnego powinny zostać określone na początku sprintu i sprawdzone pod koniec. Czy mam rację? Daj mi znać o swoich doświadczeniach.

Wymagania procesu zwinnego powinny zostać określone na początku sprintu i poddane przeglądowi w kierunku jego przebiegu. Czy mam rację?

Nie, zależy to od charakteru projektu (i procesu).

Istnieje kilka zwinnych modeli programistycznych, w których wymagania mają być ustalone podczas sprintu i powinny się zmieniać tylko podczas następnego sprintu (wyraźnym przykładem jest Scrum).

Istnieją jednak procesy, w których zmiany mogą nastąpić prawie w dowolnym momencie (o ile klient zaakceptuje opóźnienia i dodatkową pracę, którą powoduje zmiana). Kanban jest często używany do zarządzania tymi przepływami pracy (chociaż Kanban można również łączyć ze Scrumem).

Wybór modelu zależy od szczegółów każdego projektu.

Tak więc, jeśli klient czuje, że potrzebuje możliwości ciągłej zmiany wymagań, wówczas zwinny proces może to uwzględnić. Jednak klient powinien zdawać sobie sprawę z konsekwencji ciągłych zmian i powinien zrozumieć, że spowolni projekt.

Sprowadza się to do zasad zawartych w zwinnym manifeście - „Osoby i interakcje dotyczące procesów i narzędzi” oraz „Reagowanie na zmianę w związku z realizacją planu”.

Myślę, że pytanie, które powinieneś zadać, brzmi: dlaczego jesteś przesadzony przez zmiany wymagań? Najczęstsze przyczyny to:

• Programiści nie mają (wystarczającego) kontaktu z użytkownikami końcowymi, więc nie mogą zrozumieć potrzeb użytkowników. Zamiast tego traktują wymagania jak abstrakcyjną kostkę Rubika - przestrzegają liter wymagań, nawet nie próbując zrozumieć swojego ducha
• Ktoś (np. Z marketingu) dodaje wymagania, które nie mają żadnego sensu dla użytkownika końcowego (ale np. Brzmią dobrze w broszurze). Jest więc bitwa między „prawdziwymi” wymaganiami a „innymi” wymaganiami, o którą walczyli deweloperzy
• Zakres projektu jest nieokreślony („Cóż, jeśli mimo to wdrażasz edytor tekstu, nie możesz po prostu dodać małego modułu, który zajmuje się naszą księgowością płac? Och, a Bill z drugiego zespołu programistów zapytał, jak ciężko by to było sprawić, by edytor tekstu również skompilował kod C ++? ”)

Niezależnie od głównego problemu, musisz to naprawić. Utopienie go pod warstwami „Agile” (lub innej metodologii) nie zadziała.

Przynajmniej w Scrumie, który wydaje się być zwinnym procesem, który jest obecnie najbardziej popularny wśród typów zarządzania, zakres sprintu jest ustalony. Jeśli Twój Back Sprint zmienia się podczas sprintu, to nie jest Scrum, to chaos. Backlog Sprint powinien zostać utworzony na początku sprintu i pozostać niezmienny do końca sprintu (w tym momencie utworzysz nowy Backlog Sprint dla następnego sprintu).

Jeśli Twój Backlog produktu zmienia się podczas sprintu, to nic wielkiego. Zmiany stają się po prostu nową pracą, która ma priorytet, jest szacowana i wybierana jak każde inne wymaganie do następnego sprintu. Jeśli wymagania zmieniają się tak bardzo, że Właściciel produktu musi regularnie przerywać sprint, masz Kłopot z dużą literą „T”.

Może potrzebujesz krótszych sprintów?

Dla zdrowia psychicznego programistów najlepiej jest, jeśli wymagania nie zmienią się podczas rewizji / sprintu.

W twojej sytuacji istnieją dwie oczywiste opcje:

1. krótsze sprinty
2. poproś klienta, aby zgodził się nie zmieniać wymagań podczas rewizji / sprintu, chyba że cała rewizja / sprint zostanie anulowana i ponownie zaplanowana

Bardzo polecam oba .

Główny problem polega na tym, że uważasz, że używasz Scruma, ale tak nie jest. Zwłaszcza twój właściciel produktu tego nie przestrzega. W Scrumie sprint jest bezpieczną strefą i nie można wprowadzać żadnych zmian w historiach zatwierdzonych użytkowników, chyba że bieżący sprint zostanie anulowany. Egzekwowanie tego jest obowiązkiem mistrza Scrum. Jeśli to nie działa w twoim środowisku, oznacza to problem z procesem = nie używasz Scruma.

Najprostszą zmianą, jaką możesz zrobić (jeśli chcesz podążać za Scrumem), jest skrócenie sprintu - na przykład tydzień. 4-tygodniowe sprinty były rozważane jako opcja we wczesnych dniach Scruma, ale dziś powszechne są 1-2 tygodnie, a 3 tygodnie są uważane za górną granicę. 4 tygodnie to bardzo długi czas w zmieniającym się otoczeniu.