Jak radzisz sobie ze zmieniającymi się wymaganiami? [Zamknięte]


14

W mojej obecnej pracy wydaje się, że mamy wiele zmian wymagań. Jesteśmy sklepem „Agile”, więc rozumiem, że mamy się dostosować, a co nie, ale czasami zmiana jest duża i nic trywialnego.

Moje pytanie brzmi: w jaki sposób efektywnie informujesz o koszcie zmiany? Z powodu zwinności, jeśli zmiana jest wystarczająco duża, coś zostanie upuszczone z bieżącego sprintu, ale zwykle dodaje się go następnym razem. Ponieważ naszym modelem jest SaaS, klientem końcowym jest faktycznie sama firma i wiedzą, że otrzymają funkcję cięcia n tygodni później.

Wydaje mi się, że to, o co staram się uzyskać, to usunięcie funkcji, której naprawdę nie można używać do komunikacji, ponieważ opóźniono ją tylko o n tygodni. Jakie inne sposoby musisz sprawić, aby firma zrozumiała, ile kosztuje zmiana?


Odpowiedzi:


14

@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

  1. X ilość czasu do ukończenia z 25% prawdopodobieństwem niepowodzenia (lub 75% sukcesu)

  2. 1,5 * X czasu do ukończenia z 5% porażką (lub 95% sukcesu)

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


Dziękuję za Twoją radę. Mam problemy z oszacowaniem nakładu dla projektów. W swoim poście polecasz pobrać go z poprzedniego projektu. Co jeśli nie mamy wcześniejszych danych, które mogłyby zostać przedstawione z oszacowaniem. A zasoby, którymi dysponujemy, to nowi członkowie zespołu (niektórzy są świeżymi absolwentami z niewielkim doświadczeniem, co sprawia, że ​​rzeczy są jeszcze trudniejsze do oszacowania)
user1872384

8

Z tego, co opisałeś, nie masz problemu. Proszą o zmianę i albo chcą poczekać, aż powiesz, że można to zrobić, albo odłożą kolejną funkcję. Wygląda na równowagę między: czasem, zasobami i wymaganiami.


Nie twierdzę, że dawanie i branie stanowi problem. Pytam, w jaki sposób informujesz o złożoności i zakresie zadawanych zmian?

2
@joe dajesz wtedy szacunek
jk.

4

Możesz spróbować ustawić minimalny wiek nowego dodatku / zmiany (nie dotyczy poprawek). Na przykład nie można wprowadzać żadnych nowych zmian, dopóki nie osiągną wieku 3 tygodni.

Posiadanie minimalnego wieku zadania jest przyjemne, ponieważ na początku każde zadanie wygląda na niezwykle ważne, ale jeśli poczekasz trochę czasu, jego znaczenie często spadnie znacząco. W zależności od interwału czasowego zapewnia co najmniej tyle czasu stabilności zadań, nad którymi pracujesz.

Aby śledzić wiek, zezwalasz na dodawanie zadań do niektórych list, ale nie będą one uważane za zadania do wykonania przed upływem tego okresu.


1

Jest to bardzo powszechny problem, bez względu na to, jak szybko projekt postępuje pod względem technicznym, klient postrzega go jako znacznie wolniejszy i może swobodnie zmieniać wymagania, ponieważ lubią myśleć, że programiści i tak nie powinni wiele robić.

Ta błędna percepcja wynika z trzech głównych zadań programistycznych, które pochłaniają czas i nigdy nie zostaną właściwie rozliczone przez klientów:

  1. Przeglądy / czyszczenie kodu: stary kod jest rozdęty i pomieszany i wymaga regularnych recenzji i czyszczenia, zajmuje to dużo czasu i klient nigdy w to nie uwierzy.
  2. Audyt bezpieczeństwa i poprawki: Zwłaszcza jeśli masz młodszych członków zespołu, będziesz miał wiele problemów związanych z bezpieczeństwem związanych z kodem i będziesz chciał regularnie przeglądać cały nowy kod, który został napisany i przepisywać rzeczy, które nie wyglądają dobrze z bezpieczeństwa perspektywa, klient nigdy się nie dowie ani nie uwzględni tego okresu.
  3. Zmiany związane z architekturą: Rosnąca baza kodu może (i najprawdopodobniej będzie) w wielu punktach wymagać strukturalnego przemyślenia i refaktoryzacji, co może obejmować: A - Zmiany / optymalizacje związane z wydajnością (zmiany algorytmu, wymiany bibliotek, silniki pamięci podręcznej itp.) lub: B - Zmiany / optymalizacje związane z produktywnością (czytelność, możliwość ponownego użycia kodu, łatwość zrozumienia, nowe konwencje kodowania, nowa struktura, ... itd.).

Żadne z powyższych nie będzie nigdy zrozumiane i właściwie rozliczone przez klientów końcowych.

Zasadniczo cokolwiek nie ma „widoków” (elementów GUI) nie zostało zrobione.

Nazwijmy to twierdzeniem projekcji, haha ​​nie tylko żartuję: D

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.