Projektowanie w jednym zespole, kodowanie w innym

28

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?

Carlos Gavidia-Calderon
źródło
5
@mike: Oprogramowanie Spacecraft różni się nieco od większości programów. Musi cały czas działać idealnie, w przeciwnym razie może dojść do utraty życia i bardzo drogich aktywów. Zobacz fastcompany.com/28121/they-write-right-stuff
Robert Harvey
9
Wydaje mi się, że zespół offshore jest tańszy, czy jest dwa razy większy niż zespół projektowy? Czy ma jakieś realne zalety w stosunku do zespołu wewnętrznego? np. czy mówią naturalnym językiem użytkowników końcowych, a ty nie? Czy mają jakiś talent, którego nie masz w domu? Jeśli nie, widzę, że twoja firma ma zły przypadek zatrucia PHB .
ZJR
1
@mike: Myślę, że dokładniej byłoby powiedzieć, że w większości programów niewielką liczbę błędów uważa się za akceptowalną, ponieważ oprogramowanie wolne od błędów jest asymptotą, a usunięcie pozostałych błędów jest bardzo kosztowne.
Robert Harvey
9
Sugeruję, abyś natychmiast zaczął szukać innej pracy. Programiści nie są wymiennymi trybikami, co jest podstawowym założeniem tego rodzaju aranżacji. Oddzielenie projektu od rozwoju w ten sposób - na lądzie lub na morzu - gwarantuje rozłączenie między klientem a deweloperami, co sprawia, że ​​prawdopodobieństwo awarii jest wysoce prawdopodobne.
Steven A. Lowe,

Odpowiedzi:

36

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.

Tulains Córdova
źródło
2
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.
Robert Harvey
32
... Co jest częścią tego, dlaczego wiele zmian wraca na ląd do USA; takie podejście do projektowania na lądzie, rozwijania na lądzie, a następnie debugowania z powrotem na lądzie wymaga posiadania tych samych zasobów na lądzie, których użyłbyś do opracowania całej zupy do orzechów. W każdym innym procesie produkcyjnym, w którym bezpośrednie materiały i nakład pracy związany z robieniem rzeczy są wysokie, podejście na morzu ma sens. Kiedy projekt tego, co tworzysz, stanowi nie tylko większość kosztów, ale może równie dobrze być produktem końcowym, rozwój offshore staje się bardziej zbędny.
KeithS
@KeithS Świetny komentarz. Zgadzam się z tobą% 110.
Tulains Córdova
2
Zmuszenie ich do korzystania z klas i interfejsów, które wymyśliłeś bez napisania własnego kodu, jest przepisem na katastrofę.
Mike Weller,
2
@Euphoric Pomiędzy pisaniem abstract void calculateDroneTrajectoryBasedOnCNNNewsFeed()a faktyczną implementacją jest długa przerwa .
Tulains Córdova
26

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.

Robert Harvey
źródło
Czy możesz bardziej szczegółowo opisać „bardzo konkretne”? Czy musiałem dostać się do poziomu pseudokodu metody dołączania?
Carlos Gavidia-Calderon
8
Pseudokod zwiększy twoje szanse na uzyskanie kodu od zespołu offshore dokładnie tak, jak tego chcesz. Jak zauważyli inni, proces efektywnego offshoringu może być bardziej kosztowny niż utrzymywanie całej pracy w domu. Ale to nie twoja decyzja.
Robert Harvey
2
Nie powinno tak być It's very expensive when it goes wrong. :-)
LarsTech
@LarsTech: Właśnie dlatego dodatkowy koszt prawidłowego wykonania jest uzasadniony.
Robert Harvey
Pseudokod lubią podejmować takie same wysiłki, jak pisanie prawdziwego kodu, + ogólne koszty komunikacji morskiej
Web Devie
16

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.

Jon Raynor
źródło
Czy korzystasz z jakiegoś konkretnego zwinnego procesu? Może szyty na miarę?
Carlos Gavidia-Calderon
2
To nie była czysta zwinność, bardziej jak zaplanowane iteracje. Wszystko zostało zaplanowane z góry, a następnie podzielone na 2 tygodnie. Stosowaliśmy sprawne procesy w każdej interakcji. Stosowane wykresy prędkości i spalania, standardowy dzienny wstań, a następnie godzina lub dwie rozmowy telefoniczne na morzu. Zdecydowanie spędzaj dużo czasu na telefonie na morzu, ale nasz idealny dzień rozwoju wynosił 6 godzin, aby uwzględnić czas komunikacji.
Jon Raynor
2
Uwaga do siebie: wyeliminuj pojazdy rekreacyjne z przyszłych wersji oprogramowania.
Robert Harvey
Czy uważasz, że Twój sukces miał więcej wspólnego z wyborem odpowiedniego zespołu offshore, czy po prostu zaufaniem, że zrobią to dobrze bez mikrozarządzania? Czy uważasz, że technika „planowanych iteracji” była kluczowa dla Twojego sukcesu?
Robert Harvey
1
@Jess - Nie, zespół jest odpowiedzialny tylko za dostarczanie zatwierdzonych historii i funkcji (funkcjonalność). Przyszła funkcjonalność nie jest dostarczana, chociaż konstrukcja oprogramowania zwykle pozwala na pewną elastyczność, ale dostarczamy tylko to, o co prosiliśmy.
Jon Raynor,
2

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.

alistairw
źródło
1

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

imel96
źródło