Jak działa zwinny podczas wymiany działającego systemu?

W idealnym świecie zwinnym szybko budujesz mały, ale użyteczny podzbiór pożądanego systemu końcowego i przekazujesz go użytkownikom. Są podekscytowani, ponieważ jest to użyteczne, zaczynają go używać i wyrażają opinie. Następnie zastanawiasz się, co dodać, budujesz i powtarzasz, aż zabraknie czasu.

Niedawno miałem kilka projektów, które wymagały wymiany jakiegoś działającego systemu. Powyższy model po prostu w ogóle nie działał: dopóki nie zbudowałeś systemu, który obejmowałby praktycznie całą funkcjonalność istniejącego systemu, użytkownicy w ogóle nie byli zainteresowani. Nie użyliby tego.

Jak zastosować Agile, gdy „najmniejszy użyteczny podzbiór” to „wszystko”?

Zwinnym rozwiązaniem może nie być zamiana wszystkich za jednym razem, ale stopniowe wprowadzanie zamiany.

Wprowadzaj nowy system stopniowo, krok po kroku, utrzymując działanie części starego systemu. Stary system nie jest wyłączany za jednym razem, po prostu zanika. Nowe części zapewniają nową funkcjonalność lub inne korzyści, więc użytkownicy z przyjemnością z nich korzystają. Jest to również mniej ryzykowne, ponieważ masz w 100% działający system przez cały czas.

• Przeczytaj więcej od Martina Fowlera .
• Przydatne mogą być strategie w Michael Feather's Efektywna praca ze starszym kodem

Zamiast przepisywać istniejący system (który, jak wspomniałeś, zajmie sporo wysiłku, zanim nowy system dopasuje się do istniejącej funkcjonalności), zastanów się nad duszącym podejściem do winorośli . Zasadniczo wdrażasz nową funkcjonalność, stosując nowe podejście w stosunku do istniejącej aplikacji. W końcu, gdy usuniesz niedociągnięcia starego systemu, aby zająć się nową funkcjonalnością, nowy kod całkowicie zastąpi stary.

Wymaga to większej precyzji i wysiłku niż „ponowne uruchomienie” starej aplikacji. Ale masz krótszy czas na ROI. Ponadto, przechodząc przez ten proces, możesz założyć haczyki, aby łatwiej „udusić” nowy system przez kolejny „nowy” system.

Uwolnienie małych przyrostów na świecie może działać dla projektów typu greenfield, ale nawet wtedy niewielka liczba funkcji może nie być zbyt przydatna.

Scrum zaleca, aby po każdym sprincie produkt był „potencjalnie nadający się do wysyłki”. Nie musi być wysyłany, ale musi mieć jakość produktu nadającego się do wysyłki.

Jeśli chcesz udostępnić użytkownikom wersję przyrostową aplikacji, możesz ją sklasyfikować jako Alpha, a następnie Beta, a następnie wydać wersje Candidate, wciąż mając nadal używaną prawdziwą aplikację produkcyjną.

Może się okazać, że nowe funkcje zostaną dodane, a stare zostaną usunięte, jeśli uwzględnisz opinie użytkowników.

Pracowałem nad ogromną linią zastępującą aplikacje biznesowe dla dużej krajowej sieci telewizji kablowej. Opracowanie nowego systemu odbyło się za pomocą SCRUM, około 18–24-miesięczny projekt rozwojowy polegał na ponownym wdrożeniu prawie wszystkich głównych podsystemów; które zbliżały się do 10 lat.

Przed rozpoczęciem prac rozwojowych była faza planowania, która trwała około 6 miesięcy, ale do SCRUM doszło również. W tym miejscu właściciel produktu napisał sklepy i epopeje na wysokim poziomie po analizie systemu i przeprowadzeniu wywiadów z klientami.

Istniejący system był wyjątkowo stabilny, ponieważ przeszedł w tryb konserwacji krytycznej; naprawiono tylko problemy z zatrzymywaniem pokazu, wszystko po prostu rejestrowano do celów historycznych i aby upewnić się, że te same problemy nie pojawiły się w nowym systemie.

Nowy system ewoluował zgodnie z opisem w procesie zwinnym, w większości był wyjątkowo gładki. Kiedy system zamienny osiągnął część funkcji, nie wszedł do produkcji, lecz do równoległych prób produkcyjnych. Podzbiór niekrytycznych pracowników zaczął korzystać z obu systemów, aby sprawdzić, czy nowy system zachowuje się jak stary; z poprawionymi starymi błędami.

Gdy nowy system uzyskał prawie 100% nowych funkcji, został wdrożony do ogólnych równoległych serii produkcyjnych, które trwały kilka miesięcy.

Kiedy klient uznał, że spełnia ich potrzeby, utworzono kopię zapasową starego systemu, wyłączono go i usiadł. Zakładam, że zmienili przeznaczenie starego sprzętu systemowego, ponieważ nigdy nie musieli wracać do starego systemu po odcięciu.

Nadal uważam, że zwinny dodaje wiele wartości w tym scenariuszu.

Po prostu masz bardzo określony cel końcowy: „zastąpić obecny system”.

Zwinne techniki i procesy mogą jeszcze skuteczniej Cię tam osiągnąć .

Na przykład:

Nadal możesz dostarczać system iteracyjnie i w małych sprintach.

Nadal możesz używać zwinnych technik, aby nadać priorytet pracy po komunikowaniu się z kluczowymi osobami.

Nadal możesz używać zwinnego planowania na podstawie obserwowanej prędkości.

Nadal możesz korzystać ze zwinnych technik i filozofii, takich jak rozpowszechnianie wiedzy, TDD, czyste kodowanie, aby poprawić jakość i wewnętrzny projekt projektu.

Jeśli masz ludzi, którzy są naprawdę „nie zainteresowani” projektem i nie angażują się w projekt, dopóki nie znajdą idealnego zastępcy, masz większy problem, niezależnie od tego, czy używasz wodospadu, zwinności, czy w ogóle jakiegokolwiek procesu.

Działa tak samo, ale trudniej będzie sprzedać to podejście istniejącym użytkownikom. Mogą nie chcieć nowego systemu i nie chcą przeszkadzać w okresowych testach. Chcą czekać tak długo, jak to możliwe, a następnie po prostu przetestować to na końcu. Większość użytkowników czuje się w ten sposób do pewnego stopnia, ale edukowanie ich zależy od osób odpowiedzialnych. Ich zdaniem pracujesz z istniejącą aplikacją, więc powinieneś wiedzieć, co powinien zrobić, po co im to przeszkadzać?

Niech zrozumieją, że nie chcesz tego robić w ten sposób, ponieważ myślisz, że będzie fajnie i poczujesz się samotny, korzystając z procesu wodospadu. W dłuższej perspektywie sprawi, że będzie to lepsza aplikacja.

Kluczowym punktem sprzedaży może być wdrożenie tej jednej zmiany podczas tworzenia nowej aplikacji, której zawsze chcieli, ale nigdy nie mogliby dostać się do starego systemu.

Jeśli mam stary zardzewiały samochód, którym muszę jechać, aby dostać się do pracy, i idę do dealera, aby kupić nowy samochód. Model, którego chcę, jest niedostępny, więc muszą go zamówić w fabryce i minie trochę czasu, zanim się pojawi.

Dealer następnie w dobrej wierze decyduje się dać ci blok silnika samochodu, dopóki nie pojawi się zamówiony samochód. Co powinieneś zrobić z silnikiem samochodowym? Pewnie, że mogę podłączyć niektóre elementy, aby go przetestować i sprawić, by działało, ale tak naprawdę nie pomaga mi jutro pracować tam, gdzie robi to stary zardzewiały samochód.

To prawda, że znacznie różni się od budowania samochodu od niestandardowego oprogramowania, ale zignorujmy to ze względu na argument. Nie można się dziwić, że klient nie znajduje pożytku z przyrostowymi zmianami, gdy ma już oprogramowanie, które jest wystarczająco dobre, aby wykonać zadanie teraz. Na razie zaspokaja to ich potrzebę.

Nie oznacza to, że Agile nie jest tutaj ważną częścią procesu, ponieważ pozwala na ciągłą informację zwrotną dla klienta na temat statusu projektu. Mogą zapewnić, że poczyniono postępy przed ważnymi etapami i rezultatami. Mogą wcześniej zidentyfikować potencjalne problemy i problemy, zanim błąd stanie się zbyt kosztowny.

Być może jako klient samochodu chcesz tylko spojrzeć i ocenić silnik, aby upewnić się, że rzeczywiście dostaniesz to, czego się spodziewałeś. Ups, tak naprawdę chciałem 6-cylindrowy silnik zamiast 4-cylindrowego silnika! Nie mówiłem ci tego wcześniej? Nie ma problemu, wprowadźmy zmianę w zamówieniu fabrycznym.

Sprzedaj klientom pomysł, że w ich najlepszym interesie jest korzystanie z nowych wersji oprogramowania nie jako zamiennik, ale ich ocena i upewnienie się, że są zadowoleni z każdego kroku.