Jak radzisz sobie z projektowaniem w Scrum?

Jak radzisz sobie z projektowaniem w Scrum? Czy nadal masz dobrze napisane dokumenty projektowe dla każdej iteracji scrum? Czy robisz tylko notatki projektowe zawierające diagramy UML? A może masz dobrze skomentowany kod?

Każda iteracja może wymagać zmiany projektu, więc chciałem tylko dowiedzieć się, jak ludzie ją wychwytują, aby nowi programiści mieli łatwą pracę ze zrozumieniem domeny i jak najszybszym wejściem na pokład.

tylko dlatego, że jest scrum, nie oznacza, że ​​wszystko zmienia się podczas każdego sprintu!

Scrum polega na robieniu tego, co konieczne (ale nie więcej) . Nadal musisz wykonać projekt i nadal musisz udokumentować. To tylko kwota nie jest ustalona ani jak to zrobić.

Część planowania każdego sprintu decyduje o tym, co należy zrobić. Jeśli coś w zaległości musi zostać zaprojektowane, ponieważ wpływa to na inne rzeczy, musisz dodać konkretne zadanie dla procesów projektowania i zrobić to przed zadaniem implementacji.

Mam wiele do powiedzenia na ten temat. Widziałem wiele przypadków, w których firmy / zespoły / ludzie twierdzą, że używają zwinnego podejścia do oprogramowania, ale w rzeczywistości chcą czerpać korzyści, które obiecują metodyki zwinne bez przestrzegania zasad.

Aby szybka iteracja zadziałała, powinieneś zrobić programowanie testowe (przestałem mówić, że musisz robić TDD niechętnie). W TDD twoje testy wyrażają projekt i zamiary kodu (kiedy mówią „kod to dokumentacja”, to co powinni powiedzieć, to „testy to dokumentacja”). Pisząc testy jednostkowe, które wyrażają zrozumienie dla danej funkcji, wyraźnie stwierdzasz, co według Ciebie powinien zrobić kod. Następnie piszesz kod, który to robi. Następnie refaktoryzujesz ten kod, aby był zgodny z dobrymi zasadami architektury „Red-Green-Refactor”.

Uruchamianie testów jednostkowych przy każdym meldowaniu (lub nawet przed każdym meldowaniem) sprawdza, czy nowy napisany kod nie psuje oczekiwanej funkcjonalności w innym obszarze aplikacji. Zapewnia to siatkę bezpieczeństwa, która pozwala na zmianę kodu bez konieczności porzucania. Wraz ze wzrostem zrozumienia obowiązujących wymagań możesz zmodyfikować test, aby odzwierciedlić tę nową wiedzę. Prawdziwy projekt leży w testach jednostkowych. Cała reszta (w tym nie objęty kodem) jest kłamstwem.

Oto kilka zalecanych lektur

• Wyczyść kod
• Zwinne zasady tworzenia oprogramowania, wzorce i praktyki
• Pragmatyczny programista

Są to dobre miejsca, aby zacząć uczyć się, jak naprawdę podejść do sprawnego rozwoju.

Scrum to metodologia zarządzania projektami, a nie metodologia opracowywania oprogramowania. Scrum jest zwykle używany w połączeniu z metodologią Agile. Na tym polega twoja odpowiedź.

Projekt nie jest tak duży, jak często zmieniają się wymagania. Dlatego projektowanie do poziomu klasy jest zwykle stratą czasu. Warto jednak szkicować decyzje architektoniczne na wyższym poziomie.

Problem z tworzeniem wytrzymałych dokumentów projektowych polega na tym, że są one przestarzałe niemal natychmiast po ich utworzeniu. Tak więc najlepiej działała zwykle dokumentacja wysokiego poziomu, która prawdopodobnie nie zmieni się całkowicie w krótkim czasie.

Scrum to iteracyjny i przyrostowy model oparty na zwinnych wartościach . Oznacza to, że nie masz oddzielnej fazy projektowania. Chodzi o to, że powinieneś stale zajmować się projektowaniem, tak jak stale zajmujesz się analizą, wdrażaniem, testowaniem i integracją w całym projekcie.

Potrzebujesz trochę planowania, aby to zadziałało. Weź udział w spotkaniu dotyczącym planowania sprintu , podczas którego zespół szacuje zadania na nadchodzący sprint. Większość ludzi nie zdaje sobie sprawy, że jest to nie tylko spotkanie szacunkowe, ale także wysiłek projektowy. Na przykład zadaniem może być „Dodaj kod dla nowego modelu samochodu”. Nie możesz jeszcze tego oszacować, musisz dowiedzieć się więcej. Zespół omawia więc projekt i proponuje szerokie rozwiązanie („podklasa Samochód?”) I dodaje to jako przypomnienie zadania. Rzadko potrzebujesz więcej formalności niż to. Masz teraz pomysł, jak rozwiązać problem. Nie masz jeszcze wszystkich szczegółów i to dobrze, znasz wystarczająco dużo projektu, aby móc wygodnie oszacować. Bez konieczności tworzenia jakichkolwiek diagramów (w tym momencie).

Aby uzyskać rzeczywistą dokumentację fizyczną , zalecam utworzenie na ścianie schematu przeglądowego systemu, aby wszyscy mogli go zobaczyć. Przegląd musi zawierać tylko najważniejsze klasy i moduły i rzadko powinien być aktualizowany. Bardzo pomocne jest także utworzenie kilku diagramów stanów dla najważniejszych klas w systemie. Posyp kilkoma wybranymi schematami sekwencji typowych przypadków użycia, aby ułatwić ludziom szybkie sprawdzenie, jak rzeczy się łączą. Zakładam, że możesz generować diagramy hierarchii klas na podstawie kodu, dzięki czemu problem można łatwo rozwiązać.

Zauważ, że wszystkie diagramy są tworzone po faktycznej implementacji. Jest to zgodne z „działającym oprogramowaniem nad obszerną dokumentacją” i projektem „just-in-time”.

I tak, czytelny kod jest zdecydowanie dokumentacją.

Ogólna architektura projektu i projekt wysokiego poziomu zostałyby wykonane poza zespołami scrumowymi, gdy właściciele projektu tworzą historie.

Musi być dość ogólnego projektu zapisanego w dowolnej formie, aby zobaczyć związek między historiami i oczekiwaniami klienta.

Część projektu potrzebnego do każdej kondygnacji zostanie wykonana podczas planowania i negocjacji z właścicielem produktu.

Większość prac projektowych nad historią zostanie wykonana w sprincie.

Jeśli historia nie jest wystarczająco zdefiniowana do oszacowania, wówczas w bieżącym sprincie można odłożyć pole czasu, aby wykonać wystarczająco dużo pracy projektowej, aby można było stworzyć odpowiednią historię do późniejszego sprintu.

Rozumiem, że projektujesz na wyższym poziomie, z góry ustalonymi wymaganiami na początku projektu. Dobrze dokumentujesz ten projekt.

Następnie, kiedy faktycznie wdrażasz wymaganie, zmieniasz projekt niższego poziomu zgodnie z potrzebą, ale unikasz zmiany projektu wyższego poziomu.

Cóż, tak to wyjaśniono mi pięć minut temu ...

W społeczności Eclipse istnieje dziś podział na tradycyjne narzędzia UML koncentrujące się na MDD, w których model steruje kodem / programowaniem, oraz Omondo, który uważa, że ​​iteracje powinny napędzać proces rozwoju, a na pewno nie tylko model.

Zgadzam się z nimi, ponieważ MDD to bzdury, podczas gdy UML jest naprawdę świetnym sposobem, ponieważ standaryzuje się w celu komunikowania się z innymi członkami zespołu.