Wyzwania dla zwinnego podejścia do projektów rządowych

Poprzednia dyskusja Agile tutaj miała dobre odpowiedzi określające, co jest kluczowe dla powodzenia wdrożenia metodologii Agile w tworzeniu oprogramowania. Większość punktów była typowymi wyzwaniami organizacyjnymi i zarządczymi, ale jeden punkt martwi mnie i to, że klient musi być zaangażowany w cały proces.

Klient jest jedyną rzeczą, której nie można realistycznie kontrolować, być może Twój model biznesowy przygotowuje Cię do pracy na zlecenie rządu, na przykład gdy bardzo ścisła umowa zobowiązuje firmę do:

• Zapewnij funkcje X dokładnie zgodnie z żądaniem

• Prośby o nowe funkcje zostaną rzucone na ścianę, nie przejmuj się, nie chcemy tego słyszeć.

• Klient nie ma pojęcia pierwszeństwa funkcji, wszystkie są ważne, bo nie prosilibyśmy o nie.

• Projekt będzie kosztował nie więcej i nie mniej niż Y, niezależnie od przekroczeń lub terminów.

• Bezwzględny, ścisły, ostateczny i niepodlegający negocjacjom termin pełnej realizacji wszystkich prac.

Nigdy wcześniej nie współpracowaliśmy z takim klientem, ale pieniądze na projekt są zbyt duże, aby je przepuścić. Potrzebujemy tej pracy.

Przybyłem tutaj i pracowałem ciężko, aby zmienić procesy wewnątrz, aby przejść do rozwoju Agile, a tutaj nie wiem, jak pogodzić, gdzie ten projekt pasuje do naszego nowego procesu. Nigdy wcześniej nie miałem luksusu otwartego zarządzania, które zaufało mi, że poprowadzę zespół programistów i procesy na tę ścieżkę, a teraz, kiedy tu jesteśmy, nie mogę szczerze powiedzieć sobie, że ten projekt naprawdę zostanie zrealizowany Zwinny sposób. Wydaje mi się, że kierownictwo zaufało mi, że poprowadzę tę ścieżkę, i zawiodłem ich, ponieważ sytuacja, w której jesteśmy teraz, tak wyraźnie wymaga Waterfall. Obawiam się, że jeśli stracę zaufanie, stracę ich zaufanie.

Inne odpowiedzi, takie jak ta , mówią , że zwinność jest niemożliwa w przypadku tego rodzaju klienta, zgadzasz się? Czy któryś z was był w podobnej sytuacji i sprawił, że działał? Jakie strategie wdrożyłeś, aby Agile się powiodło?

Myślę, że pierwszą rzeczą do zrozumienia jest to, że istnieje różnica między byciem Zwinnym a byciem Zwinnym. Powolne wdrażanie zwinnych technik i cech - zespoły interdyscyplinarne, planowanie adaptacyjne, ewolucyjne / przyrostowe dostarczanie, iteracje z ograniczeniami czasowymi, a nawet wprowadzanie koncepcji Lean są bardzo różne niż wprowadzanie Extreme Programming, Scrum lub Crystal.

Wyraźnie wspominasz o zaangażowaniu klienta. Tak, wiele metodologii zwinnych wymaga zaangażowania klienta, ale nie musi to być zwinne. W każdym programie związanym z rządem / obroną zawsze miałem menedżera programu lub projektu, który był w kontakcie z klientem. Ta osoba staje się „głosem klienta”. Może to zostać spowolnione, gdy telekonferencja, e-mail lub zadzwoń i wyjaśnij, ale możesz mieć jedną osobę (lub grupę, jeśli masz również wicepremierzy), która jest przedstawicielem klienta Twojego zespołu. Trzeba przyznać, że to nie to samo. Ale czy nie jest zręczny w kwestii elastyczności i reagowania na zmiany?

Wspominasz także o kilku kluczowych pojęciach: predefiniowanych wymaganiach, zleceniach dotyczących funkcji „rzucanych ponad ścianę”, braku ustalania priorytetów, ponieważ „wszystkie są ważne” oraz projektach o stałych kosztach i / lub ustalonym harmonogramie. Każdą z nich można rozwiązać na różne sposoby.

Jeśli uważasz, że masz wszystkie wymagania z góry, prawdopodobnie nie. Wymagania się zmieniają. To, że masz specyfikację „zakończoną i wylogowaną”, nie oznacza, że ​​jest ustawiona na kamieniu. Biorąc pod uwagę posiadane dokumenty wymagań, uchwyć je, jak czujesz się komfortowo i / lub w sposób określony w umowie i dostarcz wymagania, projekt i architekturę. Ponadto sprawdź, czy możesz potraktować te żywe dokumenty (dokument projektu, który widziałem dziś w pracy, jest oznaczony jako Wersja G, co oznacza, że ​​jest na 8 aktualizacji). Zapytaj, ile możesz zostawić jako TBD w dowolnej iteracji i ile trzeba teraz wzmocnić - może być trochę dawania i przyjmowania.

Bądź zwinny dzięki swojej dokumentacji. Nie powielaj wysiłków między „tym, czego chce Twój zespół”, a „tym, czego chce klient”. Na przykład, jeśli Twój klient chce tradycyjnej specyfikacji wymagań oprogramowania, a Twój zespół chce korzystać z historii użytkowników, spróbuj dostosować się do tradycyjnego SRS i używać elementów akcji i listy elementów akcji kroczącej zamiast historii użytkowników, aby nie tracić czasu sformułowanie zarówno „system powinien ...”, jak i „musi być w stanie, ponieważ”. Wymaga to jednak dyscypliny ze strony zespołu, aby dostosować się do różnic między projektami. Uchwyć problemy w odbiciach.

Po przejściu do programowania możesz uruchomić 5 lub 6 iteracji, a następnie zaprosić klienta do swojego zakładu, aby zobaczył podzbiór wdrożenia. Opłucz i powtórz ten proces. Nie jest to ciągłe zaangażowanie wymagane przez niektóre metodologie, ale masz przewagę dzięki wysokiej widoczności. Jeśli Twój klient mówi „nie”, przynajmniej próbowałeś. Jeśli powiedzą tak, możesz oświecić ich zwinnością. Przy jednym projekcie, w którym byłem, klient odwiedzał witrynę co kilka miesięcy (zwykle 3-5 miesięcy). Obserwowali nas, jak przechodzimy testy jakości, rozmawiali o problemach z inżynierami, a biznes z biurem programu / projektu. Była to okazja dla wszystkich, aby dostać się na tę samą stronę.

Testy i konserwacja odbywają się tak samo, jak w innych zwinnych projektach. Twórz procedury testowe i dokumentuj defekty w odpowiedni sposób, śledź wskaźniki według zobowiązań umownych i dokumentuj wyniki testów. Jeśli chcesz śledzić TDD, idź do niego. Ciągła integracja to kolejny dobry pomysł. Podczas spotkań o statusie projektu kierownik projektu może użyć tych informacji, aby powiedzieć „wdrożyliśmy wymagania N, przeszliśmy testy M, testy X przeszliśmy” i zaktualizowaliśmy kondycję i status projektu osobom z pieniędzmi.

Mówiąc o pieniądzach, mamy problem kosztów stałych i / lub ustalonego harmonogramu.

Radzenie sobie z ustalonym harmonogramem jest dość proste. Biorąc pod uwagę swoje wymagania, wiesz, ile iteracji możesz wykonać. Twoje obciążenie pracą dla każdej iteracji jest ściśle określone pod względem funkcji do wdrożenia, testowania i integracji. Może to być trudne, ale nie jest niemożliwe rozbicie funkcji i przypisanie ich do iteracji z góry. To wraca do mojego punktu o zaproszeniu klienta - jeśli masz rok i korzystasz z 2-tygodniowych iteracji, być może zapraszaj klienta kwartalnie (i zapraszaj go co kwartał) i pokaż mu wyniki poprzedniej pracy. Niech zobaczą twoje priorytety wymagań, twoje plany na przyszłość i jak planujesz.

Postępowanie ze stałym budżetem jest podobne. Wiesz, ile masz czasu, ile zasobów masz na projekt, ile kosztują, a tym samym ile godzin każdy może przepracować na jedną iterację. Chodzi tylko o to, aby każdy dokładnie to śledził. Jeśli Twoja firma może zjeść koszt nadgodzin, idź na całość. W przeciwnym razie upewnij się, że wszyscy pracują przez odpowiedni czas, i używaj dobrych umiejętności zarządzania czasem i boksowania czasu, aby wszyscy byli produktywni. Potrzebne są bardziej produktywne godziny, aby obniżyć koszty - dostarczać dokumenty i oprogramowanie o wartości dodanej bez kosztów spotkań i kosztów ogólnych.

Ostatecznie niekoniecznie chodzi o bycie Zwinnym, ale o stosowanie rzeczy, które czynią Agile dobrym i zwinnym. Być w stanie reagować na zmiany wymagań, być w stanie dostarczać częste oprogramowanie, nawet jeśli klient tego nie chce, tylko tworzyć dokumentację o wartości dodanej (wraz z tym, co jest zobowiązane na mocy umowy) i tak dalej.

Tak, zwinność nie jest odpowiednia dla takiego projektu, ponieważ wygląda na to, że wymagania są już spełnione i osadzone w kamieniu, prawdopodobnie w wyniku lat analiz przeprowadzonych przez drogich konsultantów, spotkań komisji i kompromisu politycznego. Wodospad działa dobrze, jeśli klient jest tak zdyscyplinowany, że może powiedzieć Ci na piśmie dokładnie, czego chce. Mogą się mylić, ale przynajmniej masz to na piśmie, a otrzymasz wynagrodzenie, jeśli je dostarczysz. (To oczywiście nie mówi o zadowoleniu klienta. Możliwe, że dostarczysz coś, czego tak naprawdę nie potrzebują).

Zwinny został stworzony, aby rozwiązać problem, którego nie masz: ryzyko z powodu niepewności w wymaganiach.

To prawda, że ​​klient może poprosić o prośbę o zmianę, ale podążasz jedną z dwóch ścieżek:

1. Pieniądze były tak dobre, że wiesz, że możesz wchłonąć X nowych funkcji na różnych etapach projektu i nadal wychodzić bez utraty koszuli, lub
2. Na początku wyjaśnisz klientowi, że ze względu na negocjowanie ścisłej ceny, każde nowe żądanie funkcji wygeneruje zamówienie zmiany z ceną, która będzie musiała zostać przez niego zaakceptowana, wraz z towarzyszącym zamówieniem (lub zmianą oryginalne zamówienie) w celu jego realizacji. Zlecenie zmiany określi wpływ na funkcjonalność lub harmonogram. Jeśli powiedzą, że termin nie może zostać przesunięty, wówczas zmiany zamówień stają się wykładniczo droższe w miarę postępu projektu, ponieważ późniejsze zmiany są droższe.

Relacja wydaje się o wiele bardziej przyjazna w sytuacji nr 1, ale faktem jest, że rzadko zdarza się znaleźć działy zakupów, które nie będą cię kosztować, więc przez większość czasu jesteś w sytuacji nr 2. Oznacza to, że związek jest konfrontacyjny, ale jeśli chcesz przetrwać w biznesie, musisz być dobry w zarządzaniu związkiem, utrzymując swoją pozycję. To duża część pracy kierownika projektu.

Brzmi, jakbyś był w sytuacji nr 1, co jest dobre. Wyobrażam sobie, że kontrakty rządowe są jedynym miejscem, gdzie nie dba o pieniądze, bo przecież oni nie wydając swoje pieniądze, oni spędzają swoje pieniądze.

... praca na zlecenie rządu, na przykład gdy bardzo ścisła umowa zobowiązuje firmę do:

Pierwszy. To jest surowe. Ale to nie jest nieelastyczne. Po prostu wymaga dbałości o szczegóły i długiego, długiego ciągu zmian.

Agencje rządowe faktycznie są zwinne w powolny, nieefektywny sposób. Cały czas musisz pisać (i negocjować) formalne, szczegółowe zlecenia zmian.

Zapewnij funkcje X dokładnie zgodnie z żądaniem

Do czasu modyfikacji przez polecenie zmiany.

Prośby o nowe funkcje zostaną rzucone na ścianę, nie przejmuj się, nie chcemy tego słyszeć.

Kanał komunikacji to kolejność zmian. Wpływ na budżet i harmonogram.

Klient nie ma pojęcia pierwszeństwa funkcji, wszystkie są ważne, inaczej byśmy ich nie prosili.

Trudno to obejść. Nawet firmy pozarządowe, które wydają dużo pieniędzy na „analizę wymagań”, nie chcą powiedzieć, że duży, płaski, parujący stos wymagań nieobciążonych priorytetem i informacjami o kompromisie jest niepełny. Zapłacili dobre pieniądze, aby uzyskać wszystkie wymagania. Jak możesz uzyskać więcej informacji?

To trudny problem.

Projekt będzie kosztował nie więcej i nie mniej niż Y, niezależnie od przekroczeń lub terminów.

Z wyjątkiem zleceń zmiany. Które modyfikują Y i ostateczny termin.

Bezwzględny, ścisły, ostateczny i niepodlegający negocjacjom termin pełnej realizacji wszystkich prac.

„niezbywalny” zasadniczo nie jest prawdą. Jest do negocjacji. Negocjowanie jest po prostu bolesne.

Ważną częścią negocjacji z agencjami rządowymi jest fakt, że potrzebujesz „dowodów na poziomie prawnika” w celu zmiany kosztów i harmonogramu. Kilka uważnych prezentacji technicznych z ładnym slajdem power-point nie jest „dowodem”. Potrzebujesz dużo dokumentacji, aby uzasadnić swoją sprawę.

Ludzie z rządu muszą przedstawić niezbite dowody, że zrobili wszystko, co w ich mocy, aby uczynić to tak tanim i skutecznym, jak to możliwe. Wiedzą, że każda decyzja jest odtwarzana w prasie publicznej i analizowana z perspektywy czasu.

Złożoność opracowywania oprogramowania i późniejszy aspekt „rządowego rozgrywającego w poniedziałek rano” sprawiają, że niechętnie wprowadzają zmiany w umowie bez przytłaczających dowodów.

Utrudnia to prawidłowe podejście Agile.

„Osoby i interakcje między procesami i narzędziami” są trudne. Nie pracujesz z osobą, ale przedstawicielem rządu, którego praca jest ograniczona przez proces.

W takim projekcie związali ręce z zasięgiem, zasobami i czasem. Jedyną rzeczą, którą musisz zarządzać, jest jakość. Więc...

Nie będziesz czerpać większości korzyści z elastycznego podejścia, które w przeciwnym razie możesz zrobić, ale możesz zrobić wszystko, aby zmniejszyć ryzyko związane z jakością i być w stanie poinformować klienta o problemach wcześniej niż później.

Bądź więc tak zwinny, jak tylko możesz:

1. Przejrzyj wymagania i uszereguj je pod względem ryzyka technicznego. Ustaw priorytety jako swoje zaległości.
2. Przepracuj zaległości w sprintach - projektuj, testuj i koduj funkcje sprintu. Brakuje interakcji klienta, więc dokument wymagań musi reprezentować klienta dla tego działania.
3. Zaproś klienta do każdej recenzji sprintu - może powiedzieć „nie”, ale może powiedzieć „tak”. Otrzymasz informację zwrotną wcześniej niż później.

Jeśli zaczniesz biec przed upływem terminu, będziesz w stanie pokazać, co się stało, i być może w tym momencie klient, wiedząc, że nie dostanie wszystkiego, ustali na tyle priorytetu, by powiedzieć ci, czego chce. Powinieneś również wykonać najbardziej ryzykowne rzeczy, co oznacza, że ​​zadania w terminie są najłatwiejsze do wykonania w dodatkowych godzinach.

Myślę, że ten typ klienta nie jest normą. Masz do czynienia z grupą, która wcześniej prosiła o podobne projekty, więc wiedzą dokładnie, czego chcą. Nigdy nie wspominasz, że ich specyfikacje się zmienią.

Zapewnij funkcje X dokładnie zgodnie z żądaniem

Mam szczęście, jeśli podam ogólną funkcję X zgodnie z sugestią i jestem gotów ją zmienić w krótkim czasie.

Prośby o nowe funkcje zostaną rzucone na ścianę, nie przejmuj się, nie chcemy tego słyszeć.

Jeśli wiesz, czego chcą, idź i zbuduj to.

Klient nie ma pojęcia pierwszeństwa funkcji, wszystkie są ważne, inaczej byśmy ich nie prosili.

Nie możesz na tym stracić. Zbuduj je według własnego uznania.

Projekt będzie kosztował nie więcej i nie mniej niż Y, niezależnie od przekroczeń lub terminów. Bezwzględny, ścisły, ostateczny i niepodlegający negocjacjom termin pełnej realizacji wszystkich prac.

To trudne, jeśli nigdy nie zbudowałeś projektu dla rządu. Jeśli masz trochę historii, możesz być w stanie ustalić, czy możesz dostarczyć. Nie oznacza to, że nie płacą dobrze (są znani z płacenia 50 USD za młot 10 USD) lub mają nieuzasadnione oczekiwania. Dzięki tym specyfikacjom ktoś w Twoim zespole powinien działać jako klient i zatwierdzać pracę w porównaniu do specyfikacji. Nawet jeśli znalazłeś wadę i błagałeś ich o zmianę wymagań, prawdopodobnie nie zrobiliby tego.

Niestety to, co opisałeś, to typowy pogląd klienta na to, jak należy zająć się projektem oprogramowania. Nie oznacza to, że klient jest nierozsądny; w końcu - czy nie w ten sposób wykonano by budowę czegokolwiek innego (na przykład domu?). Biorąc to jednak pod uwagę, tak naprawdę nie oferuję nic więcej niż to, co wszyscy już wiemy. Pytasz tylko ... czy w tej sytuacji jest możliwe zastosowanie zwinnych praktyk?

Mam tę zaletę, że właśnie ukończyłem projekt, który pod wieloma względami jest podobny do opisanej przez ciebie sytuacji, tj.

1. Naprawiono (w kamieniu, przyszedł piekło lub woda) termin.
2. Dokument wymagań funkcjonalnych („biblia”). Nie jest zaskakująco nieodpowiednie.
3. Tradycyjne role: Project Manager, Business Analyst.
4. Słabo zaangażowani użytkownicy biznesowi (czy możesz powiedzieć „bez sponsora produktu”?).

... i oczywiście przyszłościowy zespół programistów stara się działać zwinnie, pomimo powyższego:

1. 2 tygodnie iteracji;
2. Stand-upy;
3. Retrospektywy;
4. Programowanie w parach;
5. TDD;
6. Ciągła integracja.

Czy coś z tego ma jednak znaczenie dla biznesu? Nie. Dwa miesiące przed upływem terminu, uważnie obserwowane iteracje i spotkania planistyczne zostały porzucone w szale bezgłowego kurczaka.

Odpowiedzi udzielone przez innych powyżej są w większym lub mniejszym stopniu kompromisem. Moim zdaniem zwinny (czy „zwinny” czy „zwinny”) jest „szkodliwy”, gdy idziemy na kompromis. W mojej opinii:

Nie ma kompromisu lub nie ma zwinności.

Sam duch zwinności polega na podchodzeniu do pościgu, usuwaniu odpadów, byciu brutalnie uczciwym wobec siebie. Jest to obecnie dobrze udokumentowany i niezaprzeczalny fakt, że szacowanie oprogramowania w dużych projektach jest w najlepszym razie ryzykowne. Czy edukowanie potencjalnych klientów tego nie jest naszym obowiązkiem jako programistów? Jeśli klienci nie chcą zaakceptować faktu, że jesteśmy ekspertami, to czy nie naszym obowiązkiem zawodowym jest odejść?

Kiedy zacząłem pracować tam, gdzie teraz jestem, zadałem sobie to samo pytanie, które zadałeś dość często. Jest coś, co można powiedzieć o wodospadzie z kontraktami rządowymi. Jak na ironię, zwinny stał się obecnie modnym słowem wśród klientów rządowych (którzy realistycznie pracują w sposób wodospadowy), więc teraz pozostaje nam jeszcze trudniej wdrożyć zwinny proces z zasadniczo nieelastycznym klientem.

Mamy system, który został opisany jako „Scrummerfall” „Agilefall” lub „Bałagan”, ale pod wieloma względami powoli byliśmy w stanie przyjąć coraz bardziej zwinny proces, ponieważ ten (gigantyczny) projekt rozwijał się z biegiem lat . Jednym ze sposobów, w jaki to zrobiliśmy, jest po prostu znalezienie tylnych kanałów komunikacji z UŻYTKOWNIKAMI naszego systemu, w przeciwieństwie do naszych KLIENTÓW. Nasi klienci to duszny dział kierowany przez wyznaczonych urzędników, którzy nigdy nie będą dotykać naszego oprogramowania w życiu zawodowym i nie chcą go zrozumieć. Nasi użytkownicy to stały personel rządowy w terenie, który próbuje wykonać ważne zadanie. Dla nas kluczem do ustanowienia pętli komunikacji zwrotnej, która pozwoliła nam być tak zwinnym jak my, była konieczność UAT (Testy Akceptacji Użytkownika).

Na wczesnym etapie naszego projektu zdecydowano, że reprezentatywna grupa RZECZYWISTYCH UŻYTKOWNIKÓW z różnych biur naszego ogromnego klienta rządowego zostanie zebrana na miejscu TUTAJ i będziemy mieli z nimi kilka tygodni przerwy na przeglądanie, przeglądając serię testuj skrypty, aby przetestować nasze oprogramowanie. Nieformalnie zespół wymagań zmienił ten czas w bezcenny sposób na uzyskanie informacji zwrotnych od rzeczywistych użytkowników końcowych. Tymczasem zespół testowy UAT w rządzie pracował nad swoją biurokracją, aby mieć coraz większy wpływ na formalny proces wymagań po ich stronie, w tym zlecenia zmian. Efektem końcowym jest to, że licencjobiorcy tacy jak ja działają jako właściciele produktów stand-in w zespołach scrum i są w stanie uzyskać nieoceniony kontakt twarzą w twarz z prawdziwymi klientami, co pozwala nam działać w bardzo zwinny sposób.

Oczywiście jest wiele problemów i wciąż nie jesteśmy tak zwinni, ale jesteśmy wystarczająco zwinni, aby zostać potraktowanym jako przykład dużego projektu zwinnego, w rzeczywistości wykorzystującego tę metodologię w rządowym sektorze kontraktowym.

Podsumowując: wykorzystaj swoje doświadczenie jako zwinny ewangelista we własnej organizacji, aby infiltrować klienta. Przejdź z nimi proces uczenia się, nawiąż partnerstwo oparte na zaufaniu z kluczowymi ludźmi po ich stronie i pracuj WOKÓŁ formalnego, skostniałego procesu wymagań, który nieuchronnie mają. Podziękują ci faceci na ziemi, którzy muszą faktycznie wykorzystać to, co rozwijacie!

Zakładasz, że wymagania są dobrze napisane i uważasz, że mają na myśli to, co myślą. W przód i w tył zwinny proces pomoże upewnić się, że otrzymują to, co mieli na myśli oprócz tego, o co prosili.