Jak uniknąć zarządzania z naszego procesu rozwoju

Jestem inżynierem oprogramowania w zespole programistów. Przez ostatnie 3 lata pracowaliśmy dla klienta wewnętrznego nad nowym produktem. Teraz, gdy ten produkt jest gotowy, będziemy pracować nad głównymi nowymi funkcjami istniejących produktów. W przypadku określonej funkcji kierownictwo produktu zgadło, że jej opracowanie zajmuje 150 godzin. Wspólnie z naszym kierownikiem projektu opracowaliśmy bardzo szczegółowy plan i staramy się pracować 300 godzin. Wczoraj dyskutowaliśmy o tym i uważają, że rażąco przeceniliśmy rzeczy.

W naszym planowaniu oszacowaliśmy godziny na pisanie testów jednostkowych, ich pomysłem jest zrzucenie ich, aby zaoszczędzić czas. Decyzja nie została jeszcze podjęta i będę bronić tego planowania i testów jednostkowych w razie potrzeby. Ale tak naprawdę nie podoba mi się tutaj to, że zarządzanie zakłóca nasz proces rozwoju. Jak uchronić je przed procesem rozwoju? I jakich argumentów mogę użyć, aby utrzymać testowanie jednostki (oprócz jakości i oszczędności w długim okresie)?

Na marginesie, nasza firma ma 3 zespoły inżynierów, a zespół, w którym pracuję, dostarcza swoje oprogramowanie na czas (daj lub weź 10% marginesu). Podczas gdy inne zespoły zawsze dostarczają późno, głównie z powodu niedoszacowania w planowaniu. Planują tylko kodowanie, a nie zarządzanie, testowanie i obsługę wokół niego.

Po pierwsze, pozwól mi powiedzieć, że całkowicie popieram twoje stanowisko. Może to być frustrujące, gdy brakuje zrozumienia lub zakłócenia komunikacji między różnymi częściami firmy. Powiedziawszy to, nie sądzę, że powinieneś próbować ich powstrzymywać. Zamiast tego powinieneś pokazać im liczby dotyczące tego, dlaczego jest to dobry pomysł. Jakie masz fakty uzasadniające testowanie jednostkowe, warte jest włożonego w nie wysiłku? Jeśli nie masz, powinieneś zacząć zbierać te dane lub pokazać badania, które potwierdzą twoje twierdzenia.

Sam miałem do czynienia z podobnymi scenariuszami i odpowiedziałem na to pytanie na podobny temat . Blogowałem również o tym, jak sobie z tym poradziłem:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

Jeśli nie masz ochoty gonić za linkami, powtórzę moje streszczenie z powiązanego pytania:

Podsumowując, porównałem nasze szacunkowe godziny z faktycznymi godzinami dla projektu, a następnie porównałem nasz wskaźnik wad z współczynnikiem wad innych zespołów. W naszym przypadku liczby te wypadły korzystnie i nie było już żadnych obaw.

Mój wniosek oparty na tym doświadczeniu jest następujący:

... najlepszym sposobem, aby przekonać każdego, że twoje podejście do robienia czegoś jest praktyczne i pragmatyczne, to zrobić to i porównać z innymi podejściami. Ludziom nie zależy na dogmatach ani na tym, dlaczego uważasz, że coś powinno być najlepszym sposobem. Tylko pokazując ludziom liczby i mierząc skuteczność swojego podejścia, możesz naprawdę pokazać, że twoje praktyki są skuteczne.

Jeśli Twój zespół zarządzający nie zgodzi się na zainwestowanie tego, co postrzegają jako dodatkowe 150 godzin w testowanie jednostkowe, być może uda ci się przekonać ich do zainwestowania w jeden niewielki obszar produktu (lub nawet zgodzić się, aby sami sobie poradzili, aby podać jakieś dane ). Wykonaj testy jednostkowe w tym jednym obszarze produktu, a następnie zbierz dane o wskaźnikach wad w tym obszarze produktu oraz o kosztach znalezienia i usunięcia tych wad w porównaniu ze wskaźnikami wad w innych obszarach produktu. Mamy nadzieję, że zgromadzisz trochę danych, aby wykonać kopię zapasową sprawy, co nie będzie stanowić problemu w następnym projekcie.

Najważniejszą zasadą, której należy przestrzegać, niezależnie od używanej metody, jest właśnie to

1. Deweloperzy powinni mieć prawo do oszacowania własnej pracy.
2. Zainteresowane strony powinny mieć prawo do priorytetowego traktowania tych prac.

Szacowanie i ustalanie priorytetów to dwie siły, które działają bardzo dobrze razem, gdy obie strony zaakceptują swoje własne obowiązki. Zamiast więc marnować czas na kłótnie, zgódź się na to i uszanuj, że obie strony wykonają swoją pracę najlepiej jak potrafią.

Możesz wskazać, że testy jednostkowe oszczędzają czas, więc jeśli je upuścisz, szacunkowy czas pracy wynosi 500 godzin.

Powiedz im o zadłużeniu technicznym i wartości testów jednostkowych

Spójrz na ten post z fajnego pomysłu na dług techniczny. Kontynuując ten post, możesz przejść do następującego pliku pdf

Podoba mi się ten post na temat wartości testów jednostkowych (prawdopodobnie jest więcej do znalezienia)

Mamy nadzieję, że nie wydostanie ich z procesu rozwoju, ale zaangażuje ich i zaangażuje we właściwy sposób.

IMHO musisz zapisać swoje pierwotne planowanie, dodać rozdziały 1 i 2 (nie w dodatku), w których wyjaśnisz dług techniczny i wartość testów jednostkowych. Daj im alternatywy:

• mniej godzin (nie całe 150, to brzmi absurdalnie), gdzie każda zmiana (podczas fazy rozwoju i konserwacji) potrwa średnio:
  • małe 4 godziny
  • średnie 16 godzin
  • duże 40 godzin
• szacunkowe godziny, w których średnio każda zmiana (faza rozwoju i podczas konserwacji) zajmie:
  • małe 2 godziny
  • średnio 8 godzin
  • duże 20 godzin

(Godziny są tylko orientacyjne. Jesteś o wiele lepiej przygotowany, aby podać prawidłowe dane szacunkowe.)

Nie zapomnij podać swoich osiągnięć w terminowych dostawach budżetowych.

Zapisz to i przedyskutuj to z nimi. Mogą mieć pewne cenne punkty w funkcjach, których tak naprawdę nie potrzebują teraz, lub jakiś dług techniczny, który są gotowi wziąć w celu dostarczenia na czas. Upewnij się tylko, że są to świadome wybory.

Mam nadzieję, że to pomoże i powodzenia.

Przede wszystkim nie dziel „testów jednostkowych” jako osobnego zadania, które ma zostać oszacowane, zaplanowane i potencjalnie skrócone. Twoje szacunki powinny być na poziomie funkcji „Implementuj XYZ - 18 godzin”. Te 18 godzin powinno obejmować wszystko, czego potrzeba, aby ustawić tę funkcję na „ZAKOŃCZONO”, w tym „pisać testy jednostkowe”.

To jedna dobra droga, aby pozatechniczny rozwój „z procesu rozwoju”. Nie dołączaj swojego procesu rozwoju do podanej listy zadań lub harmonogramu projektu!

Po drugie, wygląda na to, że Twój zespół już dostarcza im dobre produkty na czas, ale inne zespoły nie. Być może ta grupa zarządzająca jest przyzwyczajona do mikrozarządzania tymi zespołami. Wykorzystaj swoje mocne strony - zaoferuj cotygodniowe lub dwutygodniowe aktualizacje z działającymi funkcjami, a oni odejdą od ciebie na temat „procesu rozwoju”.

Kiedyś byłem w sytuacji, w której pracowałem z bazą kodu w bardzo dobrym stanie; wymagająca nowa funkcja była potrzebna w bardzo krótkim czasie, a ja udało mi się ją dostarczyć w bardzo krótkim czasie. W tym momencie baza kodu była w znacznie gorszym stanie. Tak więc funkcja została dostarczona, ale moja praca nie została wykonana: musiałem przywrócić wszystko do równie dobrego stanu.

Wyjaśniłem menedżerowi dwa poziomy wyżej: To jak malowanie w domu. Jeśli wszystkie narzędzia są tam, gdzie należą i są w dobrym stanie, wszystkie pędzle zostały wyczyszczone itd., Można bardzo szybko wykonać lakierowanie. Ale musisz poświęcić czas na uporządkowanie wszystkich narzędzi. Jeśli tego nie zrobisz, następne malowanie potrwa znacznie dłużej. W rzeczywistości nie pamiętasz, gdzie są twoje narzędzia, nie możesz już odzyskać pędzli, a to kosztuje znacznie więcej czasu i pieniędzy, jakbyś natychmiast wykonał porządek.

I to samo w mojej pracy programistycznej: sprzątając, doprowadzam bazę kodu do stanu, w którym mogę ponownie dostarczyć coś bardzo szybko, gdy następnym razem będzie to potrzebne. Jeśli nie, następnym razem potrwa to znacznie dłużej.

Nie możesz ich całkowicie wykluczyć z procesu, w końcu płacą ci wynagrodzenie i będą korzystać z twojego produktu (jeśli nie bezpośrednio, prawdopodobnie ktoś w twojej firmie jest użytkownikiem końcowym).

Menedżerowie oskarżający deweloperów o przeszacowanie czasu to bardzo częsty scenariusz z mojego doświadczenia, a jeśli nie zostanie to rozwiązane, może doprowadzić do dość głupiego wyścigu zbrojeń, w którym kolejne szacunki zostaną podwojone, ponieważ wiesz, że szefowie je zmniejszą o połowę, wiedzą o tym tak dzielą je na ćwiartki, więc poczwórnie je itd. itd. Jeśli to możliwe, musisz unikać tego błędnego koła.

Zakładając, że nie ma powodu do „dead dead” powodu terminu, sugerowałbym 2 rzeczy.

1. Przedstaw szczegółowy plan tego, co według Ciebie możesz zrobić w 150 godzin, przestrzegając obecnego podejścia do pracy wysokiej jakości. Wymień dokładnie, co może zostać dostarczone w tych ramach czasowych. Odpowiedź od KeesDijk ma bardzo dobre połączenia na temat planowania przy drobnoziarnista poziomie.
2. Kontynuuj w tym samym stylu szczegółowego planowania, aby objąć wszystkie funkcje i pokazać, jak to potrwa 300 godzin (lub cokolwiek wyjdzie na to).

Następnie zabieraj się do pracy i regularnie składaj sprawozdania z postępów, a jeśli to możliwe, regularnie dostarczaj jakieś produkty. To powinno dać zarządowi zaufanie do twoich umiejętności szacowania i zdolności do dostarczania.

Zapytaj ich o podstawę ich szacunków. Dyskusja na temat rozbieżności jest sprawiedliwa. Zrzucanie testów jednostkowych to fałszywa ekonomia, czego nie spędzasz na pisaniu testów jednostkowych, które wydasz w debuggerze później (i dłużej). Zasadniczo udokumentowałeś fakt, że planujesz przetestować ukończoną pracę. Mówią ci nie testu w ogóle . Niezależnie od tego, czy testujesz przy użyciu testów jednostkowych, czy testów ad hoc podczas opracowywania projektu, nadal musisz wziąć pod uwagę ten czas. Usunięcie czasu przeznaczonego na testy jednostkowe powoduje również usunięcie czasu przeznaczonego na testy ad hoc.

Podsumowując: trzymaj się swojej broni z szacunkiem. Z twoich osiągnięć wynika, że ​​wiesz, o czym mówisz, i możesz udzielić rozsądnej odpowiedzi co do podstawy swoich szacunków (założeń, oczekiwań, wcześniejszych wyników itp.). Wygląda na to, że twoje kierownictwo nie ma widoczności, której potrzebują, aby dokonać rozsądnej oceny. Czy zakładają 8 godzin bez przerwy na spotkania? Czy przewidują budżetowanie na testy systemu? Jak wymyślili liczbę, która jest twoją połową, biorąc pod uwagę twoje osiągnięcia?

Szacuję, że zajmie to 300 godzin, a jeśli budżet 150 da im opcję, albo będzie to robota buggy, albo spóźniona z dostawą. Kiedy projekt jest ukończony i jest zgodny z przewidywaniami, możesz po prostu powiedzieć im, o co prosiłeś.

Co zrobiłby Wally?

Istnieje wiele sposobów interpretacji żądań kierownictwa, jednym z nich jest to, że nie chcą, abyś dostarczył je na czas.

Czy to absurdalne? Tak, ale skąd oni mogą wiedzieć, że nie przeceniasz? Nie dotrzymuj terminów (w razie potrzeby zwolnij), jeśli poślizgniesz się i przypadkowo dostarczysz coś na czas, upewnij się, że wyglądasz na naprawdę zmęczonego, aby nie sprawiać wrażenia, że ​​był to spacer po parku.

Jesteś w zalewie. Jeśli trzymasz się broni i chcesz pozostać przy testach jednostkowych i chcesz zająć 300 godzin, staniesz się wrogiem.

Jeśli skrócisz do 150 godzin i wykonasz testy jednostkowe uchwytu, możesz szybciej dostarczyć produkt buggier, ale spowoduje to żal na drodze, powodując wyższe koszty utrzymania.

Tak czy inaczej, przegrywasz.

A przynajmniej tak się wydaje.

Widzisz, nie prowadzisz laboratorium naukowego na uniwersytecie. Świadczysz usługi biznesowe jednostce biznesowej w firmie, która świadczy usługi klientom w ekosystemie firm. Twoja firma może potrzebować Twojego produktu, aby zacząć dostarczać szybsze i lepsze usługi dla swoich klientów, a tym samym zwiększyć potrzebne przychody.

Widzisz, potrzebna jest analiza ROI i nie masz wszystkich danych do jej przeprowadzenia. Masz tylko część kosztów (nie znasz liczb płac wszystkich osób) i na pewno nie masz części przychodów, zwłaszcza nie prognozowanych przychodów.

Wasze kierownictwo, wierzcie lub nie, jest biegłe w tworzeniu prognoz ROI (tego uczą w szkole biznesu) i może przeprowadziło wiele prognoz ROI i wymyśliło „jeśli działamy teraz, zarobimy o wiele więcej pieniędzy nawet płacąc trzykrotnie za utrzymanie oprogramowania, na które skarży się bozo w IT ”.

Tak więc, jeśli chcesz prowadzić wspólne przedsięwzięcie, załóż własną firmę. Zobaczysz, to nie jest takie proste.

Innymi słowy: rób to, co ci każą. Jeśli kierownictwo wie, co robi, wyjdziesz na przód. Jeśli nie, nie masz pracy, testów jednostkowych, czy nie.

O jaki ROI pytasz? Zwrot z inwestycji. Ale to zła nazwa. Musi to być zwrot z terminowej inwestycji (ROTI), ponieważ czas jest wszystkim w inwestycji.