Czy można zastosować elastyczne podejście zwinne do projektów, które wymagają oszacowania zarówno czasu poświęconego, jak i zaoszczędzonego czasu?

Jako osoba, która wcześniej efektywnie pracowała z Agile, staram się przekonać moich obecnych pracodawców o jej zaletach. Jednak zarząd nalega, aby zachować możliwość dokonywania wstępnych szacunków w celu oceny wartości biznesowej projektów.

Większość moich klientów ma charakter wewnętrzny, a ostatnio miałem za zadanie obchodzić zespoły i prosić ich o pomysły na automatyzację procesów biznesowych. Miałem wtedy dowiedzieć się, ile czasu to zabierało, dowiedzieć się, ile czasu zaoszczędziłoby rozwiązanie i oszacować całkowity czas programowania. W ten sposób menedżerowie mogliby zmierzyć skuteczność rozwiązania pod względem oszczędności czasu.

Wydaje mi się jednak, że nie ma sposobu, aby podejść do tego wymogu w sposób „zwinny”. Elastyczne wymagania oznaczają, że nie tylko oszacowanie zajętego czasu będzie błędne, ale także oszacowanie potencjalnego zaoszczędzonego czasu. Wyjaśniłem tyle samo, wyjaśniłem, dlaczego może to być problematyczne, ale powiedziano mi, że nie podlega negocjacji.

Pytanie Jak sprzedać programowanie Agile klientom (wodospadem) zawiera przydatne porady na temat tego, jak „sprzedać” Agile klientom zewnętrznym. Nie próbuję go sprzedawać klientom zewnętrznym: staram się ustalić, jak najlepiej pogodzić wymagania wewnętrznego zarządzania, zachowując metodologię, która moim zdaniem działa dobrze.

Czy istnieje sposób na elastyczne podejście do tego zadania, które pozwala mi zachować przynajmniej niektóre korzyści Agile?

Jak stwierdzono w innych odpowiedziach, Kierownictwo ma wszelkie prawo do uzyskania wysokiego poziomu szacunku przed projektem. Nie są nierozsądne przy próbie ustalenia ROI.

Jednym z podejść, które lubię w Agile, jest to, że zakres projektu nie jest ustalony. Można go wstępnie oszacować na poziomie Funkcji i Epic, a następnie firma może określić ROI na podstawie najważniejszych funkcji. Być może fantazyjny interfejs użytkownika z dzwonkami i gwizdkami ma niską wartość biznesową, ale silnik przepływu pracy do obsługi roszczeń ma wysoki zwrot z inwestycji.

Kiedy skupisz cały projekt razem, trudniej jest osiągnąć zwrot z inwestycji niż skupić się na kluczowych funkcjach biznesowych, które są pożądane.

Oto jak to zrobiłem:

Zabierz swoje kamienie milowe WBS i zmień każdy z nich w funkcję umożliwiającą dostarczenie

Pozwala to na podzielenie projektu na małe podprojekty o różnej wartości biznesowej. Każdy z nich powinien być samodzielny pod względem wartości biznesowej.

T-Shirt Rozmiar wysiłku na funkcje

Jest to bardzo łatwy sposób, aby uzyskać ogólne pojęcie o tym, jak duża lub zaangażowana może być konkretna funkcja. Być może funkcje o niskiej wartości nadal mają świetny zwrot z inwestycji, jeśli wyglądają na łatwe wygrane.

Podziel funkcję na historie

Przejrzyj ćwiczenie, aby znaleźć małą dobrze zrozumiałą funkcję i początkowo podzielić ją na historie. Oszacuj te historie według punktów. Teraz masz podstawę gdzie

Mały -> 40 punktów

Będzie to podstawa do porównania z innymi funkcjami

Skojarz punkt fabularny ze wszystkimi funkcjami

Porównaj swoją małą funkcję z innymi funkcjami. Na przykład,

Średnia cecha Y wydaje się być dwa razy większa niż wysiłek małej cechy X w porównaniu z 40 punktami historii.

Średnia cecha Y to prawdopodobnie 80 punktów historii. Kontynuuj to, aż uzyskasz punkty historii na wysokim poziomie dla wszystkich funkcji.

Oszacuj swoją prędkość drużyny

Patrząc na zespół programistów, spróbuj ustalić, ile punktów historii może skutecznie dostarczyć ten zespół w danym sprincie. Jeśli masz wcześniejsze projekty Agile jako przykład z tym zespołem, to jest świetne miejsce na rozpoczęcie. Jeśli nie masz takiej historii za zespołem, przejdź ze swoim zespołem próbne Planowanie Sprintu, w którym zaczynasz patrzeć na swoją małą funkcję, którą szczegółowo opisałeś. Jakie szacunki godzinowe ludzie opowiadają za swoje zadania związane z tymi historiami?

Na podstawie tego, ile pracy zespół może wykonać w ciągu 2 tygodni, użyj tej całkowitej liczby punktów historii jako średniej potencjalnej prędkości twojego zespołu!

Znajdź przewidywaną datę ukończenia

Jeśli Twój zespół podczas próbnego planowania sprintu czuje się komfortowo, dostarczając 25 punktów historii w sprincie, a całkowite zaległości wyglądają jak 300 punktów historii dla złotej wersji projektu Cadillaca, to wygląda na to, że Twój zespół idealnie zająłby 12 lub 24 tygodnie sprintu uzupełnij wszystko.

Teraz przekształcenie kosztu zasobów w zespół na dolary tygodniowo jest banalne, aby uzyskać zwrot z inwestycji ROI w stosunku do wartości biznesowej. Negocjacje mogą być kontynuowane na temat najważniejszych funkcji, a wtedy zarządzanie projektem staje się w zasadzie problemem plecakowym.

To nie jest problem z „zarządzaniem”. Bezwzględnym wymogiem jest możliwość oszacowania kosztów i korzyści każdego potencjalnego projektu przed rozpoczęciem. W przeciwnym razie, skąd ktokolwiek wiedziałby, co warto robić (lub próbować)?

Dlaczego więc zwinny?

Twierdziłbym, że stosowanie metod zwinnych nie oznacza wyboru niepewności. Agile jest raczej argumentem, że niepewność jest nieunikniona, a szczegółowe specyfikacje i szacunki tradycyjnych metod wprowadzają fałszywą pewność - co może być dość kosztowne.

Niektóre kluczowe punkty w zakresie szacowania czasu:

• Zmiany wymagań w trakcie projektu są nieuniknione; Zwinny bierze to pod uwagę zamiast udawać, że nie będzie żadnych zmian.
• Szczegółowe specyfikacje często zawierają wady projektowe, które nie są ujawniane, dopóki nie wejdą w projekt. Może to oznaczać większe zmiany w tradycyjnym projekcie niż w Agile.
• Oszacowanie czasu oparte na „jak dużym znaczeniu wydaje mi się ten cały projekt?” prawdopodobnie będzie tak samo dokładne jak zsumowanie szacowanego czasu dla wielu szczegółowych wymagań.
• Najważniejsze, co prowadzi do dobrych oszacowań, to cykl szacowania, pomiaru i przeglądu - który można zastosować do każdego spójnego procesu.
• Oszacowanie „zaoszczędzonej pracy” będzie oparte na pierwotnych wymaganiach dotyczących projektu, a nie na szczegółach, więc wątpię, by Agile zaszkodziłoby możliwości oszacowania tego.

Aktualizacja:

Aby wyjaśnić, twoja odpowiedź na twoich szefów brzmi: „Nie możemy oszacować zaoszczędzonego czasu ani całkowitego wysiłku rozwojowego przy użyciu Agile, ponieważ jest elastyczny”. Myślę, że to błąd. Uważam, że te szacunki można równie dobrze dokonać, stosując proces zwinny, ponieważ i tak istnieje niepewność. I oczywiście Agile pozwala na bardziej elastyczny i elastyczny proces w miarę rozwoju projektu.

Jest to z pewnością jedna z najtrudniejszych części wprowadzania Agile

„Zarząd wciąż potrzebuje szacunków czasu”

Moje podejście to:

• Pad 300%. Stare powiedzenie 300% jest przydatne, gdy jesteś w sytuacji, w której bycie naprawdę zwinnym na poziomie zarządzania nie nastąpi. Nie jest to może „zwinne podejście”, ale jest kompromisem w tej sytuacji. Będziesz mógł przejść kilka razy do przodu - ale nie licz na to!

• Poproś o recenzję w oparciu o pracę osiągniętą w punkcie, który byłby w połowie projektu. Projektuj kiedy będziesz kompletny na podstawie wykonanej pracy. Następnie porozmawiaj z zarządem i przejdź przez nich, które poświęcić - funkcjonalność lub jakość - biorąc pod uwagę, że czas jest ustalony na podstawie domysłów na początku projektu.

• Upewnij się, że współpracujesz w zakresie wykonanych funkcji i jakości zarządzania, aby faktycznie podejmowali te decyzje

• Podążaj za nurtem tego projektu i pozwól, aby zdarzyły się zwykłe rzeczy - przekroczone terminy, obniżona jakość, wypaleni i zestresowani (i prawdopodobnie odeszli) odchodzący pracownicy. Kiedy pojawi się kolejny projekt fazy, omów te „skutki uboczne”.

• Skoncentruj się i zademonstruj zalety „prawdziwego” zwinnego podejścia. Mów o poprawie jakości. Porozmawiaj o możliwości wprowadzania zmian późno w ciągu dnia, aż do ich wprowadzenia do produkcji. Mówił o mniejszej potrzebie ponownej pracy. Mów o mniejszym zadłużeniu technicznym, który ostatecznie doprowadzi rozwój do szaleństwa. Zrób analogie do prawdziwego świata, na przykład możemy odłożyć wymianę oleju każdego dnia, ale odłóż ją wystarczająco długo, a silnik cierpi, słabo działa i ostatecznie wieje pręt.

• Aktualizuj swoje CV i linkIn profil. Jeśli po kilkukrotnym zgłoszeniu sprawy nie możesz uzyskać wsparcia w zakresie zarządzania, przejdź dalej. Niektóre organizacje nie będą wymieniać Twoich argumentów, więc przejdź do tych, które to robią. Nazwał to zatrudnieniem darwinizmu;)

Myślę, że przyjmujesz fałszywe założenia dotyczące rozwoju Agile. Elastyczność i zmieniające się wymagania są dosłownie upieczone w Agile Manifesto .

Witamy zmieniające się wymagania, nawet w późnej fazie rozwoju. Zwinne procesy wykorzystują zmiany w celu uzyskania przewagi konkurencyjnej klienta.

Elastyczne (czytaj: zmieniające się) wymagania są mile widziane w Agile. Oczywiście jeśli zapytasz większość programistów, dodadzą zastrzeżenie, że zmiana musi być uzasadniona. Poproszenie zespołu o zbudowanie gry 3D, a następnie zmiana wymagań dotyczących „systemu sterowania reaktorem jądrowym” to trochę za dużo. Ale dodawanie, usuwanie lub modyfikowanie wymagań w zakresie projektu jest całkowicie w porządku.

Pytanie brzmi, jak radzisz sobie ze zmieniającymi się wymaganiami? Typową odpowiedzią jest użycie krótkich iteracji, abyś mógł wcześnie dokonać korekty kursu, zanim zmarnujesz zbyt dużo czasu. Zmusza zespół do rozkładania wymagań na mniejsze części, aby każdy mógł je lepiej zrozumieć i wdrożyć w rozsądnym czasie i wysiłku.

Prostota - sztuka maksymalizacji ilości niewykonanej pracy - jest niezbędna.

Podoba mi się również ta zasada zwinności. Zazwyczaj uważa się, że zespół powinien dążyć do dostarczania tylko tych rzeczy, które są niezbędne dzięki bezwzględnej wydajności. Na przykład: jeśli klient myśli, że czegoś potrzebuje, ale wydaje się podejrzany, rozejrzyj się. Może użytkownicy końcowi naprawdę nie mają z tego pożytku, więc nie należy wykonywać pracy.

Myślę jednak, że twoje pytanie dotyczy innego aspektu tej zasady. Oprogramowanie zasadniczo służy do automatyzacji procesu ręcznego. Samo oprogramowanie istnieje po to, aby zmaksymalizować ilość pracy niewykonanej - przez użytkowników końcowych.

Mierzenie ilości pracy, jaką oprogramowanie zaoszczędzi użytkownikom końcowym, jest zdecydowanie godną miarą. Zmierzyłem to sam w swojej karierze. W rzeczywistości jest to kluczowy element analizy kosztów i korzyści: ile wysiłku włoży projekt oprogramowania w porównaniu do tego, ile wysiłku produkt końcowy uratuje użytkowników końcowych.

Jest to całkowicie zgodne z filozofią programowania zwinnego (lub jakąkolwiek inną), a twoje kierownictwo absolutnie powinno się na to zgodzić.

Tak, zwinność ma pewne zalety.

• Pozwala ludziom biznesu zmienić zdanie podczas lotu.
• W pewien sposób chroni firmę przed wiecznie złymi szacunkami inżyniera.
• Zapewnia wartość wcześnie i często przed osiągnięciem ostatecznej wizji.
• To oszczędza Ci niektóre z kosztów planowania up-front, który często może wywołać złe planu anyway .
• To jest super fajne. Dobrze?

Ale nadal musisz podać dość dokładne wstępne szacunki.

Jeśli tego nie zrobisz, skutecznie poprosisz firmę o zainwestowanie w Twój produkt bez żadnych dowodów, że Twój produkt jest nawet wart początkowej inwestycji - aw niektórych przypadkach w ogóle nic.

I teraz to słyszę.

Już to słyszałem. Jestem pewien, że powiedziałem to wcześniej:

Och - ale haow !? JAKA zwykły śmiertelny człowiek, taki jak ja, wpatruje się w moje oczy w przeznaczenie takich rzeczy! Rzeczy, które tylko bogowie mogą bosko i bezpośrednio kierować. Rzeczy, które śmiertelni ludzie mogą marzyć tylko w najgłębszych snach i zapomnieć o świcie! Och, tyraniczne typy menedżerskie, JAK można spełnić takie wymagania !?

Wykorzystaj swoje wcześniejsze wyniki jako przewodnik i bądź szczery .

• Przeprowadzaj wystarczającą rozmowę z interesariuszem i / lub użytkownikiem końcowym, aby określić stopień złożoności produktu i / lub jego głównych komponentów w stosunku do innych głównych komponentów, nad którymi pracowałeś. Dokonaj wstępnego oszacowania punktu względnego.
• Napełnij tę liczbę historyczną wielkością zmiany zasięgu i opadem błędów, które wcześniej widziałeś.
• Zastosuj swoją historyczną prędkość do oszacowania punktu, aby dotrzeć do przybliżonej osi czasu. I zastosuj rozsądny stożek niepewności .
• Ponownie sprawdź swoje oszacowanie i zrozumienie projektu. Bądź pewien, że na podstawie swojej oceny zechcesz podjąć decyzję o realizacji projektu.

Na koniec zaprezentuj interesariuszom swój stożek niepewności, przedstaw swoje założenia i obawy, i zostaw to przy tym.

Na marginesie, proponuję również zaproponowanie heurystycznego obiektywnego oszacowania punktowego w celu sprawdzenia zdrowia psychicznego ciebie i / lub normalnych szacunków twojego zespołu.

Możesz użyć tego oszacowania jako N-tego głosu podczas planowania pokera lub w celu weryfikacji swojego prywatnego oszacowania, jeśli grasz solo. Na przykład, mój zespół ma tendencję do oszacowania o 1 punkt za minutę odkryć luźno techniczną dyskusję o historii. Jest to szczególnie pomocne, jeśli twoje jelita mówią ci, że historia ma 5 punktów, ale zajęło ci 20 minut, aby zrozumieć, co należy zrobić - zwykle jest to dobry wskaźnik, że wciąż czają się złożone i nieporozumienia.

Nigdy nie pracowałem w żadnej firmie, która byłaby w stanie zawsze mieć dobre prognozy czasu, ani też nigdy nie pracowałem z nikim, kto twierdzi, że to zrobił. Wyszukiwanie pokaże, że oszacowanie jest nierozwiązanym problemem w branży.

Spróbowałbym się przekonać o pomiarze prędkości w oparciu o abstrakcyjne punkty historii, a jeśli nie możesz tego zrobić, podałbym więcej twoich szacunków.

Zwinne jest doskonałym rozwiązaniem dla całego szeregu problemów, ale pomimo tego, co sugerują niektórzy ewangelicy, nie jest to jedyne rozwiązanie i nie zawsze jest to właściwe rozwiązanie.

Podany przypadek nie jest po prostu zwinnym problemem:

Niedawno miałem za zadanie omijać zespoły i prosić ich o pomysły dotyczące procesów biznesowych do automatyzacji. Miałem wtedy dowiedzieć się, ile czasu to zabierało, dowiedzieć się, ile czasu zaoszczędziłoby rozwiązanie i oszacować całkowity czas programowania. W ten sposób menedżerowie mogliby zmierzyć skuteczność rozwiązania pod względem zaoszczędzonego czasu.

Twoim zadaniem jest określenie kosztów i korzyści z automatyzacji niektórych procesów biznesowych, co nie jest sprawnym zadaniem podlegającym zmianom, jest to specyficzny problem z konkretnym rozwiązaniem. Stworzysz listę z dowolną liczbą procesów biznesowych, a dla każdego z nich będzie oszacowany koszt automatyzacji, szacowany koszt braku automatyzacji i szacowana korzyść automatyzacji. Kierownictwo dopasuje to do swoich budżetów, zasobów, wymagań i celów strategicznych i określi, które (jeśli w ogóle) z tych procesów zautomatyzować. Jeśli jesteś sumienny, wyróżnisz wybrane zadania, które same w sobie mogą potencjalnie obniżyć ROI, ale które obniżą koszty innych faz, poprawiając całkowity ROI. Możliwe, że zidentyfikowałeś różne sposoby osiągnięcia automatyzacji, w tym rozwój wewnętrzny i outsourcingowy na zamówienie (przy użyciu technik zwinnych i / lub wodospadowych), kupowanie gotowych rozwiązań, korzystanie z zewnętrznych dostawców usług i tak dalej. Cały ten proces był bardzo modny w latach 90., kiedy był znany jako przeprojektowanie procesów biznesowych.