Organizacja publiczna poprosiła mnie o nieformalne warsztaty na temat 101 zwinnego rozwoju, wyjaśniające warunki i koncepcje Scrum, Kanban i tym podobne. Pracuję w zwinnym środowisku od około pięciu lat, ale nie uważam się za ewangelistę Scruma.

Po warsztatach spodobał im się ten pomysł. Wyjaśnili jednak, że to podejście prawdopodobnie nie miałoby do nich zastosowania, ponieważ muszą zlecić zewnętrznym firmom programistycznym opracowanie oprogramowania dla nich (sami mają niewielu programistów). To działanie należy wykonać w drodze przetargu publicznego, który opisuje wynik, cenę i ramy czasowe. Jest to prawny wymóg ubiegania się o budżet dla tej organizacji (publicznego instytutu badawczego).

Ograniczenia te wydają się nieco sprzeczne z podstawowymi zasadami sprawnego rozwoju, prawda?

Czy Scrum jest po prostu niekompatybilny w takim środowisku?

Co poleciłbyś tej organizacji?

Scrum prawdopodobnie nie jest odpowiedni dla tej organizacji.

W Przewodniku Scrum „Scrum stanowi środowisko do opracowywania, dostarczania i utrzymywania złożonych produktów”. Jest również przeznaczony dla zespołu 3-9 członków zespołu programistycznego pracującego nad produktem, właściciela produktu i Scrum Master (który może, ale nie musi być w zespole programistycznym), w sumie 4-11 osób.

Jeśli chodzi o wewnętrzny rozwój, wspominasz, że mają tylko kilku programistów. Jeśli nie ma wystarczająco dużego zespołu, aby utworzyć Zespół Scrumowy, nie ma sensu korzystać z całego Scruma. Jednak niektóre praktyki Scruma mogą być przydatne dla organizacji.

W przypadku zakontraktowanego rozwoju jedna ze stron zewnętrznych może korzystać ze Scruma. W takim przypadku przydatne jest, aby instytut badawczy wiedział o praktykach Scrum i zrozumiał role i sposób działania. Być może nadal będą musieli zrozumieć, w jaki sposób zewnętrzna organizacja programistyczna stosuje praktyki Scrum, a także inne praktyki, ale może to pomóc im zrozumieć, jak to działa. Na przykład zrozumienie potrzeby udziału w recenzjach sprintu lub współpracy z organizacją (prawdopodobnie ich właścicielem produktu) przy zamawianiu rejestru produktów.

18F, agencja usług cyfrowych w rządzie USA, wykonała wiele pracy nad tym, jak rząd może pisać umowy, aby umożliwić stosowanie zwinnych metodologii w sposób zgodny z prawem, określając ogólne wyniki, a nie szczegółowe wymagania dotyczące sposobu pracy ma być zrobione. Niektóre z ich zasobów obejmują:

• Poprawa wyników rządów dzięki zwinnemu formatowi umów
• Umowa zakupu zwinnego koca
• Modułowe kontraktowanie (dzielenie dużych projektów na mniejsze modułowe z elastycznym rozwojem)
• Czy twój projekt używa „agilefall”?

Zaletą zwinnych metod pracy jest to, że koncentrują się one na znalezieniu rozwiązania problemu po udzieleniu zamówienia, to znaczy podczas realizacji po udzieleniu zamówienia, zamiast na szczegółowym rozwiązywaniu problemu z góry, jak w części 15. Zwinna umowa próbuje określać problemy wymagające szczegółowych rozwiązań, często jako pozycje Backlogu Produktu, które opisują obszary realizacji kontraktów na wysokim poziomie.

Rozumiejąc ten problem, Urząd Zarządzania i Budżetu oraz Urząd Federalnej Polityki Zamówień nakazały agencjom zaprzestanie korzystania z SOW i przejście do korzystania z Oświadczenia o wydajności (PWS) w celu nabycia usług. PWS „powinien określać ogólne wymagania dotyczące tego, co (wynik) ma zostać wykonane, a nie jak (metoda) jest wykonywana”. Dobrzy oficerowie kontraktowi doradzają agencjom, że kupując usługi eksperckie, oznacza to, że nie masz największej wiedzy w „jak” wykonywana jest praca. Jako właściciel misji jesteś ekspertem w tym, „co” trzeba osiągnąć, ale połączenie tych dwóch narazi twoją misję na ryzyko i utrudni kontraktowi dostarczenie wartości.

Zasadniczo podejście to bardziej przypomina zatrudnienie usługodawcy do współpracy z tobą w celu zaprojektowania rozwiązania, zamiast wcześniejszego wyświetlania stron ze szczegółowymi specyfikacjami. Instytucja nie zatrudniłaby architekta do zaprojektowania nowego budynku, wymieniając „projekt musi składać się z czterech kondygnacji, z nachyleniem dachu 37º. Trzecie piętro musi mieć kuchnię o powierzchni 237 m2 z czterema fluorescencyjnymi oprawami oświetleniowymi, sterowanymi ruchem -czuły włącznik światła w suficie podsufitowym. ” Zamiast tego mieliby umowę na architekta na świadczenie usług projektowych w porozumieniu z klientem i poleganie na ich dostawcy, ekspercie w tej dziedzinie, w celu wytworzenia rezultatów.

Chociaż szczegóły będą zależeć od instytucji i obowiązujących przepisów dotyczących zamówień publicznych i przepisów, to pokazuje, że wśród wszystkich niepowodzeń dużych rządowych projektów informatycznych istnieją grupy pracujące nad przesunięciem przetargów publicznych na rozwój oprogramowania na bardziej nowoczesne metodyki zwinne, mając wystarczającą wolę polityczną i godnych zaufania partnerów na rzecz rozwoju. To wymaga znacznej zmiany w sposobie opracowywania i zarządzania takimi projektami (w tym wiele ciągłego czasu dostarczania informacji zwrotnych od użytkowników w trakcie całego procesu), które organizacja może, ale nie musi być zainteresowana realizacją.

Brzmi typowo. Po napisaniu oferty, oferty są złożone, a jeden ze konkurentów otrzymał umowę ... w przypadku przedstawicieli organizacji publicznej projekt jest zakończony.

Dlatego wiele z tych projektów kończy się niepowodzeniem. Po przekroczeniu budżetu.

Chodzi o to, że brakuje im (lub przynajmniej nie uważają, że to ich obawa), że są interesariuszami, którzy powinni uczestniczyć w spotkaniach i pokazach.

Więc nie ma żadnego konfliktu z Agile ani Scrumem. Ludzie nie podnoszą swoich ról. Powoduje to sposób działania rządu.

To nie jest tak, że „chcielibyśmy mieć ten system i jesteśmy gotowi włożyć w to trochę wysiłku i przekonać się, jak daleko możemy go zabrać”.

Nie. To tak, jakby „nasza demokracja zdecydowała, że ​​do tego czasu będziemy mieć ten system”. Co nie pozostawia miejsca między 100% sukcesem z jednej strony a 100% porażką z drugiej. Skazane na śmierć od samego początku.

To także zaproszenie na rynek z prośbą o śmieszne stawki. Realizacja projektu, ponieważ jest zbyt kosztowny, nie wchodzi w grę, decyzja o jego podjęciu została podjęta przed napisaniem oferty.

W porządku, nawet jeśli interesariusze przejmie swoje role, byliby całkowicie bezsilni. Żaden z nich nie miałby wiarygodnego kija, aby wziąć udział w tych demonstracjach z tego samego powodu.

Nie, SCRUM nie jest niezgodny z przetargami publicznymi. Musisz wyraźnie określić, co kupujesz w przetargu publicznym.

„Nabywca chce kupić 10 2-tygodniowych sprintów deweloperskich, od doświadczonego zespołu SCRUM zawierającego 5 programistów i certyfikowanego mistrza SCRUM (nabywca wypełni rolę Interesariuszy). Sprinty potrwają od marca 2018 r. Do lipca 2018 r.” początek przetargu. Będziesz oczywiście musiał wymienić niezbędne umiejętności zespołu i dać pomysł na projekt, nad którym będą pracować, ale przyjęcie oferty jest całkowicie dopuszczalne.

Oczywiście rezygnujesz z „ustalonego zakresu” tutaj. W końcu jest to typowe dla SCRUM. Mając nieco więcej sformułowań w ofercie (ale wchodzimy tutaj na legalny obszar), możesz zezwolić na niewielkie rozszerzenie zakresu, tj. Niewielką liczbę dodatkowych sprintów. Ale jeśli zdecydujesz się na dodatkowe 10 sprintu po pierwszych 10 sprintach, prawdopodobnie będziesz musiał ponownie złożyć ofertę.

To jest trudne.

Oczywiście nie można licytować pracy z otwartym budżetem. Musisz więc spojrzeć na to, co trzeba zrobić i ile wysiłku potrzeba, aby to zrobić.

Powodem niepowodzenia wielu projektów oprogramowania jest fakt, że naprawa, czas, wysiłek i zakres z góry są bardzo podatne na błędy. Na przykład specyfikacja podana w ofercie prawie zawsze będzie miała dwuznaczność.

Jest więc podstawowa kwestia nie tylko zwinności, ale także koncepcji otwartych przetargów na rozwój oprogramowania. Szanse na to, że ktoś pójdzie i stworzy dokładnie to, czego chciałeś w określonym czasie, są niskie.

Jeśli pozwolisz na pewną elastyczność, możesz to poprawić.

Wygląda na to, że proces przetargowy nie jest elastyczny. Jednak po wygraniu kontraktu może się okazać, że jest miejsce na zawijanie. Możesz na przykład zezwolić na sprawną pracę, ale musisz zaakceptować (i uzyskać legalną zgodę), że może to wpłynąć na zakres.

Teraz uważam, że dzięki temu uzyskasz lepszy produkt, ponieważ zobaczysz, co się dzieje wcześnie i wprowadzisz zmiany, zanim zostaną one upieczone w produkcie. Ścisłe pętle informacji zwrotnych i iteracyjny rozwój mogą sprawić, że produkty będą lepiej dopasowane do faktycznych wymagań (które mogą, ale nie muszą, być przedmiotem przetargu).

To zależy, ale prawdopodobnie tak.

Jestem gotów postawić pieniądze, że każdy, kto kiedykolwiek współpracował z jakimkolwiek rządem przy jakimkolwiek projekcie związanym z IT, będzie wiedział, że w praktyce „twarde limity” opisane w przetargu nigdy nie są spełnione. Rzeczy mają tendencję do przekraczania budżetu, opóźniania się i / lub zmiany zakresu. Zwykle jest ich wiele. Jeśli rządy chętnie przyznają, że taka jest prawda i chcą traktować je jak wytyczne, to scrum może naprawdę dobrze działać.

Z własnego doświadczenia (zarówno własnego, jak i mojej sieci zawodowej) wiem, że wymagania zmieniają się często w większości projektów rządowych. Odpowiedzialne komitety mają również wiele informacji zwrotnych, kiedy w końcu angażują się pod koniec projektu. Są to problemy, dla których Scrum jest odpowiedni.

Wymagałoby to jednak fundamentalnej zmiany sposobu myślenia ze strony rządów i ich agencji. W większości krajów, jest bardzo mało prawdopodobne, że ta zmiana będzie kiedykolwiek nastąpi. Do tego czasu przetargi publiczne będą nadal niezgodne z pracą ze Scrumem. (Zresztą, moim osobistym zdaniem przetargi publiczne będą nadal niezgodne z jakichkolwiek praktyk zrównoważonego rozwoju oprogramowania, ale to już inna sprawa na inny czas ...)

Co poleciłbyś tej organizacji?

W tym momencie nic.

Brakuje tutaj historii o tym, jakie problemy powoduje ich obecny proces. Scrum nie jest czymś, co można ślepo polecić. Ma rację. To nie jest jeden rozmiar dla wszystkich.

Zapytaj ich, jakie problemy spowodował ich obecny proces. Słuchać. Zalecaj tylko metody, które rozwiązują ich prawdziwe problemy. Będą stronniczy w stosunku do obecnego procesu. Nauczyciele mogą wydawać się, że dyktują proces rozwoju, ale tak nie jest. Decydują o procesie dostawy. Ale to jest różnica, której ten zespół prawdopodobnie nigdy wcześniej nie musiał robić.

Zwinność działa najlepiej, gdy wymagania zmieniają się o ponad 3% w trakcie trwania projektu. W przeciwnym razie wodospad jest nadal bardzo skuteczny. Jest nadal używany w wielu miejscach dzisiaj. I oczywiście wielu udanych programistów nigdy nie formalizuje swojego procesu w żaden sposób. Nieformalne działa dobrze, gdy trudne problemy mają charakter techniczny, a nie dotyczy ludzi.

Porozmawiaj z nimi na temat ich obecnego procesu i problemów, jakie on ma. Powiedz im, w czym pomagają te metody. Ale jeśli nie jest zepsute, nie naprawiaj tego.