Jak uzyskać dobry projekt, stosując metody zwinne?

Używam metodyki zwinnej (SCRUM) od około trzech lat i widzę w niej pewne zalety, szczególnie w krótkoterminowych opiniach na wielu poziomach (od klientów mających wczesny dostęp do zaimplementowanych funkcji, od testerów, którzy mogą testować funkcje jako zaraz po ich wdrożeniu, od innych programistów, którzy mogą bardzo wcześnie przekazywać opinie na temat nowego kodu poprzez przegląd itp.)

Z drugiej strony mam dwa otwarte problemy, z których pierwszy spróbuję wyjaśnić w tym pytaniu.

Problem: Trudność z uzyskaniem dobrego projektu

Staram się przeprowadzać refaktoryzację, gdy tylko kod staje się nieuporządkowany, piszę testy jednostkowe tak dużo, jak to możliwe (co pomaga w zapobieganiu błędom w ogóle, a zwłaszcza w refaktoryzacji). Z drugiej strony, opracowanie złożonej funkcji w małych krokach, z codziennymi zatwierdzeniami i ciągłym przemyślaniem kodu, gdy staje się nieustrukturyzowany, nie pozwala mi na stworzenie naprawdę dobrego projektu.

Jedyny dobrze zaprojektowany moduł, który mogłem ostatnio wyprodukować, uzyskałem, stosując inne podejście: analizowałem problem przez kilka dni (właściwie miałem problem przez kilka miesięcy, zanim zacząłem nad nim poważnie pracować) ), przez kilka kolejnych dni naszkicowałem dość szczegółowy projekt wszystkich zaangażowanych klas i ich relacji, a następnie zamknąłem się w moim biurze i spisałem cały kod, pracując bez przerwy przez około trzy tygodnie. Rezultat był najlepszą rzeczą, jaką stworzyłem od jakiegoś czasu, z bardzo małą liczbą błędów, które były dość łatwe do zlokalizowania i naprawy, oraz z bardzo przejrzystym projektem, który od tamtej pory nie wymagał żadnych istotnych zmian.

Do tej pory uważałem, że o wiele skuteczniejsze jest uzyskanie ogólnego obrazu tego, co chcę zrobić wcześniej, niż pisanie kodu małymi krokami w nadziei, że duży obraz pojawi się magicznie w trakcie tego procesu. Z moim wysiłkiem podejście polegające na opracowywaniu małych przyrostów zawsze prowadziło mnie do gorszego projektu.

Pytanie : Czy ktoś miał podobne doświadczenie? Czy stosuję SCRUM w niewłaściwy sposób lub na co powinienem zwrócić uwagę, jeśli chcę się rozwijać w małych krokach i nadal mieć dobrze zaprojektowane oprogramowanie? A może powinienem zaplanować historię projektu przed rozpoczęciem właściwego kodowania? Czy jest to uważane za dobrą praktykę, przynajmniej w przypadku funkcji bardziej złożonych niż średnia?

EDYTUJ NOTATKĘ

Zdaję sobie sprawę z tego, że dobry projekt nie jest czymś absolutnym i sam w sobie nie ma wartości, ale zależy od kontekstu i że należy dążyć do projektu, który jest wystarczająco dobry dla danego problemu.

Na przykład nie dbam (zbytnio) o dobry projekt, jeśli muszę wdrożyć prosty komponent, który (1) musi być gotowy jak najszybciej, (2) zostanie użyty tylko raz, (3) nie jest używane przez inne części systemu (YAGNI).

Dbam o dobry projekt, gdy komponent (1) będzie używany kilka razy, aw kilku różnych wersjach produktu (2) musi być utrzymywany i przedłużany w czasie, (3) ma wiele innych komponentów w zależności od niego .

Z drugiej strony, opracowanie złożonej funkcji w małych krokach, z codziennymi zatwierdzeniami i ciągłym przemyślaniem kodu, gdy staje się nieustrukturyzowany, nie pozwala mi na stworzenie naprawdę dobrego projektu.

Więc nie rób tego.

Nie wszystko pasuje do ładnego, zwinnego pudełka. Często produkt zawiera kilka skomplikowanych rzeczy, których nie można sprzedać pojedynczym osobom i których nie można ukończyć w żaden rozsądny sposób podczas sprintu. Zmuszenie ich do tego pudełka spowoduje tylko kłopoty. Ale powinno być ich niewiele i daleko. Jeśli stwierdzisz, że wiele z twoich komponentów jest takich, właściciel produktu musi pracować nad lepszym rozwiązywaniem problemów (ze swoim zespołem). Czuję się dobrze, robiąc to, co zrobiłeś: weź historię, zaprojektuj ją, a następnie rozwal jak najszybciej, oczekując, że zajmie to kilka tygodni.

W bardziej ogólnym przypadku istnieją 3 rzeczy, które widziałem, aby uzyskać dobry projekt w Agile:

• Właściwie to projektuj - wiele miejsc, które widziałem, rozpoczynają swój sprint i po prostu zaczynają wymyślać kody. W ten sposób otrzymasz zły projekt. Zwinne nie zmienia procesu tworzenia planu - kodu - testu - wydania, po prostu skraca go do bardziej szczegółowych elementów. Na początku sprintu usiądź w razie potrzeby i zaprojektuj swoje rozwiązanie.

• Miej architekta / lead - Gdy twój projekt będzie wystarczająco duży, skończysz z wieloma zespołami scrumowymi pracującymi nad różnymi częściami aplikacji. Bardzo przydatne jest posiadanie kogoś (lub wielu osób w zależności od wielkości aplikacji), którego głównym zadaniem jest wiedzieć, co robią wszystkie zespoły z punktu widzenia projektowania. Mogą odpowiedzieć na pytania i poprowadzić zespoły w kierunku bardziej harmonijnego, nadrzędnego projektu. Każdy zespół scrumowy ma przewagę, która wie, co robią inne zespoły, które widziałem, i która była bardzo skuteczna.

• Bądź pragmatykiem - omówiłem to powyżej. Zwinne to narzędzie i jak każde narzędzie; nie dotyczy wszystkich problemów. Jeśli zastosowanie jakiegoś komponentu nie ma sensu, nie należy go tam stosować. Twoim celem jest dostarczenie dobrego oprogramowania; nie zapomnij tego.

Bardzo możliwe jest wdrożenie w małych krokach i uzyskanie dobrze skonstruowanego, łatwego do utrzymania kodu. Teoretycznie jest to bardzo proste: jeśli upewnisz się, że kod jest dobrze ustrukturyzowany po każdej zmianie, zawsze będzie dobrze ustrukturyzowany. Twój kod staje się słabo ustrukturyzowany, ponieważ nadal dodajesz kod, kiedy powinieneś refaktoryzować.

Bez względu na to, ile czasu poświęcisz na projektowanie, w końcu wymagania zmienią się w nieoczekiwany sposób i będziesz musiał napisać kod, który nie będzie pasował do oryginalnego projektu. Następnie będziesz musiał dokonać stopniowej zmiany. Jeśli masz dobry zestaw testów jednostkowych i jesteś biegły w refaktoryzacji, będziesz w stanie utrzymać dobrą strukturę kodu, spełniając nowe wymagania.

„Dobrze zaprojektowane” jest subiektywne

Co oznacza dla Ciebie „dobrze zaprojektowany” ? do właściciela produktu? dla klienta?

Czy „dobrze zaprojektowane ” jest celem właściciela produktu? cel klienta? czy tylko Ty?

Czy to , co uważasz za „niezbyt dobrze zaprojektowane”, wciąż spełnia oczekiwania właścicieli produktów i sprawia, że ​​klient jest szczęśliwy? To jest całkiem „dobrze zaprojektowane” .

Good Enough and YAGNI

Nic w większości metodologii zwinnych nie mówi o „dobrze zaprojektowanym”, ponieważ każdy system, który Właściciel produktu akceptuje jako kompletny, a klienci uważają, że spełnia ich wymagania, jest „dobrze zaprojektowany” .

Jest oczekiwać , że deweloperzy są profesjonalistami i pragmatycznie wykorzystywać najlepsze praktyki, odpowiednie wzory i idiomów do realizacji funkcji i historie.

Jeśli nie bierzesz pod uwagę czasu na prawidłowe wykonanie czynności, co stanowi problem programisty, jeśli Właściciel Produktu żąda rzeczy w krótszym czasie, niż można to zrobić, jest to ich przywilejem, a Twoim obowiązkiem jest edukowanie ich na temat konsekwencje w postaci historycznych długów technicznych .

SCRUM

_{Metodologia zwinna, którą można zapisać, nie jest metodyką zwinną. ”- Jarrod Roberson}

SCRUM ma być ramą narzędzi do zarządzania całkowitym cyklem życia oprogramowania. To nie powinien być sztywny zestaw rzeczy, tylko dobre miejsce do rozpoczęcia i mam nadzieję na poprawę.

Większość sklepów, w których pracowałem, ma tak zwane Sprint ZERO, sprinty dla starszych członków zespołu, aby naszkicować ogólną architekturę lub temat produktu.

Historie, które są większe niż 20, zwykle się rozpadają, aż w rzeczywistości są to historie 3–5 punktowe. Jedna z tych historii brzmi: „Jako zespół musimy się spotkać, aby omówić, w jaki sposób zaprojektujemy tę funkcję, abyśmy mieli jak najmniej techniczny dług, biorąc pod uwagę przydzielony czas”.

Ogólnie

Ogólnie rzecz biorąc, „dobrze zaprojektowany” system jest wystarczająco dobry i podąża za YAGNI.

Agile, aw szczególności SCRUM jako implementacja Agile, skupiają się na tym, jak wytwarzać produkt w sposób jak najbardziej przejrzysty dla Właściciela / sponsorów produktu.

To nie jest o niczym technicznego projektu / architektura mądry. Jest to bardziej filozofia dotycząca sposobu dostarczania oprogramowania, które spełnia potrzeby i oczekiwania klientów. Jeśli nie ma czegoś, co nazywacie „dobrze zaprojektowanymi” częściami, nie jest to samo w sobie wadą, ponieważ nie jest to podstawowa część filozofii.

Pracujemy ze scrumem od kilku miesięcy i chcę podzielić się moim doświadczeniem dotyczącym twojego problemu.

Kilka miesięcy temu dostałem duży kawałek do wdrożenia. Przygotowałem wszystkie specyfikacje, więc musiałem odpowiednio wdrożyć nowe funkcje. Zadanie miało zająć około 5-6 tygodni (jak oszacowałem). Pierwszy tydzień spędziłem na projektowaniu. Zadanie było trochę skomplikowane: istniał główny obiekt, który, jak wywnioskowałem ze specyfikacji, miał 15 różnych stanów, a interfejs użytkownika miał mieć różne zachowania dla każdego stanu.

Zaprojektowałem cały przepływ pracy, a następnie strukturę i klasy DB.

W moim przypadku nie widzę innego podejścia. Gdybym od razu zajął się kodowaniem, na końcu miałbym duży, nieprzyjemny bałagan - prawie niemożliwy do utrzymania i niezwykle trudny do wprowadzenia dalszych zmian. Ale zmiany nadeszły w ciągu najbliższych 2 tygodni, więc musiałem przerobić kod. Było to teraz łatwe dzięki początkowo przemyślanemu projektowi. Oszczędzało to nasz czas, pieniądze i nerwy.

Po tym doświadczeniu jestem absolutnie pewien, że na początku warto stworzyć akceptowalny projekt, niż mam nadzieję, że z jakimś cudem dostaniesz go na końcu.

Widok z tyłu wynosi 20-20. Jeśli na początku projektu dysponowałeś dostępnymi informacjami, aby dowiedzieć się wszystkiego, a następnie napisać kod za kilka tygodni, sugeruję, abyś to zrobił.

Nie przyznajesz wystarczającego uznania wszystkim zdobytym spostrzeżeniom, podejściom, które zostały wypróbowane i zawiodły / musiały zostać zmienione, a także zwiększonej zdolności klienta / użytkowników do zapewnienia wymaganego uznania.

Dlaczego ktoś z historią udanych projektów związanych z wodospadem miałby przejść na zwinną metodologię?

Zawsze potrzebujesz szerszego obrazu tego, jaki powinien być cel końcowy oraz jakie funkcje mają zostać wdrożone i kiedy przed rozpoczęciem projektu. Praca nad historiami jako zadaniami atomowymi wymaga kłopotów. Musisz w miarę możliwości mieć na uwadze przyszłe wymagania.