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

15

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 .

Giorgio
źródło
5
The only well-designed module I could produce recently I obtained by taking a different approach- Odpowiedziałeś na swoje pytanie. Nadal potrzebujesz trochę dobrego projektu; nie można oczekiwać, że dobry projekt wyrasta organicznie po refaktoryzacji. To nie działa w ten sposób.
Robert Harvey
1
Nie. Ponieważ może nie stosuję poprawnie SCRUM.
Giorgio
3
Nie ma czegoś takiego jak „SCRUM poprawnie”. Jest tylko ten proces, który daje pożądany rezultat.
Robert Harvey
1
Dlatego nazywane są „wytycznymi” :) W każdym razie, zatwierdzaj codziennie, miej krótkie (od 1 tygodnia do 1 miesiąca) sprinty, takie zasady wcale nie mówią o projektowaniu. Nadal musisz mieć projekt.
Robert Harvey

Odpowiedzi:

13

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.

Telastyn
źródło
3
+1 (+10, gdybym miał więcej niż jeden głos!) Za „Zmuszenie ich do tego pudełka spowoduje tylko kłopoty”.
Giorgio
17

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.

Kevin Cline
źródło
+1: OK. Powinienem więc zaplanować historię refaktoryzacji, kiedy myślę, że jest taka potrzeba, i nie dodawać żadnych nowych funkcji, dopóki nie będę mieć wystarczająco dobrego projektu. Prawdopodobnie tego nam brakuje w naszym procesie (oprócz tego, że w IMO przyrosty, które opracowujemy, są często zbyt małe).
Giorgio
2
tak naprawdę powinieneś dodać historię długu technicznego i przedyskutować, kiedy należy podjąć działania w tej sprawie z właścicielem produktu, to właśnie oznacza dług techniczny .
4
Wszystkie projekty, w których widziałem, w których odpowiedzialność za jakość kodu spoczywa na właścicielu produktu poprzez tworzenie historii „długów technicznych” lub podobnych, jakość kodu zawsze była traktowana priorytetowo tak nisko, że poważnie szkodziło to szybkości i morale. Wierzę, że zespół jest podmiotem, który bierze odpowiedzialność za jakość kodu. Zespół powinien oszacować historie, aby było miejsce na dostarczenie z zachowanym lub, jeśli to konieczne, zmniejszonym długiem technicznym.
Buhb,
4
„Historia refaktoryzacji” lub „Historia długu technicznego” nie powinna się zdarzyć. Nigdy. Koszt refaktoryzacji jest częścią rozwoju i nie powinien być osobnym zadaniem. Należy to robić w sposób ciągły małymi krokami, nie planowanymi, po fakcie, historiami. Wiem o tym, nasz zespół wypróbował historie refaktoryzacji, to źle. Kiedy zaczniesz refaktoryzować „w locie”, zobaczysz, że refaktoryzacja staje się częścią twojego kodowania, a nie oddzielnym zadaniem do wykonania.
Patkos Csaba
1
Jeśli uważasz, że baza kodów nie będzie w stanie wygodnie poradzić sobie z historią X bez znaczącej restrukturyzacji / przepisania, to ta restrukturyzacja powinna być częścią historii X, a praca potrzebna do tej restrukturyzacji powinna zostać uwzględniona przy szacowaniu historii X.
Buhb
6

„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.

Robert Harvey
źródło
2
Czy „dobrze zaprojektowany” jest celem właściciela produktu: nie jest bezpośrednim celem. Pośrednio tak: dobrze zaprojektowany oznacza łatwiejszy do debugowania i konserwacji. Musiałem spędzić tygodnie na znajdowaniu krytycznych błędów (które spowodowały awarię aplikacji) w niechlujnym, źle zaprojektowanym kodzie.
Giorgio
3
Co za przygnębiająca odpowiedź. Zasadniczo gwarantuje mierne oprogramowanie otaczające planetę jak szara mazia.
Robert Harvey
@Giorgio, który nie jest celem, to dorozumiane oczekiwanie.
@RobertHarvey Wiem , że widziałeś wideo Big Ball of Mud i czytałeś gazetę . To jest prawdziwe życie, w szczególności SCRUM jest potwierdzeniem BBOM i obejmuje je w metodologii, przyjmując entropię jako część procesu i zarządzając nią, próbując ją udokumentować (debiut techniczny) i spowolnić (refaktoryzacja). Tak, powinieneś zacząć tak daleko od całkowitego BBOM / Entropy, ale w prawdziwym życiu nie zawsze tak jest.
1
OK, ale nie możesz jeść „domniemanych oczekiwań”. To tylko machanie ręką. „Będzie dobrze zaprojektowany, ponieważ jestem profesjonalistą i wiem, co robię”. (używając mojego najlepszego głosu Billa Murraya) Tak, racja.
Robert Harvey
3

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.

superM
źródło
1
+1: Bardzo interesująca odpowiedź. Zwinni kibice powiedzieliby ci, że powinieneś podzielić swoją 6-tygodniową historię na mniejsze. Kiedyś otrzymałem podobną radę i odpowiedziałem, że moje sześć 1-tygodniowych historii miałoby wiele zależności między sobą: ponieważ nawet jeśli zmienię plan pracy, nie mogę zmienić dziedziny problemowej. Nie mam na to odpowiedzi: zwinny często zakłada, że ​​możesz przerwać pracę nad małymi, niezależnymi historiami, ale w prawdziwym świecie nie zawsze tak jest.
Giorgio
1

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ę?

JeffO
źródło
„Dlaczego ktoś z historią udanych projektów związanych z wodospadem miałby przejść na zwinną metodologię?”: Bardzo dobra obserwacja (+1). Myślę, że wybór między wodospadem a zwinnością powinien być związany z tym, co się robi: w przypadku projektów o słabo określonych wymaganiach, które wymagają częstych prototypów i w których prototyp prawdopodobnie stanie się produktem końcowym, zwinność może być odpowiednia. W przypadku projektu, w którym wymagania są bardziej stabilne i gdzie ważniejsza jest solidność i stabilność, wodospad (lub pewna odmiana) jest prawdopodobnie lepszym wyborem.
Giorgio,
0

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.

James
źródło
Czy dobrze jest zaplanować historii projektu ?
Giorgio
@Giorgio: Prawdopodobnie nie jest to konieczne, ale właściciel produktu powinien przynajmniej przedstawić swojemu zespołowi przegląd oczekiwań klienta wobec projektu, zanim rozpocznie się projekt, oraz wyjaśnienie, w jaki sposób został on rozbity.
James
1
Jeśli ktoś głosuje negatywnie, proszę podać przyczynę
James
Downvoterzy rzadko poświęcają czas na wyjaśnienie, dlaczego głosują. Uważam to za dość irytujące.
Giorgio