Projektowanie w jednym zespole, kodowanie w innym

Będę zaangażowany w projekt, w którym cały projekt oprogramowania jest wykonywany przez lokalny zespół, a projekty te są wysyłane do zespołu offshore w celu kodowania.

Po raz pierwszy spotykam się z projektem o takich cechach i wydaje mi się to dziwne: menedżerowie oczekują od nas opracowania bardzo szczegółowych dokumentów projektowych, więc nie ma miejsca na błędy dla zespołu offshore; z mojego punktu widzenia zmuszają nas do kodowania na papierze, podczas gdy możemy to zrobić w środowisku IDE.

Moje pytanie brzmi, czy to podejście jest dobre, czy udowodnione, prawda? Jakie są główne względy, które proces oprogramowania musi mieć, aby odnieść sukces w naszym projekcie?

Moja opinia:

Jeśli wszystkim, co dasz ludziom offshore, są dokumenty i diagramy, będziesz miał wiele nieporozumień i rozczarowań .

Moja rekomendacja

• Nie udostępniaj im tak wielu dokumentów, ale interfejsy i abstrakcyjne klasy , aby ograniczyć je do swoich celów projektowych .

• Wymagaj od nich korzystania ze znanego standardu nazewnictwa.

• Wymagaj od nich używania testów jednostkowych.

• Wyślij jednego ze swoich projektantów / architektów do ich siedzib w celu nadzorowania procesu, nadal będzie to tańsze niż kodowanie we własnym zakresie, ale uzyskasz lepsze wyniki.

Nazywa się Big Design Up Front, czyli Waterfall. Nie jest to powszechnie uważane za bardzo udaną metodologię. Ale widziałem, jak działa, a kiedy działa, działa bardzo dobrze. To bardzo drogie, aby zrobić dobrze.

Właśnie o to prosili twoi pracodawcy.

Zespoły offshore nie działają tak jak zespoły onshore. Musisz być bardzo, bardzo konkretny co do tego, czego dokładnie chcesz, w przeciwnym razie nie dostaniesz tego, czego chcesz.

Ostatnim projektem byłem projektant oprogramowania. Cały rozwój był na morzu. Nam się udało Tak więc ten proces może działać.

Stworzyłem dużo dokumentacji, ale w żadnym wypadku nie była ona wyczerpująca i nie zawierała instrukcji krok po kroku ani szczegółowych instrukcji dotyczących nazw klas, nazw funkcji itp. Na przykład stworzyłem diagramy sekwencji, przypadki użycia, przepływy pracy, system i integrację diragramy, a także bardziej szczegółową dokumentację projektową w razie potrzeby.

To naprawdę zależy od tego, jak bardzo ufasz rozwojowi offshore. Ufam, że mój zespół offshore jest kompetentnym programistą. To powiedziawszy, podałem ogólny kierunek, ale dałem im swobodę wdrożenia, co zespół offshore uznał za przyjemne. W przeszłości były one bardziej zarządzane mikro. W niektórych sytuacjach prowadziłbym je, stosując wzory projektowe w razie potrzeby. Regularnie przeprowadzałem również przegląd kodu i analizę napisanego przez niego kodu, a także doradzałem przy refaktoryzacji lub czyszczeniu. Ponadto, ponieważ część zespołu miała wypadki z pojazdami rekreacyjnymi, skończyło się na kodowaniu niektórych historii podczas wdrażania, ponieważ skończyło się na niektórych zasobach.

Ponadto myślę, że ten proces naprawdę udaje się tylko dzięki sile twoich technicznych leadów w projekcie i komunikacji między biznesem, projektantem, leadami i programistami. Poświęciliśmy dużo czasu na przeglądanie każdej funkcji i historii i upewnialiśmy się, że potencjalni klienci / zasoby na morzu byli dobrze zorientowani w zakresie wymagań. Jeśli nie zadają pytań podczas przeglądu funkcji / historii, spodziewaj się pewnych problemów. Również praca nie została uznana za zakończoną, dopóki nie nastąpiło zatwierdzenie firmy. Dzięki temu wszyscy byli odpowiedzialni, ponieważ wszystko było śledzone w narzędziu, które zarządzało zwinnym rozwojem.

Jak wspomniała już jedna z pozostałych odpowiedzi, proces rozwoju obejmował standardy nazewnictwa (wbudowane reguły resharpera), pokrycie przypadków testowych (wykorzystywał TDD, Mocking itp.), Więc jeśli istnieje dobry proces kodowania i procedura, to wzrośnie twoje szanse na udany projekt.

Głównym kosztem rozwoju offshore jest komunikacja. Dokumentacja jest jednym ze sposobów komunikacji, jednak dokumenty zwykle nie są w stanie objąć wszystkich szczegółów i potencjalnych zmian.

Nie jestem pewien, jak duży jest twój projekt. Zakładam, że jest duży, w przeciwnym razie korzystanie z zespołu programistów offshore nie jest cenne. Tak więc moje doświadczenie jest

1. Zdefiniuj kod szkieletu, interfejs publiczny, interfejs usługi itp. I wspólnie przejrzyj
2. Zdefiniuj testy akceptacyjne z drugą stroną
3. Podziel duży dokument na małe historie, pracuj w oparciu o małe historie. Duży dokument to po prostu duży obraz całego systemu
4. Ustaw punkty kontrolne opowieści na tydzień lub dwa tygodnie

1 i 2 tak naprawdę dotyczy rozwoju, aby upewnić się, że druga strona dobrze rozumie wymaganie, a obie strony używają tego samego wzorca. 3 i 4 jest częścią metodologii zwinnego rozwoju, ale w przypadku rozwoju offshore trudno jest zastosować pełny zwinny proces.

Myślę, że do pewnego stopnia wszyscy tak pracujemy. Ktoś gdzieś coś zaprojektował, a my kodujemy coś, co jest częścią systemu lub współpracuje z nim. Przykładem jest tworzenie aplikacji opartych na frameworku, takich jak aplikacje inne niż gry na urządzenia mobilne. Zespół projektowy ludzi, którzy zbudowali platformę, podjął wiele decyzji dotyczących interfejsu użytkownika. Kontrolowali wszystko, od nauki pisania aplikacji po sprzedaż aplikacji. Jeśli chcesz sprawdzić, dlaczego ten model się powiódł, spójrz na ilość dokumentacji i narzędzi udostępnianych przez niektórych dostawców.

Innym przykładem są aplikacje internetowe, z których wiele próbuje wdrożyć styl REST. Ten tak naprawdę nie mówi, jak coś zaimplementować, chociaż istnieją specyfikacje dotyczące używania HTTP. W każdym razie należy przestrzegać specyfikacji i zasad przewodnich. Jeśli widzisz wiele dyskusji na temat implementacji REST podczas wymiany stosów lub w miejscu pracy, to tak, jakby architekt powiedział ludziom, aby wdrożyli coś w określony sposób. Myślę, że wciąż jest to udany model, a tylu ludzi podąża za tym stylem.

Z tych dwóch przykładów można zobaczyć, w jaki sposób propagowane są projekty, niektóre jako specyfikacje papierowe, inne zawierają książki, narzędzia i przykłady. Możesz zobaczyć, jak ludzie pytają (objętościowo), próbując uzyskać właściwe zrozumienie z różnymi stopniami, w zależności od standardów / projektów, które starają się stosować. Wystarczy przejść do stackoverflow i obejrzeć;)

Jeśli podasz mi swoją specyfikację, zapytam. Jeśli dasz mi test jednostkowy, koduję i testuję.