Jak radzić sobie z różnymi stylami programistycznymi (odgórne vs. oddolne) w zespole?

Załóżmy, że właśnie zacząłeś pracować w bardzo małym zespole przy {obecnie stosunkowo małym, ale mam nadzieję, że większym później} projekcie. Należy pamiętać, że jest to rzeczywisty projekt przeznaczony do wykorzystania przez innych programistów w prawdziwym świecie, a nie jakiś projekt akademicki, który ma zostać złomowany pod koniec semestru.
Jednak kod nie został jeszcze udostępniony innym, więc żadna decyzja nie została jeszcze podjęta.

Metodologie

Jeden z was lubi zacząć kodować i dopasowywać elementy do siebie, zanim będzie trzeba mieć jasny obraz tego, jak dokładnie wszystkie komponenty będą oddziaływać (projekt oddolny). Inny z was lubi najpierw wykonać cały projekt i dopracować szczegóły wszystkich komponentów i komunikacji przed kodowaniem rozwiązania.

Załóżmy, że pracujesz nad nowym systemem, a nie naśladujesz istniejące, dlatego nie zawsze jest oczywiste, jak powinien wyglądać właściwy projekt końcowy. Tak więc, w twoim zespole, różni członkowie zespołu czasami mają różne wyobrażenia o tym, jakie wymagania są nawet niezbędne dla produktu końcowego, nie mówiąc już o tym, jak zająć się jego zaprojektowaniem.

Gdy programista oddolny pisze kod, programista odgórny odrzuca go z powodu potencjalnych przyszłych problemów przewidzianych w projekcie, mimo że kod może rozwiązać dany problem, uważając, że ważniejsze jest poprawne zaprojektowanie projektu przed próbą kodowania rozwiązania problemu.

Gdy programista odgórny próbuje wypracować pełny projekt i przewidywane problemy przed rozpoczęciem pisania kodu, programista oddolny odrzuca go, ponieważ programista oddolny nie sądzi, że niektóre problemy faktycznie pojawią się w praktyce i sądzi, że projekt może wymagać zmiany w przyszłości, gdy wymagania i ograniczenia staną się jaśniejsze.

Problem

Problemem, który to spowodowało, jest to, że programista oddolny marnuje czas, ponieważ programista odgórny często decyduje, że rozwiązanie, które napisał programista oddolny, powinno zostać złomowane z powodu wady projektowej, co powoduje konieczność ponownego -pisz kod.

Deweloper odgórny marnuje czas, ponieważ zamiast zrównoważyć pracę, teraz odgórny programista często siada, aby wypracować poprawny projekt z programistą oddolnym, szeregując te dwa elementy do tego stopnia, że ​​może być nawet szybszy za 1 osobę do wykonania pracy niż 2.

Obaj programiści chcą nadal współpracować, ale nie wydaje się, aby kombinacja faktycznie pomagała obu z nich w praktyce.

Cele

Wspólnymi celami są oczywiście maksymalizacja efektywności kodowania (tj. Zminimalizowanie straty czasu) i napisanie przydatnego oprogramowania.

Pytanie

Mówiąc wprost, jak rozwiązać ten problem i poradzić sobie z tą sytuacją?

Jedynym skutecznym rozwiązaniem, które mogę wymyślić, nie marnuje czasu, jest pozwolenie każdemu deweloperowi na podążanie własnym stylem projektowania. Ale jest to trudniejsze, niż się wydaje, gdy przeglądasz kod i faktycznie musisz zatwierdzać zmiany innych, i gdy próbujesz zaprojektować spójne ramy dla innych.

Czy jest lepszy sposób?

Oczywiście oboje się mylą.

Ten oddolny hakuje kod i nigdy nie wyprodukuje czegoś, co robi to, co powinien - będzie to ciągła rezygnacja, gdy zostaną określone nieznane wymagania.

Odgórny facet może poświęcić tyle samo czasu na architektoniczną wizję i nie zrobić nic produktywnego.

Środek jest jednak idealny - jeśli znasz cele, do których dążysz (które osiągasz dzięki szeroko zakrojonej pracy projektowej) i zaczynasz kodować je (bez szczegółowego planowania), wówczas czerpiesz korzyści z systemu, który jest zarówno zorganizowane, jak i skutecznie opracowane.

Nawiasem mówiąc, nazywa się Agile (nie wersja BS Agile, że niektóre osoby ćwiczą tam, gdzie procedury są ważniejsze niż działające oprogramowanie), ale prawdziwa Agile, która kontynuuje pracę w kierunku często opisywanego i rozumianego celu końcowego.

Aby rozwiązać problem tutaj, spróbuj podejść zwinnego (Kanban jest prawdopodobnie najlepszy), który zmusi odgórnego faceta do wykonania pracy i zmusi oddolnego faceta do planowania tego, co on chce osiągnąć.

Dwaj programiści muszą zachować wzajemny szacunek .

Osoba z góry na dół musi szanować fakt, że osoba z dołu do góry mogła wymyślić coś, co faktycznie działa. Jak powiedział mi jeden z „ilościowych” profesorów: „Model roboczy jest wart 1000 domysłów”. W takim przypadku osoba z góry na dół powinna rozważyć ponowne wykonanie swojego „projektu”, aby uwzględnić pracę osoby z dołu do góry.

Osoba oddolna powinna również szanować „strukturę” osoby odgórnej i zdawać sobie sprawę, że może ona być dobra w celu uniknięcia marnowania wysiłku, rozwiązania niewłaściwego problemu, zejścia z tematu itp. Koder oddolny powinien przynajmniej pamiętać, co osoba z góry na dół próbuje to zrobić, i spróbuj rozwiązać przynajmniej obawy z góry na dół , jak wyrażono w ramach. Byłoby to prawdą, nawet jeśli dolna górna część nie zgadzałaby się z częściami samego frameworka.

Możesz zminimalizować straty czasu spędzane przez każdego programistę, dzieląc duże zadania na wiele mniejszych i bardziej ukierunkowanych. Niech ściśle ze sobą współpracują, aby żadne z nich nie wyprzedziło się zbytnio. Krótkie sprinty i małe przedmioty dostawcze mają długą drogę. Łatwiej jest naprawić mały błąd niż duży.

Może się to wydawać sprzeczne z intuicją w stosunku do celu, ale programowanie w parach działa. Są rzeczy, których po prostu nie złapiesz od razu, czasami przez kilka godzin, a nawet dni. Jeśli nie ma mowy o wspólnej pracy nad zadaniami, spróbuj przeglądać kod / testy częściej w ciągu tygodnia.

Informuj wszystkich na bieżąco!

Jeśli widzisz, jak deweloperzy wyrzucają kod, ponieważ byli w swoim własnym świecie, musisz złapać i pogodzić konflikty tak szybko i skutecznie, jak to możliwe. Twój szef to doceni, a zespół doceni to, że nie będzie musiał wyrzucać tygodniowej pracy, ponieważ nie wiedział, co robi ten drugi facet.

Powinieneś także zobaczyć ich pracujących razem jako błogosławieństwo. Fakt, że pracują razem i naprawiają swoje błędy na bieżąco, jest dobrym znakiem. Przeszedłem do połowy twojego postu, myśląc: „ten dwójka prawdopodobnie się nienawidzi ...” i ku mojemu zdziwieniu powiedziałeś, że chcą dalej współpracować.

Myślę, że ten cytat jest odpowiedni, biorąc pod uwagę twój scenariusz.

„Jeśli dwie osoby zgadzają się we wszystkim, jedna z nich jest niepotrzebna”. ~ Jakiś Stary Facet

W rzeczywistości brzmi to jak idealny scenariusz. Z drugiej strony jestem obydwoma programistami jednocześnie. Lubię opracowywać „duży obraz” w postaci notatek, które ostatecznie trafiają do narzędzia do śledzenia problemów. Następnie zaczynam myśleć o szczegółach implementacji od podstaw. Ogólny obraz ewoluuje, gdy lepiej rozumiem, w jaki sposób elementy będą do siebie pasować, a elementy ewoluują wraz ze zmianami wymagań i otrzymuję nowe pomysły.

Może to dobry model dla wielu mózgów.

Moim zdaniem są to profile komplementarne i mogą kończyć się bardzo dobrze. Zarówno kodowanie, jak i projektowanie są niezbędnymi fazami programowania i nie chcesz skończyć w zespole, w którym nikt nie chce robić X, wystarczy trochę organizacji (patrz, ja też mogę mieć odważne słowo!)

Można tego dokonać poprzez nadzór, jak zauważyli inni, ale jeszcze lepiej zrobić to za obopólną zgodą co do harmonogramu iteracji, kiedy projektować i kiedy kodować, i ogólnie unikać kodowania tego, co jest obecnie projektowane.

Punkt bonusowy, gdy tylko projekt zostanie rozproszony w mniejszych modułach, programista odgórny może zaprojektować rzeczy, nad którymi programista oddolny obecnie nie pracuje, co czyni fazę, w której oba robią, co im się podoba. Oznacza to jednak zdolność obu z nich do dokonania niezbędnych korekt, gdy przyjdzie czas na złożenie wszystkiego.

Jedna uwaga: powiedziałeś

Załóżmy, że pracujesz nad nowym systemem, a nie naśladujesz istniejące, dlatego nie zawsze jest oczywiste, jak powinien wyglądać właściwy projekt końcowy.

Jest to część problemu: chyba że pracujesz nad małym projektem dla już rozwiązanego problemu, tak naprawdę nie ma właściwego projektu końcowego . Istnieje wiele możliwych wzorów. Pamiętaj, że jeśli nie robisz tego w celu wzmocnienia ego ze względu na piękno kodu, ostatecznym celem jest działająca aplikacja. to jest to! To, jak się tam dostaniesz, jest nieistotne, a najlepszym sposobem, aby pozwolić tym dwóm pić się szybko, jest ich wzajemna współpraca w uzupełniający się sposób.

Jak powiedzieli inni, oba poglądy mogą być poprawne na różne sposoby. Nie jest niczym niezwykłym, że dwóch deweloperów nie zgadza się co do praktyk, szczególnie w przypadku tak subiektywnych działań, jak procesy projektowania i rozwoju. Masz tutaj dwie osoby, które pasjonują się tym, co robią i mają wiedzę na temat tego, jak to zrobić: obejmij to!

Masz tutaj duży potencjał, aby pozwolić obu osobom pracować na swój własny sposób i nadal dopasowywać elementy, aby uzyskać działającą aplikację.

1. Kazałbym im usiąść i przedyskutować, zachęcając ich, aby zobaczyli to z punktu widzenia drugiego.

2. Po tej dyskusji możesz zacząć mówić o planowaniu: należy to zrobić jako zespół, przy założeniu, że żadne nie musi „ustępować” drugiemu, ale trzeba będzie pójść na kompromis. Istnieje wiele sposobów planowania architektury bazy kodu, które pozwalają na jej późniejsze rozszerzenie, bez wprowadzania dodatkowej masy kodu.

3. Gdy tylko zdołasz ich doprowadzić do zawarcia rozejmu, pozwól im się rozerwać! Pozwól „odgórnemu facetowi” kierować planowaniem architektury wysokiego poziomu, interfejsów, hierarchii itp. Pozwól „oddolnemu facetowi” wskoczyć i zacząć pisać kod, gdy zaplanowanych jest kilka modułów. Poproś ich, aby oficjalnie zgodzili się zaakceptować metody drugiej osoby jako dobre dla całego projektu: Planowanie umożliwienia łatwych przyszłych zmian jest dobre, ale nie musi być od razu kodowane w ten sposób. Utwórz interfejsy i wytnij metody, aby uzyskać strukturę kodu, i zaakceptuj, że duża część kodu na przyszłość nie zostanie napisana, dopóki nie będzie potrzebna.

4. Niech często wspólnie sprawdzają zarówno projekt, jak i kod. Powtarzaj cykle, w których zanurzasz się głęboko w niektóre segmenty architektury, planujesz bardziej szczegółowo i piszesz te części.

5. Jest to prawdopodobnie najważniejszy punkt: Ułatwienie punktów w cyklu, w których mówią tylko o procesie, a nie o wykonywanej pracy. Zastanów się nad budowaną dynamiką: powinieneś zadać cztery pytania. Co poszło dobrze, że powinniśmy dalej robić? Co poszło źle, że powinniśmy przestać? Czego nam brakuje? Co możemy zrobić z tym, czego nam brakuje?

To zajmie trochę pracy: musisz przekonać ich, aby zgodzili się współpracować na swój własny sposób. Niektórym nie jest łatwo przyznać, że nie ma jednego, poprawnego sposobu działania. Ważną rzeczą nie jest to, w jaki sposób pracujesz ani jak wygląda kod na końcu; ważne jest to, że ci dwaj wykwalifikowani, kompetentni ludzie uczą się, jak najlepiej ze sobą współpracować. To nie jest coś, co możesz im po prostu powiedzieć; wszystko, co możesz zrobić, to poprowadzić ich przez proces uczenia się, jak zrobić to sami. Tak jak nie ma jednego odpowiedniego projektu, nie ma jednego właściwego sposobu pracy dla ludzi.

Ogólnie rzecz biorąc, z mojego doświadczenia zawodowego nie mam wystarczającego projektu z przodu. A projekt, który się dzieje z przodu, jest niskiej jakości . To jest złe. Głównie dlatego, że rezultatem jest (w większym lub mniejszym stopniu) rzucanie błotem w ścianę i sprawdzanie, co przylega. Dług techniczny zaciąga się od samego początku.

Z góry na dół jest ogólnie lepsze niż z dołu do góry. Chociaż nie wykluczałbym całkowicie oddolnego podejścia. Powodem tego jest to, że odgórne zmusza Cię do szerszego myślenia o problemie i zadawania lepszych pytań . To wzmacnia pierwszy punkt powyżej ... prowadzi do wyższej jakości projektowania i zwykle ma duży wpływ na znaczną część pracy na niższym poziomie. Ogranicza to znaczną konieczność ponownej pracy, która często jest konieczna, jeśli najpierw zostaną zbudowane komponenty niższego poziomu.

Istnieje niemałe ryzyko, że jeśli najpierw zostaną zbudowane komponenty oddolne, presja programistyczna próbuje dopasować wymagania biznesowe do zaprojektowanych komponentów. To też jest złe. Wymagania biznesowe powinny kierować projektem, który powinien kierować wdrażaniem. Wszystko, co pójdzie w drugą stronę, doprowadzi do gorszych wyników.

Żadne z tych podejść nie jest wystarczające. Wygląda na to, że każdy z nich jest sprytny lub ma wystarczające doświadczenie, aby zdać sobie sprawę z niedociągnięć drugiego podejścia (może zostali spaleni?), Ale nie dostrzega niedociągnięć własnego, wybranego przez siebie podejścia ...

Prawda jest taka, że ​​konieczne jest podejście mieszane:

• prawie niemożliwe jest stworzenie „właściwego” projektu z góry; niezbędny jest pewien stopień eksperymentu, aby zidentyfikować punkty bólu, wąskie gardła ... (wskazówka: nigdy nie są tam, gdzie myślisz, że będą)
• jest prawie niemożliwe, aby przejść gdziekolwiek, po prostu „idąc”, jest bardziej prawdopodobne, że skończysz gdzieś, gdzie nie chciałeś lub po prostu biegłeś w kółko, niż cokolwiek innego

Mieszając oba, możesz:

• mieć z grubsza szkic wskazujący kierunki i szkielet infrastruktury
• i opracowywanie komponentów pasujących do tej wizji

Ponieważ nie istnieje żaden istniejący system spełniający ten cel, należy z góry zdać sobie sprawę, że:

• konieczne będą eksperymenty / prototypowanie
• iteracja będzie zatem konieczna

Dlatego należy jak najszybciej położyć nacisk na „działający” system, nawet jeśli oznacza to ignorowanie narożnych skrzynek itp. Jest to koncepcja „cienkiego pionowego wycinka”: zamiast budowania fundamentów domu , potem ściany, potem konstrukcja dachu ... i tylko uzyskanie czegoś użytecznego na samym końcu (lub nigdy nie uzyskanie, albo to naprawdę nie jest użyteczne) ... lepiej zamiast tego najpierw zbudować w pełni wyposażony pokój , jak łazienka. Można go użyć natychmiast i można go wykorzystać do zebrania opinii.

Aby opinie były cenne, najlepiej najpierw zająć się podstawową częścią.

A co z twoimi współpracownikami?

Pierwszą rzeczą po pierwsze jest to, że oboje muszą zrozumieć potrzebę współpracy i potrzebę uzgodnienia drogi naprzód: ciągłe karanie, tak jak jest, musi działać na nerwy i wpływać na motywację. Powyżej przedstawiłem to, co sprawdziło się w praktyce przy wielu projektach, możesz to wykorzystać jako sugestię.

Następnie muszą ustalić, kto co robi. Zauważ, że w podkreślonym powyżej podejściu w środkowej płaszczyźnie oba powinny dobrze wykonywać zadania, które doceniają.

Pamiętaj, że zarówno do budowania szkieletów, jak i do budowania cegieł najlepiej podchodzić stopniowo.

1. Obaj powinni uzyskać przybliżony szkic szkieletu, a następnie wspólnie zdecydować, na którym „cienkim plasterku” skupić się najpierw
2. Facet oddolny powinien zacząć pracę nad najlepiej zrozumiałym kawałkiem „cienkiego plasterka”
3. Odgórny facet powinien zacząć rozbijać szkielet, najlepiej zajmując się najbardziej blokującymi elementami, aby ukończyć plasterek

Opłucz i powtarzaj, aż plasterek zacznie działać; gromadzić opinie po drodze, aby dostosować w razie potrzeby.

Uwaga: jest to prototyp, oba muszą być gotowe do wyrzucenia i zacząć od zera w zupełnie innym projekcie.

Potrzebny jest lider (lub przełożony), który rozumie tworzenie oprogramowania i decyduje o tym, jakie podejście należy zastosować w projekcie. W razie potrzeby lider poleca programistom pracę w określony sposób, niezależnie od osobistych preferencji.

Jedynym skutecznym rozwiązaniem, które mogę wymyślić, nie marnuje czasu, jest pozwolenie każdemu deweloperowi na podążanie własnym stylem projektowania.

W rzeczywistości może być bardzo nieefektywny ... ponieważ są szanse, że będzie wiele konfliktów i przeróbek. Co gorsza, możesz zakończyć się całkowitym niepowodzeniem projektu.