@Joe „Jesteśmy sklepem„ Agile ”, więc rozumiem, że mamy się dostosować, a co nie, ale czasami zmiana jest duża i nic trywialnego.”
Jeśli twój proces nie pozwala ci kontrolować tempa zmian wymagań, proces nie jest zwinny, ale przypadkowy. Zwinność nie oznacza „zabrania czegokolwiek, co stanie mi na drodze”.
Aby kontrolować zmianę / pełzanie wymagań, możesz przyjąć - w swoim procesie - pojęcie, że wymaganie się nie zmienia (przekonanie, że jest to sedno Scruma). Traktuj zmianę wymagania jako zastąpienie starego wymagania nowym. Musisz mieć zaległe wymagania i użytkownik musi wybrać, które z nich chce wdrożyć.
Chciałeś X i Y za dwa tygodnie, ale nagle chcesz Z. Cóż, wtedy mogę dostarczyć ci wszystkie trzy za 4 tygodnie. Albo mogę podać parę (X i Z) lub (X i Y) lub (Y i Z) w ciągu dwóch tygodni, a resztę dostarczyć później. Wybierać.
W ten sposób negocjujesz z klientami. W ten sposób informujesz o koszcie zmiany wymagań. Jeśli twoja grupa nie ma takiej mocy, nie jesteś w zwinnym sklepie i nic nie możesz na to poradzić. To jest do bani, ale to prawda.
W przypadku, gdy możesz negocjować, musisz śledzić (z precyzją) czas potrzebny do wdrożenia wymagań i zmian wymagań. Oznacza to, że musisz zebrać te dane z poprzednich i obecnych projektów.
Zbierasz pierwotny szacunkowy czas i rzeczywisty czas zakończenia (oprócz zasobów takich jak liczba programistów) na żądanie (lub moduł, na który wpływa N wniosków). Jeszcze lepiej, oszacuj wielkość zmiany żądania / żądania (pod względem linii kodu lub punktów funkcyjnych w poprzednich projektach i żądaniach).
Załóżmy, że masz dane, z którymi możesz porozmawiać z użytkownikiem. Wiesz, że nowe żądanie zajmie, powiedzmy, 1 000 wierszy kodu lub 10 stron internetowych ze średnio 5 polami wejściowymi każde (50 punktów funkcyjnych).
Następnie, patrząc na dane historyczne specyficzne dla twoich wcześniejszych projektów (niektóre według linii kodów, niektóre według stron internetowych, niektóre według faktycznych punktów funkcyjnych), możesz oszacować, jak każdy z nich kosztuje pod względem bezwzględnego czasu realizacji. Dla osób posiadających wystarczającą ilość danych można również zidentyfikować wymagania, które śledzą faktyczną liczbę pracowników programistów.
Następnie używasz tego i mówisz swojemu klientowi, że na podstawie danych historycznych; argumentujesz, że niepowodzenia projektu zwykle następują po rozkładzie wykładniczym; a następnie jesteś uzbrojony w następujący argument dla swojego klienta:
W oparciu o dane z naszych przeszłych i obecnych projektów i dostępnych zasobów, wymagania, o które pytasz, zostaną spełnione
X ilość czasu do ukończenia z 25% prawdopodobieństwem niepowodzenia (lub 75% sukcesu)
1,5 * X czasu do ukończenia z 5% porażką (lub 95% sukcesu)
0,5 * X czasu do ukończenia z 95% niepowodzeniem (lub 5% sukcesu)
Prawdopodobieństwo awarii w zależności od ilości zasobów czasu zwykle wynosi 95%, 25% i 5% (przypominając rozkład wykładniczy). Przekazujesz komunikat, że pewna podstawowa kwota daje dość przyzwoitą szansę na sukces (ale z realnym ryzykiem ). 1,5 z tego może dać prawie pewną szansę na sukces przy minimalnym ryzyku, ale znacznie mniej niż to (0,5 pierwotnego gwarantuje prawie pewną porażkę).
Pozwalacie im to trawić. Jeśli nadal wybierają ryzykowną propozycję ( zrobioną wczoraj! ), Przynajmniej masz na piśmie, że im to powiedziałeś. Jeśli masz nadzieję, że twoja grupa będzie nie tylko zwinna, ale również inżynierska, klient może poważnie rozważyć twoje liczby i odpowiednio zaplanować to i przyszłe żądania.
Twoim zadaniem jako inżyniera jest wyjaśnienie inżyniera, weryfikowalne i jasne warunki, że żądania zmian nie są bezpłatnym posiłkiem.