Jak można zastosować Agile do aplikacji wymagających złożonego przetwarzania?

12

Większość literatury na temat zwinności wydaje się być stronnicza w stosunku do aplikacji biznesowych typu CRUD, w których użytkownik jest prawie świadomy tego, co dzieje się za kulisami. (W porządku, ponieważ większość pisanego kodu prawdopodobnie należy do tej klasy).

W przypadku tego typu aplikacji związek między historiami użytkowników (wymaganiami) a zadaniami programistycznymi jest w większości prosty: wystarczy podzielić historię użytkownika na kilka zadań.

Istnieje jednak inny rodzaj aplikacji, w którym większość kodu ma do czynienia ze złożonym przetwarzaniem, które nie jest bezpośrednio widoczne dla użytkownika. Przykładami mogą być:

  • Kompilatory
  • Systemy analizy obrazu samochodów samojezdnych
  • Systemy symulacji przepływu płynów

Tutaj relacja zadań i historii użytkowników może być bardzo trudna. Czy istnieją techniki rozwiązania tego problemu, czy jest to coś, co musimy zaakceptować i jak najlepiej wykorzystać?

agile project-management user-story task Frank Puffer
źródło
6
Nie downvoter, ale założę, że to dlatego, że pytanie opiera się na fałszywym założeniu. Złożone systemy IMO są jeszcze bardziej odpowiednie do opracowywania zwinnego stylu, ponieważ są bardziej złożone. Im bardziej złożony system, tym większe prawdopodobieństwo pojawienia się nowych wymagań. Zwinny SwDev został stworzony, aby lepiej obsługiwać pojawiające się wymagania.
RubberDuck,
4
@RubberDuck: „Zakładam, że to dlatego, że pytanie opiera się na fałszywej przesłance.”: IMO, to uzasadniałoby odpowiedź, w której wyjaśniono by fałszywą przesłankę, a nie głos negatywny.
Giorgio
To, czy użycie rozumie logikę, czy nie, jest całkowicie nieistotne dla zwinnego procesu. Do zespołu należy mapowanie historii użytkownika do implementacji ORAZ oszacowanie, ile to zajmie. Jeśli jest to skomplikowane i / lub dużo pracy, zespół może podzielić historię na mniejsze. Rodzaj logiki nie ma znaczenia.
Martin Maat,
2
„Większość literatury na temat zwinności wydaje się być stronnicza w stosunku do aplikacji biznesowych typu CRUD” - I większość literatury na temat Java wydaje się tendencyjna do drukowania napisu „Hello World” na konsoli (lub alternatywnego obliczania n-tej liczby Fibonacciego). To nie znaczy, że to jedyna rzecz, do której Java jest dobra. Powód jest taki sam w obu przypadkach: trudno jest wyjaśnić realistyczne przykłady w poście na blogu lub w samouczku. [Uwaga: jest to komentarz hiperboliczny, próbujący zilustrować podstawę fałszywej przesłanki.]
Jörg W Mittag
1
Zwinne nie wymaga zadań i historii użytkowników. Możesz użyć dowolnej formy specyfikacji. Chodzi o elastyczność.
Frank Hileman

Odpowiedzi:

9

Okazało się, że jest on dłuższy niż planowałem (zaczął jako komentarz), ale mam nadzieję, że dodana długość / szczegóły są pomocne i uważasz je za uzasadnione.

Zwinne nie jest specyficzne dla aplikacji CRUD

Większość literatury na temat zwinności wydaje się być stronnicza w stosunku do aplikacji biznesowych typu CRUD, w których użytkownik jest prawie świadomy tego, co dzieje się za kulisami. (W porządku, ponieważ większość pisanego kodu prawdopodobnie należy do tej klasy).

Myślę, że dzieje się tak, ponieważ łatwiej jest tworzyć łatwe do naśladowania przykłady tego typu, a nie dlatego, że metodologia jest ukierunkowana na tego rodzaju systemy. Jeśli stworzysz niezbyt łatwy do naśladowania przykład, ryzykujesz, że czytelnik utknie, próbując zrozumieć przykład, kiedy Twoim celem było nauczenie czytelnika o zwinnych koncepcjach.

Historie użytkowników! = Wymagania

W przypadku tego typu aplikacji związek między historiami użytkowników (wymaganiami) a zadaniami programistycznymi jest w większości prosty: wystarczy podzielić historię użytkownika na kilka zadań.

Historia użytkownika nie jest tym samym, co wymaganie. To prawda, że ​​może się nakładać w zależności od tego, jak „wysoki poziom” jest wymagany, ale ogólnie nie taki sam. Mam wrażenie, że wpadłeś w tę samą pułapkę, w którą wpadło wielu moich byłych menedżerów: myślenie o historiach użytkowników jako synonimach „wymagań”, podobnie jak w przypadku użytkowników SVN próbujących przejść na Git, ale zachowaj myślenie w kategoriach SVN. (Następnie mają problemy z powodu złych założeń początkowych).

IMHO, kluczowa różnica między wymaganiami a historiami użytkowników polega na tym, że wymagania określają szczegółowo, w jaki sposób powinny zachowywać się niektóre elementy systemu; są to specyfikacje, które obejmują dane wejściowe, wyjściowe, założenia / warunki wstępne, zgłoszone możliwe wyjątki itp. Koncentrują się na tym, co robi system .

OTOH, historie użytkowników koncentrują się na oczekiwanym wyniku dla użytkownika końcowego bez próby stworzenia szczegółowej specyfikacji behawioralnej dla komponentów systemu. Koncentrują się na oczekiwanym doświadczeniu użytkownika .

To, co kiedyś robiłem i to była praktyka, którą mój zespół przyjął, polegało na podziale historii użytkowników na zadania. Twoje zadania mogą być tak szczegółowe lub niejasne, jak chciałeś / potrzebujesz, ale miały one być wskaźnikami postępu w rzeczywistej pracy wykonanej w celu doprowadzenia historii do końca.

Przykład

Z grubsza przypominam sobie USA, nad którymi pracowałem lata temu, w których użytkownicy musieli samodzielnie przypisywać przypadki testowe, aby wszyscy w zespole wiedzieli, nad którymi pracują, aby uniknąć powielania wysiłków; interfejs użytkownika był (n wewnętrzną) aplikacją internetową. Użytkownik widział tylko przycisk, ale historia została podzielona na kilka zadań, które obejmowały pewne szczegóły techniczne dotyczące implementacji itp.

Widoczność użytkownika

Istnieje jednak inny rodzaj aplikacji, w którym większość kodu ma do czynienia ze złożonym przetwarzaniem, które nie jest bezpośrednio widoczne dla użytkownika.

Czy można w jakiś sposób uczynić go widocznym dla użytkownika?

Rozważ GPS. Kiedy spóźnisz się na swoją kolej, nie zobaczysz faktycznego procesu ponownego obliczania trasy, ale użytkownik otrzymuje przydatne informacje zwrotne (np. „Ponowne obliczanie ...”).

Kompilatory mogą wyświetlać ostrzeżenia lub błędy lub zawierać nowe ustawienia / opcje w GUI, aby użytkownicy mogli zobaczyć, że dodano coś nowego. Myślałem, że użytkownikami kompilatorów byliby programiści, prawda? Czy nie widzą dodanego wsparcia dla nowego standardu?

Chociaż obsługa nowego standardu prawdopodobnie byłaby na poziomie funkcji i musiałaby zostać podzielona na historie użytkowników, upewnij się, że przynajmniej w niektórych przypadkach nie próbujesz używać historii, gdy powinieneś używać funkcji ?

Analiza obrazu w samochodzie może być sformułowana w sposób, który pozwala użytkownikowi wiedzieć, że szanse na wypadek samochodu zostały zmniejszone. Na przykład:

Jako pasażer w samochodzie samobieżnym potrzebuję prawdopodobieństwa, że ​​pojazd spowoduje wypadek, uderzając w nierozpoznany obiekt tak blisko zera, jak to możliwe, aby móc podróżować bezpieczniej.

To USA przechwytuje, na wysokim poziomie, rzeczy, które normalnie trzeba by określić, używając kombinacji wymagań funkcjonalnych i niefunkcjonalnych - w tym bezpieczeństwa, ochrony itp.

Wymaganie może jednak dotyczyć bardziej systemu; na przykład:

Funkcja abcw komponencie Amusi mieć zmniejszoną wartość progową tolerancji w algorytmie porównywania obrazów, aby lepiej wykrywać obiekty poruszające się powoli.

Dla mnie byłoby to z łatwością zadanie w ramach wspomnianej powyżej historii użytkownika, zatytułowanej: Zmniejszenie tolerancji działania,A.abc a następnie uwzględnienie w niej innych istotnych szczegółów.

W przypadku systemu symulacji płynów możesz nawet mieć pasek postępu, który zawiera informacje zwrotne na temat zadań wykonywanych w tle przez system, jeśli ma to sens. (Zawsze istnieje sposób na poinformowanie użytkownika o czymś, chociaż możesz chcieć uniknąć spamowania).

Nie wiem wystarczająco dużo o konkretnych domenach, o których wspomniałeś, aby wymyślić lepsze i / lub bardziej realistyczne przykłady, ale jeśli jest coś na wynos, możesz użyć różnych sposobów przekazywania opinii użytkownikom na temat czegoś mniej widocznego, co system może działać, tzn. mogą istnieć sposoby na uczynienie niewidzialnych rzeczy nieco bardziej widocznymi. (Nawet jeśli sprowadza się do napisania zestawu uwag do wydania, które dokumentują, o ile szybsza jest wydajność systemu dzięki twoim wysiłkom itp.)

Związek między historiami a zadaniami

Tutaj relacja zadań i historii użytkowników może być bardzo trudna.

Nasze podejście polegało na skoncentrowaniu historii użytkowników na tym, co było żądaniem, dlaczego zostało złożone i jakie rzeczy muszą być prawdziwe, aby uznać USA za „zrobione”. To, jak zawsze pozostawiono poza USA i pozostawiono programistom.

Deweloperzy podzielą problem opisany w USA na zestaw zadań, nad którymi będą pracować.

Mówię to jako ktoś, kto w przeważającej części zajmował się programowaniem po stronie serwera, co jest prawdopodobnie tak „niewidoczne”, jak to tylko możliwe dla użytkownika końcowego.

W zależności od tego, co musiałem zrobić, czasami korzystałem z AJAX, aby wyświetlać prostą animację / gif „ładowanie ...”, aby użytkownik wiedział, że musi poczekać chwilę na ukończenie czegoś innego, nie otrzymując złego wrażenia. Czasami było to tak proste. Zadanie do tego byłoby właściwe.

Inny paradygmat, praktyka i doświadczenie

Czy istnieją techniki rozwiązania tego problemu, czy jest to coś, co musimy zaakceptować i jak najlepiej wykorzystać?

Poza zaakceptowaniem zmiany paradygmatu, ćwiczeniem i gromadzeniem doświadczenia, prawdopodobnie niewiele więcej do powiedzenia. Często widziałem ludzi, którzy próbowali przejrzeć skróty. Odradzałbym to, szczególnie jeśli zaczynasz. W miarę zdobywania doświadczenia możesz pozwolić sobie na pewną elastyczność, ale unikaj osłabiania siebie.

Biorąc pod uwagę poprzednie sformułowania, nadal myślisz o opowiadaniach, jakby były one „przemianowanymi wymaganiami”, co moim zdaniem jest fałszywym założeniem. Myślę, że jest to objaw głębszego problemu dotyczącego podstawowych różnic między podejściami zwinnymi i nieagresywnymi.

Po drugie, uważam, że powinieneś zaakceptować fakt, że zwinność jest zmianą paradygmatu w porównaniu z wodospadem, co oznacza, że ​​chociaż proces ma podobne cele, podchodzą do niego na różne sposoby. (Pomyśl SVN kontra Git, jeśli to pomoże).

Spróbuj poprawić swoje obecne zrozumienie różnic koncepcyjnych między wymaganiami a historiami użytkowników i zaakceptuj, że to nie to samo.

Uczenie się na twoich sprintach - retrospektywy

To, czego nie mogę wystarczająco podkreślić, to retrospekcja między Scrum Master a deweloperami na końcu każdego sprintu. To miejsce, w którym dyskutują o rzeczach, które „poszły dobrze” lub „nie poszły dobrze” w uczciwy / przejrzysty sposób, i jakie możliwe zmiany zostaną wprowadzone w następnym sprincie w celu rozwiązania kwestii „nie poszło dobrze” .

To pozwoliło nam się dostosować, a nawet uczyć się na podstawie doświadczeń innych. Zanim się zorientowaliśmy, znacznie się poprawiliśmy, mierząc ogólną spójność prędkości naszego zespołu.

kod_dredd
źródło
„Historie użytkowników! = Wymagania”: Nie chciałem powiedzieć, że oba są synonimami. Nie każde wymaganie jest historią użytkownika. Myślę jednak, że wszystkie historie użytkowników są wymaganiami. Widzę wymagania jako hierarchiczną strukturę, w której historie użytkowników są jednym określonym poziomem szczegółowości. Zgodziłbyś się?
Frank Puffer
@FrankPuffer Myślę, że przeglądanie historii użytkowników tak, jakby były one na innym poziomie w hierarchii wymagań, zasadniczo łączy różne koncepcje. Po stronie zwinnej hierarchia wygląda bardziej jak: Tematy >> Epopeje >> Funkcje >> Historie użytkowników >> Zadania . Wymagania są zwykle podzielone na wymagania funkcjonalne i niefunkcjonalne w bardziej tradycyjnym podejściu do Wodospadu, ale nie spotkałem się z faktyczną hierarchią; powiedziawszy, nie zdziwiłbym się, gdyby ktoś rekurencyjnie podzielił wymóg na mniejsze „wymagania” podrzędne. W każdym razie łączysz różne koncepcje.
code_dredd
Systemy zarządzania wymaganiami, takie jak PTC Integrity, traktują wymagania jako hierarchię. Może to być zaletą przy mapowaniu wymagań do dokumentu specyfikacji.
Frank Puffer,
@FrankPuffer Tak, dlatego powiedziałem, że nie będę zaskoczony. To powiedziawszy, zastanawiam się, że moja odpowiedź wyjaśniła ci wszystko. Czy pomocna była analogia SVN vs Git? (Zakłada się, że znasz oba systemy, co wydawało się rozsądne w kontekście rozwoju oprogramowania.)
code_dredd
Ok, źle odczytałem „nie” jako „chciałbym”. I tak, uważam twoją odpowiedź za bardzo pomocną i prawdopodobnie ją zaakceptuję. Prawdopodobnie potrzebuję trochę czasu, aby przyzwyczaić się do tego, aby nie traktować historii użytkowników jako wymagań.
Frank Puffer,
4

W takich przypadkach z pewnością można zastosować zasady zwinne. W jaki sposób?

  • Kompilatory mogą mieć nowe funkcje językowe dodane później w osobnych historiach użytkowników
  • Systemy analizy obrazu mogą mieć nowe funkcje dodane jako różne klasyfikacje obrazów
  • Systemy symulacji przepływu płynów mogą uwzględniać w swoich symulacjach różne aspekty modelu

Nie musisz jeść całego słonia jednym kęsem. Zwinny prosi tylko o pokazanie, że wyczyściłeś talerz przed kolejną porcją słonia.

candied_orange
źródło
Nadal uważam, że pozostanie co najmniej jedna historia użytkownika, która wymaga wielu tak zwanych podstawowych funkcji. Często nie zmieszczą się w jednym sprincie. Jak sobie z tym poradzić?
Frank Puffer,
1
Mierzysz skuteczność za pomocą działających aplikacji, które klienci mogą przetestować, zobaczyć lub dotknąć. Jeśli tak jest, daj im zabawkę, która w ten sposób generuje poczucie postępu. Na przykład prawdopodobnie nie możesz wypuścić samochodu samobieżnego podczas pierwszego sprintu, ale możesz zrobić demo pokazujące, jak twoje algo radzi sobie z ludźmi. Później, jak rozpoznaje sygnały i zwierzęta. Później, jak mierzy odległości, rozmiary itp. Samobieżny samochód jest daleko, daleko, w odległym sprincie, który wie, czy to się kiedykolwiek wydarzy.
Laiv
2
@Laiv: Byłoby fajnie, ale nie jestem pewien, czy to działa. W skrócie, po kilku pierwszych sprintach oprogramowanie nie będzie w stanie zrobić nic, z czym mógłby się odnosić klient. Będziesz miał postęp techniczny, ale przekazanie go klientowi będzie trudne, jeśli nie niemożliwe.
Frank Puffer,
2
Dlaczego? Ponieważ został napisany na Stone przez kogoś obcego do twojego projektu? Oczekuję, że Agile dostosuje się do moich potrzeb, a nie inaczej. Jeśli powiem, że mogę nauczyć cię jeździć na łyżwach w ciągu 4 tygodni, a raz na 5. nadal nie możesz stać, czy to znaczy, że nie uczysz się jeździć na łyżwach? A może po prostu zajmie Ci to trochę dłużej? Zwinny manifest nie został napisany na kamieniu, a zasady Scruma nie są przykazaniami Tend.
Laiv
2
Celem sprintu jest włączenie klienta do iteracji. Aby komunikować się z nimi za pomocą dostarczonego kodu. Nie plany i obietnice. Wymaga to skupienia się na rozwiązaniu problemu. Nie wymaga, aby pierwsza rzecz, którą dostarczysz, była osadzona w kamieniu. Wymaga to udowodnienia, że ​​warto płacić każdy sprint.
candied_orange
1

Uważam, że ludzie, którzy stosują się wyłącznie do historii użytkowników, albo po prostu wezmą udział w bardzo głupich ćwiczeniach wymyślania dalekosiężnych sposobów, w jakie zmiany techniczne zaplecza wpływają na użytkownika (oczywiście bez wiedzy użytkownika, ponieważ są po prostu naiwniakami użytkownik i mówisz o skomplikowanych zmianach w linii potoku analizy danych lub coś w tym rodzaju), albo całkowicie stracą na tym „jak możemy zorganizować tę pracę!?!”

Myślę, że oczywistym rozwiązaniem jest bycie bardziej pragmatycznym. Jeśli praca ma charakter techniczny i nie ma szczególnie zauważalnego wpływu na użytkownika, nie trać snu, próbując wyjaśnić, jak to działa. Po prostu wybierz oczywisty i prosty sposób, w jaki może przynieść korzyści użytkownikom, a następnie zorientuj historię wokół szczegółów niezbędnych deweloperom do wykonywania swoich zadań. Uważam to za niezwykle frustrujące, gdy organizacja producentów upiera się przy braku informacji technicznych w historii, gdy jest to absolutnie konieczne. To po prostu niezbyt całościowy pogląd na to, czym tak naprawdę jest ten artefakt (historia). Jak myślą, że istnieje tylko dla nich, w większości przypadków jest to ważne również dla inżynierów.

W przypadku większości tych zadań technicznych istnieje niewielka niepewność w odniesieniu do wpływu na użytkownika, niezależnie od tego, czy poprawia to wydajność, aby przyszłe dostawy były szybsze, poprawiając wydajność, wpływ na niezawodność. Nie są tak naprawdę tym, o czym ludzie myślą, gdy myślą „historie użytkowników”, ale jeśli firma chce zrozumieć, dlaczego zaciągnąłbyś dług techniczny lub coś w tym celu, wyjaśnienia te są zwykle najprostsze do przekazania.

tl; dr nie pozwól, aby scrumnazi utrudniły ci życie po prostu dlatego, że są zbyt duże, by się przystosować. Bycie adaptacyjnym to w końcu podstawowa koncepcja zwinności. Ścisłe przestrzeganie Scruma lub Agile zwykle leci w twarz lub pragmatyzm i praktyczność (co tak naprawdę działa najlepiej).

evanmcdonnal
źródło
Jestem za elastycznością, ale szczerze mówiąc, użytkownik nie dba szczególnie o szczegóły techniczne, o ile ich historie są satysfakcjonujące. Nie musisz być „zwinny”, aby mieć dobre wymagania; a przez dobre wymagania mam na myśli wymagania, którym każdemu towarzyszy test akceptacyjny, który jednoznacznie potwierdza, że ​​wymaganie jest spełnione. Ludzie, którzy „angażują się w bardzo głupie ćwiczenia”, oczywiście robią to źle, ale to nie znaczy, że stosują jakieś pojęcie „ścisłego scrumu”.
Robert Harvey
@RobertHarvey Zgadzam się, że szczegóły techniczne nie mają znaczenia dla użytkownika, ale moja uwaga jest taka, że ​​artefakty zawierające historie użytkowników mają szerszy cel niż tylko komunikowanie, jak rzeczy działają dla użytkownika (a przynajmniej powinny). Jak egzekwować wymagania związane z architekturą, rozszerzalnością, wydajnością itd., Jeśli piszą wyłącznie historie użytkowników? Podejście oparte wyłącznie na historii użytkownika zachęca programistów do pisania słabej jakości kodu. I to nie użytkownicy czytają „historie użytkowników”, to dev i qa, głupotą jest celowe wykluczanie istotnych informacji, ponieważ są one techniczne.
evanmcdonnal
0

Myślę, że problemem jest nadanie historyjkom użytkowników znaczenia, którego nie mają. Scrum używa terminu PBI lub Backlog Produktu, który moim zdaniem jest nieskończenie lepszy. PBIS będzie często wykonaj format historię użytkownika, na przykład, może masz PBI jak „Abonenci powinni móc przeglądać swoje dane abonamentu”, ale również może równie dobrze mieć PBI jak „Utwórz procedurę przechowywaną, aby uzyskać dane abonenta „.

Historie użytkowników są narzędziem . Pomagają ci tworzyć opisy funkcji i wymagania oparte na postawieniu się w sytuacji użytkownika. Ale tak jak klucz jest bezużyteczny, gdy trzeba zawiesić zdjęcie, zdarza się, że historia użytkownika może nie być potrzebna.

To powiedziawszy, wiele drużyn gra po prostu szybko i swobodnie z częścią „użytkownika”. Mogą mieć „historie użytkowników”, takie jak „Jako programista, muszę mieć możliwość wywołania procedury składowanej w celu uzyskania szczegółów subskrybenta”, zasadniczo „historii programisty”. Jest to równie ważna opcja, ale osobiście twierdzę, że tak długo, jak potrafisz opisać, co należy zrobić, i wymyślić zestaw kryteriów akceptacji, nie ma znaczenia, czy masz za nią prawdziwą historię użytkownika.

Chris Pratt
źródło
1
Nie zgadzam się z tym, z wyjątkiem bardzo dziwnych i rzadkich przypadków. W Scrumie HOW leży w gestii zespołu programistów, a nie właściciela produktu. Jednak właściciel produktu powinien być odpowiedzialny za PBI. Tak więc PBI, takie jak „tworzenie procedury składowanej”, pozbawia zespół programistów prawa wyboru HOW. PBI, niezależnie od tego, czy jest to historia użytkownika, czy nie, powinny wyjaśniać, jaką wartością biznesową jest wykonywanie PBI. Tworzenie procedury przechowywanej nie dotyczy wartości biznesowej, lecz szczegółów implementacji.
RibaldEddie
Nie o to chodzi. To był tylko przykład. Możesz po prostu zmienić „procedurę przechowywaną” na coś ogólnego, np. „Sposób”. Chodzi o to, że niekoniecznie musi to być historia użytkownika.
Chris Pratt
cały sens przykładu ma być przykładem. Jeśli twój przykład „nie ma sensu”, jaki jest sens tego przykładu?
RibaldEddie
-3

Tego rodzaju aplikacje są dokładnie tymi, w których występuje różna wiedza specjalistyczna i będą się dalej rozwijać. Członkowie zespołu będą mieli zróżnicowane wykształcenie, różne projekty hobbystyczne i różne doświadczenia zawodowe w przeszłości, różne umiejętności. Ponadto, jeśli ktoś opracuje określony fragment kodu, można oczekiwać, że programista będzie tym, który zna kod najlepiej. Dlatego sensowne może być przekazanie tego samego dewelopera dalszym zadaniom programistycznym obejmującym ten sam fragment kodu.

W najpopularniejszym zwinnym procesie Scrum planuje się pokera, w którym do każdego zadania przypisany jest poziom trudności. Poziom trudności nie zależy od osoby, która wykonuje to zadanie zgodnie z procesem. Następnie podczas sprintu ludzie są uważani za jednorodnych, dzięki czemu każda osoba będzie mogła wybrać każde zadanie i je zrealizować. To założenie obowiązuje w prostych projektach typu CRUD. Ale w bardzo złożonych i trudnych projektach na pewno nie.

Nie użyłbym zwinnego procesu do tego rodzaju projektów. Najlepszym wyborem jest unikanie formalnych procesów i po prostu dobre zarządzanie projektami. Decydując, kto wdraża daną funkcję, należy wziąć pod uwagę, kto ma najlepsze umiejętności potrzebne do tej funkcji i najlepszą znajomość istniejącego kodu. Nie jest do tego potrzebny żaden proces. Prawdopodobnie będziesz chciał napisać dobre dokumenty projektowe dla wszystkich funkcji i aktualizować je. Pamiętaj, że nie promuję tutaj modelu przypominającego wodospad: nie wszystkie dokumenty projektowe zostaną napisane na początku projektu; zamiast tego napiszesz nowe dokumenty projektowe, ponieważ potrzebne są nowe funkcje.

juhist
źródło
5
Nie bardzo związane z moim pytaniem, ale zawsze pozwalanie osobie z najlepszymi umiejętnościami wdrożyć jakąś funkcję może być niebezpieczne. Utrudnia to rozpowszechnianie wiedzy w zespole. Jeśli wymagana jest konserwacja, a ekspert opuścił zespół lub jest tymczasowo niedostępny, będziesz miał kłopoty.
Frank Puffer,
@FrankPuffer W przypadku niektórych wymienionych systemów, np. Samochodów samojezdnych, jeśli ekspert opuści zespół, masz kłopoty. Kropka. Chociaż prawdopodobnie nie jest tak, że kodowanie powinno być scentralizowane, jest również całkowicie nieuzasadnione zakładanie odpowiedniego „rozpowszechniania wiedzy”, aby umożliwić wymianę eksperta w rozsądnie krótkim czasie. Są to ludzie, którzy spędzili ponad dekadę na badaniu problemu i prawdopodobnie znajdują się na szczycie swojej dziedziny. Prawdopodobnie będziesz potrzebować wielu takich osób o różnych umiejętnościach. Takie projekty są z natury ryzykowne.
Derek Elkins opuścił SE