Przepisywanie oprogramowania przy użyciu metodologii Agile

Załóżmy, że musisz przepisać całą aplikację przy użyciu metodologii Agile. Jak byś to zrobił?

Sądzę, że możesz napisać dużą grupę historii użytkowników opartych na zachowaniu twojego obecnego systemu. A następnie zaimplementuj je w małych iteracjach. Ale to nie znaczy, że mamy wymagania Z PRZODU ?

Ponadto, kiedy zaczniesz wydawać? Zwinny mówi, że powinniśmy wypuszczać wcześnie i często, ale nie ma sensu wypuszczać go przed zakończeniem kompletnego przepisywania.

Podziel go na epopeje na wysokim poziomie. Weź każdy obszar funkcjonalny aplikacji, krok po kroku.

Podziel jedną epicką historię na grupę opowiadań (użyteczne fragmenty - wszystko, co poprawia aplikację) i zarządzaj nimi tak, jak gdybyś nie miał istniejącej aplikacji, z jednym wyjątkiem: jeśli to możliwe, zrób to, abyś może wdrożyć ten element funkcjonalności jako część oryginalnej aplikacji lub obok niej.

Kiedy agiliści mówią „wcześnie i często wypuszczaj”, nie musi to oznaczać produkcji. Jeśli zamierzasz zastąpić istniejącą aplikację, powinieneś często używać wersji tymczasowej i upewnić się, że użytkownicy testują tam system. To wciąż pozostawia im miejsce, aby nadać priorytet następnej pracy i upewnić się, że nic, co wydasz do produkcji, nie obniża wartości produktu.

Po zwolnieniu jednego komponentu do produkcji przejdź do następnego.

właśnie przeszliśmy przez takie doświadczenie (ja jako właściciel produktu scrum). Dwa lata zajęło nam dotarcie do czegoś, co można wydać. Ale zwinny przyniósł nam wiele korzyści.

Po pierwsze: całkowite przepisanie nie jest z natury zwinne. Zamiast tego należy rozważyć refaktoryzację istniejącego produktu kawałek po kawałku. Zostało to omówione w innym pytaniu. Załóżmy więc, że musi to być przepisanie.

Rzeczywiście, zaczynasz od dziennika zdarzeń, który obejmuje wszystkie odpowiednie przypadki użycia istniejącego produktu. Ale proszę, nie traktuj tego jak pisanie specyfikacji. To byłoby zbyt wiele szczegółów. Powinien być kompletny (w przeciwnym razie nie można zaplanować wydania). I nie powinno to być zbyt skomplikowane (inaczej piszesz specyfikacje z góry). Oto jak do tego podeszliśmy:

• kategoryzuj użytkowników starego produktu. Zidentyfikuj użytkowników, którzy potrzebują tylko niewielkiej części starego produktu, i nadal uzyskaj z niego coś pożytecznego. Definiują twoje pierwsze epopeje.

• Następnie dodaj epiki, które pozwoliłyby innej kategorii użytkowników przejść do nowego produktu. Itd., Dopóki nie będziesz mieć tylnego dziennika obejmującego wszystkich użytkowników.

• najprawdopodobniej te epiki będą wymagać dalszego podziału. Jeśli to możliwe, spróbuj podzielić, aby każda część nadal miała jakąś wartość. Jeśli nie jest to wykonalne, to przynajmniej upewnij się, że każdą część można wykazać.

• gdy masz 20-50 eposów, poproś zespół o ich oszacowanie.

• podzielił najważniejsze epopeje na Historie użytkowników, które zdaniem zespołu są wykonalne w trakcie sprintu. Nie rób tego jeszcze dla wszystkich epików, tylko tych na górze. Będziesz miał dużo czasu na podzielenie się resztą.

Kiedy wypuszczać na zewnątrz! To jest decyzja biznesowa. Przynajmniej to podejście daje możliwość wcześniejszego wydania niektórych kategorii użytkowników. Może to być przydatne, jeśli kierownictwo denerwuje się tym pozornie niekończącym się projektem.

Zwolnij teraz, jeśli możesz

Twoje pytanie o to, kiedy zaczniesz wypuszczać kod, jest świetne. Myślę, że obowiązują dwa warunki. Po pierwsze, że masz „wystarczająco dobrą jakość”, a po drugie, że spełniasz wymagania MVP (minimalny opłacalny produkt).

Rzym (i zwinny) nie został zbudowany w jeden dzień

Być może jesteś gotowy z zespołem zwinnym pod klucz, aby przejąć kontrolę już pierwszego dnia. W przypadku większości organizacji jest to praca i koszt szkolenia, przebudowy oraz zwykłe formowanie, szturmowanie, normowanie, wykonywanie cyklu budowania zespołu. Bądź na bieżąco z informacjami o ryzyku i kosztach, bądź ostrożny, aby ustalać realistyczne oczekiwania, bądź na bieżąco i przygotowany do popierania twojego podejścia.

Ponownie użyj Bootstrappera

Podobnie jak energia syntezy jądrowej, ponowne użycie kodu jest i zawsze będzie przyszłym rozwiązaniem naszych problemów gospodarczych. Mam wrażenie, że programiści często twierdzą, że wierzą w ponowne użycie, ale tylko rodzaj ponownego użycia, który zaczyna się po zbudowaniu nowego frameworka, a nie taki, w którym bazują na tym, co ktoś już zrobił. Jak to działa, dopóki ktoś nie zdecyduje się na budowanie na czyimś fundamencie? W najlepszym razie oznacza to przepisywanie co kilka lat, gdy zmienia się kierownictwo zespołu.

Dlaczego często wypuszczać wcześnie?

Zwolnij wcześniej i często jest mantrą z wielu powodów. Daje życie naszym dyskusjom na temat tego, czym powinien być produkt, staje się realne tam, gdzie jesteśmy, i daje nam podstawę do iteracyjnych / przyrostowych zmian. Tempo wydań jest praktycznie niezmienne dla zwinnych, z tą różnicą, że kto otrzymuje wydania (zastępcy klientów lub użytkownicy końcowi). Przed zwinnością oszacowano, że konserwacja stanowi 60% kosztów systemów oprogramowania. Jest to źródłem wielu konsternacji dla menedżerów i innych osób. Niektórzy uważają, że wydanie produktu jest przyczyną śmierci oprogramowania. Dla nich wszystko po wydaniu to przerobienie i zapłacenie, aby naprawić produkt, za który już zapłacili.

Pre-release jest nienaturalne

Kent Beck pisze, że wersja przedpremierowa jest nienaturalnym stanem oprogramowania. Jest to z pewnością niewygodny czas, ponieważ jest to czas, w którym nie masz klientów i płacisz za produkt, a nie za produkt.

Nie krytykuj poprzedniego zespołu

Chociaż może to pomóc programistom, którzy przejmą przepisywanie jako heros i zbawienie projektu, myślę, że krytykowanie osiągnięć poprzedniego zespołu jest kosztowne.

• Po pierwsze, jeśli pozwalasz ludziom decydować o poprzednim zespole, masz więcej czasu i energii na swoją prawdziwą misję.
• Będzie to niezręczne, jeśli będziesz musiał współpracować z członkami poprzedniego zespołu, zarówno deweloperami, jak i interesariuszami, takimi jak menedżerowie produktu, kierownicy projektów lub klienci.
• Jeśli uda ci się sprawić, że zadziała, być może otrzymasz (lub jeszcze gorzej) kredyt za to, co zrobił poprzedni zespół.
• Średnio poprzedni zespół był prawdopodobnie średni. Średnio możesz być przeciętny. Masz więcej pracy niż poprzedni zespół, ponieważ masz nową metodologię, którą należy wprowadzić oprócz projektu.
• Jeśli stary zespół był okropny, chyba że też jesteś okropny, w końcu zyskasz uznanie za bycie lepszym niż okropnym. Jeśli były lepsze niż okropne, a ty nie jesteś wyraźnie lepszy, powiedzenie, że były okropne, może zaprosić nieprzyjemne porównania.
• Jeśli stary zespół był lepszy, niż ci się wydawało, i wpadniesz w kłopoty, ponieważ organizacja jest zepsuta lub problem jest źle zdefiniowany lub bardzo trudny, wszystko pójdzie lepiej, jeśli nie podniosłeś znacząco oczekiwań.
• Jeśli oczekują tego, co dostają, ale robisz to lepiej, to jest dla ciebie wygrana.
• Powstrzymanie się od krytyki to zarówno dobre maniery, jak i dowód, że masz klasę.

Monitują komentarze @Chuck i odniesienia do Netscape, mówiąc w zasadzie „nie przepisuj”, i prawidłowe odpowiedzi odpisujące, że OP nie pyta, czy powinien. - Naprawdę zwinny cykl tworzenia oprogramowania wyklucza przepisywanie. Przepisywanie prawie zawsze łamie wiele zasad Agile. Używając obecnego oprogramowania jako podstawy, te zasady Agile (z Agile Manifesto ) nie mogą być spełnione przy przepisywaniu.

• Wczesne i ciągłe dostarczanie cennego oprogramowania . - klient nie uzyska wczesnej wartości w porównaniu do tego, co już ma
• Często dostarczaj działające oprogramowanie - tygodnie lub miesiące - jak duży jest ten projekt, możesz szczerze powiedzieć, że klient dostanie w przyszłości coś bardziej przydatnego.
• Działające oprogramowanie jest podstawową miarą postępu - praca w porównaniu z poziomem podstawowym nie nastąpi w pośpiechu
• Zwinne procesy promują zrównoważony rozwój. - Biorąc pod uwagę, że klient ma działającą linię bazową, presja będzie na dostarczenie ulepszonej funkcjonalności. Jest mało prawdopodobne, aby było to zrobione w tempie, które jest zrównoważone
• Prostota - sztuka maksymalizacji ilości niewykonanej pracy - jest niezbędna. to mówi wszystko naprawdę ...

„Załóżmy, że musisz przepisać całą aplikację przy użyciu metodologii Agile, jak byś to zrobił?”

Pytanie opiera się na fałszywej przesłance - że przepisanie można uznać za zwinne.

Zastanów się, czy możesz zwolnić przepisaną aplikację pojedynczo i mieć ją przy produkcji razem ze starą.

W szczególności w przypadku aplikacji internetowych przeniesienie pojedynczej części aplikacji na nową platformę może być dość łatwe, a moduł równoważenia obciążenia kieruje żądania do odpowiedniego systemu. Następnie napisz historie, które pozwolą ci uruchomić swoją pierwszą stronę, i dostarczaj je w zwinny sposób.

Aplikacje komputerowe mogą być bardziej skomplikowane, ale często będzie to możliwe.

Szukasz szwów - miejsc, w których stary system może przejąć obowiązki nowego, bez konieczności pełnego przepisywania.

Być może istnieje pewna niezależna logika biznesowa, którą można przenieść do nowej usługi lub frameworku, a starą aplikację można zmodyfikować, używając jej zamiast starego kodu. Po prostu wycinaj kawałki w szwach, aż to, co pozostanie, będzie możliwe do opanowania w jednym kęsie.

Jeśli nie możesz znaleźć żadnych szwów, być może będziesz musiał poszukać takiego rodzaju podejścia Big Bang sugerowanego w niektórych innych odpowiedziach. Ale przygotuj się na długi marsz, zanim dotrzesz do celu, zwłaszcza jeśli oczekuje się, że równolegle będziesz rozwijać stary system ...

Zwinny mówi, że powinniśmy wypuszczać wcześnie i często, ale nie ma sensu wypuszczać go przed zakończeniem kompletnego przepisywania.

W rzeczywistości, IMHO to jest kluczowy punkt - im wcześniej otrzymasz części przepisanej aplikacji w produkcji (i idealnie zastępujesz funkcjonalność starego systemu), tym większe są szanse, że Twój projekt odniesie sukces. Jeśli uważasz, że to nie ma większego sensu, zastanów się nad tym - prawie zawsze są możliwości uwolnienia części.

Prawdopodobnie będzie to oznaczać, że ktoś musi coś zmienić w starej aplikacji, na przykład dodać nowe interfejsy do interakcji z przepisaną aplikacją w czasie, gdy przepisywanie nie jest zakończone. Ale z mojego doświadczenia wynika, że ​​taka dodatkowa praca zawsze się zwraca.

Gdy pierwsze części nowej aplikacji będą w produkcji, sprawne, iteracyjne podejście stanie się oczywiste. Wymagania zmienią się, twoje historie użytkowników zmienią się lub uzyskają nowe priorytety, i mam nadzieję, że zastąpisz coraz większą funkcjonalność starego systemu małymi krokami.