Jak zdobyć osobistą praktykę w metodologii rozwoju wagi ciężkiej?

Jestem w nowej pracy, w której projekt musi spełniać surowe standardy jakości, być mocno udokumentowany, szczegółowo zarządzany, diagramy UML i wszystkie te rzeczy, które są przeciwieństwem „kodowania kowbojskiego”, w którym większość mojego dotychczasowego doświadczenia zawodowego była . Pomyśl o tym, jak powstaje oprogramowanie na dużą skalę dla przemysłu lotniczego i kosmicznego.

Cieszę się, że mogę opuścić chaos kodowania kowbojskiego i jestem ciekawy, jak dobrze sprawdzają się metody inżynierii ciężkiej. Ale jak szybko zdobyć doświadczenie w stosowaniu ciężkich metod?

Poza tym po prostu bycie w pracy przez pewną liczbę miesięcy / lat.

Za pomocą zwykłego języka lub nowego interfejsu API można zhakować program testów zabawek, czytać, celowo popełniać błędy, aby zobaczyć, co się dzieje, itp. Aby stać się dobrym w jeździe na rowerze lub grze na instrumencie muzycznym, niezbędna jest praktyka. Łatwo jest podnieść flet i spędzić pół godziny każdego dnia; nie trzeba dołączać do orkiestry ani być etatowym konsultantem ds. fletów. Ale jak ćwiczyć działania inżynierii oprogramowania, które są duże, złożone, angażują zespoły, a większość z nich dotyczy komunikacji i planowania oraz unikania nieporozumień i przekraczania limitów harmonogramu i budżetu?

Nie wydaje się to możliwe w pojedynkę. Czy istnieje sposób, aby niewielka liczba osób mogła symulować zaprojektowanie całego dużego projektu na małą skalę w krótkim czasie (jeden dzień)?

Czy istnieje sposób, aby niewielka liczba osób mogła symulować zaprojektowanie całego dużego projektu na małą skalę w krótkim czasie (jeden dzień)?

Tak, jest to do pewnego stopnia możliwe. Około 10 lat temu wziąłem udział w warsztatach na konferencji OOP w Monachium, podczas których 16 osób otrzymało zadanie zgrubnej analizy i zaprojektowania oprogramowania dla małego biznesu. Pierwsza połowa dnia polegała głównie na znalezieniu struktury zespołu do rozwiązania zadania z 16 osobami, a druga połowa dnia skoncentrowana na rozwiązaniu zadania z tym zespołem.

W pierwszej części poprowadzono nas do podziału 16 osób na czteroosobowe grupy. Każda czteroosobowa drużyna musiała wypracować sugestie dotyczące struktury zespołu (pod presją czasu), a następnie zastosowano procedurę strzelania w celu podjęcia decyzji, która struktura zespołu może być najlepsza i powinna zostać wykorzystana w drugiej części warsztatów .

Niestety, podczas pierwszej części, popełnialiśmy błąd, próbując dać każdej z 16 osób pracę w ramach planowanej struktury zespołu. Ten błąd doprowadził do chaosu w drugiej połowie - ponieważ 16 osób to zdecydowanie za dużo, aby rozwiązać takie zadanie. Rozwiązaniem może być podzielenie 16 osób na mniejsze zespoły lub wybranie 3 lub 4 osób do wykonania głównej pracy, ale w czasie, gdy tego nie zauważyliśmy.

Nadal mam wrażenie, że wiele się nauczyłem o typowych problemach, które mogą napotkać tego dnia w większych organizacjach projektowych. Nie wiem, gdzie możesz odwiedzić takie warsztaty gdzieś blisko ciebie, ani kto oferuje takie rzeczy w dzisiejszych czasach, ale jeśli masz szansę, zdecydowanie polecam wziąć udział.

Zacznij od listy kontrolnej . (Wiedziałeś, że to był pierwszy krok, prawda?)
Upewnij się, że na liście kontrolnej znajduje się cała standardowa dokumentacja dla twojego bieżącego projektu. to znaczy. Diagram UML, specyfikacja funkcjonalna, projekty wysokiego i niskiego poziomu itp. Inżynier systemów we mnie zasugeruje użycie RTVM (macierz weryfikacji zgodności wymagań)

Wybierz przykładowy program do pracy. Jeśli nie możesz go wymyślić, przejdź do Google „code katas” lub sprawdź archiwum wyzwań Google Codeejam. Lub po prostu zbuduj kalkulator. :-)

Zbuduj funkcjonalną specyfikację dla przykładowego programu. Następnie przejdź do projektu wysokiego poziomu, diagramu UML itp. Zbuduj go zgodnie ze specyfikacją. Sprawdź to. Za każdym razem, gdy znajdziesz znaczną wadę w specyfikacji (zgodnie z twoimi obecnymi praktykami pracy), musisz cofnąć się do tego etapu SDLC i dokonać przeglądu, zanim przejdziesz dalej.

W pierwszej rundzie idź dalej i utrzymuj ją na niskim poziomie. Cykliczne przechodzenie przez ten proces jest ważniejsze niż przesadzanie na jakimkolwiek etapie. Do kolejnych rund dodaj funkcje, które przerwałeś. Śledzenie, rejestrowanie, analiza wydajności, rusztowanie testowe itp. To, co chcesz dodać, będzie zależeć od tego, czego Twój pracodawca oczekuje od Twojej prawdziwej pracy.

Po kilkukrotnym powtórzeniu cyklu projektowania / budowania / testowania / powtarzania nabędziesz umiejętności i doświadczenia w komponentach „wagi ciężkiej”, które Cię teraz niepokoją. Iteracje pokażą również wzajemne powiązania między poszczególnymi etapami i wygenerowaną dokumentację. Cenna lekcja pokazuje, jak 5-minutowa zmiana kodu może wywołać efekt wielogodzinnego tętnienia w innych miejscach dzięki aktualizacjom dokumentów i wymaganiom testowym.

Doświadczenie w ćwiczeniach „wagi ciężkiej” pochodzi tylko z robienia rzeczy prawdziwych. Nie ma sposobu, aby skutecznie ćwiczyć to w izolacji. Możesz to jednak przestudiować. Istnieje wiele studiów przypadków i źródeł, które można studiować i rozważać.

Jednak nie wszystkie praktyki, które widzisz lub studiujesz, są koniecznie pozytywne. Tworzenie oprogramowania jest sprawą płynną, a to, co dziś wydaje się trudne i surowe, jutro może wydawać się głupie i zbędne. Dzieje się tak zarówno dzięki nowym narzędziom, jak i doświadczeniom, które przechodzą od startupów do bardziej konserwatywnych organizacji.

Zasadniczo wydaje się, że zarządzanie zmianami i ryzykiem ma unikalny kształt dla każdej organizacji. Najlepiej jest zachować otwarty umysł, ale nie przejmuj zbyt wielu założeń od zespołu do zespołu.