Refaktoryzacja w rozwoju Agile
W projekcie tworzenia aplikacji pełny zakres projektu nie został uwzględniony w projekcie aplikacji. Dlatego częste refaktoryzowanie kodów w celu uwzględnienia zmian negatywnie wpływa na harmonogram realizacji projektu, co stało się konieczne podczas sprintu. Jak najlepiej można to kontrolować, aby zminimalizować ryzyko przekroczenia uzgodnionego terminu realizacji projektu, skoro interesariusze nie chcą iść na kompromis?
Odpowiedzi
TL; DR
Częścią każdej struktury zarządzania projektami, ale szczególnie zwinnych ram, takich jak Scrum, jest konieczność ciągłego zarządzania oczekiwaniami interesariuszy. Ludzie chcą tego, czego chcą i kiedy chcą, ale duża część zarządzania projektem polega na wyjaśnianiu ludziom, co tak naprawdę mogą mieć w ramach różnych ograniczeń wpływających na projekt. Wraz z rozwojem projektu powinno się również rozumieć, co jest obecnie wykonalne w ramach obecnych ograniczeń, zwłaszcza gdy to, co wykonalne, odbiega od tego, co pierwotnie planowano.
Oczekiwana jest przeróbka
Refaktoryzacja implementacji zmian bez zmiany zewnętrznego zachowania. Najprawdopodobniej tak naprawdę nie dokonujesz refaktoryzacji; spłacasz dług techniczny lub wykonujesz poprawki i integrację, które z natury nie są tym samym.
Struktury takie jak Scrum traktują różne rodzaje pracy (w tym refaktoryzację i przeróbki) jako akceptowalny kompromis dla empirycznej kontroli i projektowania. Jest to obsługiwane w procesie szacowania i (poprawnie) objawia się jako przeszkoda dla szybkości, gdy rośnie dług technologiczny, złożoność lub tempo zmian. Jest to zarówno oczekiwane, jak i pożądane w ramach iteracyjnych, ponieważ każda pętla inspekcji i adaptacji zapewnia możliwość zmiany zakresu, priorytetów lub podejścia.
Przeróbka to koszt kontroli empirycznej. Tak naprawdę nie da się tego uniknąć w złożonych projektach, takich jak tworzenie oprogramowania. Scrum po prostu sprawia, że przeróbka jest widoczna dla zespołu i interesariuszy jako koszt wprowadzenia niezbędnych lub pożądanych zmian.
Naprawiono - wszystko nie jest możliwe
„Żelazny trójkąt” zakłada, że projekt można dostosowywać, kontrolując budżet, zakres lub harmonogram, przy czym pozostałe trzy suwaki mają wpływ na niejawny czwarty wymiar jakości. Poniższa grafika przedstawia to.
Zwinne frameworki, takie jak Scrum, ogólnie traktują zakres, a zwłaszcza zakres projektu , jako główny suwak, pytając:
Jak duży zakres możemy zmieścić w ramce czasowej pojedynczego Sprintu lub w naszym zwinnym planie wydania ?
Obecnie Twój projekt próbuje naprawić zarówno zakres, jak i harmonogram. To pozostawia budżet jako dostępny suwak. Jeśli spróbujesz również to zablokować, albo twój projekt się nie powiedzie, albo pogorszy się jakość, albo jedno i drugie. Po prostu nie można niezawodnie osiągnąć stałej ceny, ustalonego zakresu i ustalonego harmonogramu w żadnej strukturze projektu przy zachowaniu jakości; Scrum po prostu czyni to bardziej oczywistym i sprawia, że kompromisy są bardziej widoczne.
Celem Scruma nie jest magiczne spowodowanie zniknięcia żelaznego trójkąta. Zamiast tego zmusza projekt (a także interesariuszy i sponsorów) do pogodzenia się z nieodłącznymi kompromisami. Scrum umożliwia interesariuszom określenie, czy coś jest „wystarczająco dobre” do wysłania pod koniec każdego Sprintu, a Właściciel Produktu ma możliwość dostosowania zakresu i priorytetów podczas Udoskonalania Backlogu i Planowania Sprintu. Interesariusze muszą wykorzystać te wydarzenia jako sposób na zapewnienie im jak największej wartości w ramach planu wydania; to nigdy gwarancja zwrotu pieniędzy, że projekt będzie albo 100% kompletne i zdatne do celu na końcu stałych serii sprintów.
Zmniejsz koszty utopione
Innym aspektem zwinnego rozwoju jest możliwość „wczesnego niepowodzenia”. Gdy projekt może się nie powieść z jakiegokolwiek powodu, zwinne ramy, takie jak Scrum, dają właścicielowi produktu możliwość zaoszczędzenia pieniędzy poprzez anulowanie Sprintu i planowanie nowego w oparciu o zmienione oczekiwania lub umożliwienie interesariuszom anulowania pozostałej części projektu, jeśli tak się stanie. nie będą służyć ich celom. Ta ostatnia nie zapewni powodzenia projektu, ale zmniejszy koszty utopione związane z projektem.
Nic, co ktoś robi, nie gwarantuje sukcesu projektu. Najlepsze, co możesz zrobić, to kontrolować go i zabić skazany na porażkę projekt tak wcześnie, jak to możliwe, gdy sukces nie jest już możliwy.
Co możesz teraz zrobić
Po pierwsze, przyznaj, że jesteś na drodze do marszu śmierci. Jeśli nie zmierzysz się z tą prawdą, nic innego nie będzie miało znaczenia.
Następnie zastanów się, czy problemem jest projekt, dług technologiczny, nieuzasadnione oczekiwania, czy coś innego. Nie ma znaczenia, jaka jest główna przyczyna lub przyczyny; wystarczy, aby były widoczne, aby zespół i interesariusze mogli wspólnie się do nich zwrócić.
Na koniec jasno poinformuj o aktualnym stanie. Jeśli jesteś na dobrej drodze do wydania w pełni funkcjonalnego wydania kilka cykli po pierwotnie przewidywanej dacie dostawy, przedyskutuj, czy projekt może dostosować wierzchołek „czasu”. Jeśli nie możesz lub nie możesz dostosować harmonogramu, nadal możesz dotrzymać ustalonego terminu, zwiększając koszty lub zmniejszając zakres. Czy interesariusze handlowaliby na czas w celu ograniczenia czasochłonnej funkcjonalności? Nie dowiesz się, dopóki nie zapytasz.
Jeśli projekt nie może lub nie zrobi żadnej z powyższych rzeczy, przygotuj się na niepowodzenie. Odśwież swoje CV i miej nadzieję, że nauczyłeś się cennych lekcji, które możesz wykorzystać w następnym projekcie lub następnej pracy. Przede wszystkim miej nadzieję, że nauczyłeś się wcześnie i często komunikować o założeniach, wyzwaniach, wymaganiach ramowych i kompromisach, a także zinternalizowałeś znaczenie ciągłego zarządzania oczekiwaniami interesariuszy.
Czy w każdym sprincie tworzysz możliwy do wdrożenia przyrost produktu? Jeśli tak, to ustalone terminy dostaw są już dotrzymane i jest to najlepszy sposób na zminimalizowanie ryzyka i zapewnienie klientowi zaufania do tego, co robisz. Interesariusze (za pośrednictwem właściciela produktu) powinni zdecydować, które rzeczy chcą i kiedy, więc najważniejsze jest, aby nadal widzieli, jak dostarczasz wartość, i że otrzymujesz ich opinie na temat ulepszeń, zmian i poprawek potrzebnych do produktu. Uzyskanie ich opinii jest tutaj kluczowe. Klienci mogą być, co zrozumiałe, zaniepokojeni, jeśli harmonogram wydłuży się bez nowego zakresu funkcjonalnego, ale gdy tylko zaczniesz włączać najnowsze ulepszenia, które uznają za priorytet, będą bardziej skłonni docenić potrzebę elastyczności.