Jak wytłumaczysz „zwinnemu” zespołowi, że nadal muszą planować pisane przez siebie oprogramowanie?

W tym tygodniu w pracy znów się zmotywowałem . Po przejściu standardowej zwinnej, TDD, wspólnej własności, doraźnej metodologii opracowywania, aby nigdy nie planować niczego poza kilkoma historiami użytkowników na kartce, werbalnie żuć cud nad technicznymi aspektami integracji z reklamami stron trzecich bez nudności myśląc o należytej staranności i architektonicznie łącząc cały kod produkcyjny z pierwszym testem, który przychodzi komukolwiek do głowy w ciągu ostatnich kilku miesięcy, osiągamy koniec cyklu wydania i oto, a oto główna widoczna z zewnątrz funkcja, którą opracowujemy, jest zbyt wolna, aby używać, buggy, staje się labiryntowo złożony i całkowicie nieelastyczny.

Podczas tego procesu dokonano „skoków”, ale nigdy nie udokumentowano i nigdy nie wyprodukowano żadnego projektu architektonicznego (nie było FS, więc co do cholery, jeśli nie wiesz, co rozwijasz, jak możesz to zaplanować lub zbadać ?) - projekt przeszedł od pary do pary, z których każda koncentrowała się tylko na jednej historii użytkownika, a wynik był nieunikniony.

Aby rozwiązać ten problem, wyszedłem z radaru, poszedłem (przerażony) wodospad, zaplanowałem, zakodowałem i w zasadzie nie zamieniłem pary i próbowałem jak mogłem pracować sam - skupiając się na solidnej architekturze i specyfikacjach, a nie na testach jednostkowych, które przyjdzie później, kiedy wszystko zostanie przypięte. Kod jest teraz znacznie lepszy i jest w rzeczywistości całkowicie użyteczny, elastyczny i szybki. Wygląda na to, że niektórzy ludzie naprawdę mnie urazili i robili wszystko, aby sabotować moje wysiłki (być może nieświadomie), ponieważ jest to sprzeczne ze świętym procesem zwinności.

Jak więc, jako programista, wyjaśniasz zespołowi, że planowanie „pracy” nie jest „niestabilne” i jak dopasowujesz planowanie do zwinnego procesu? (Nie mówię o IPM; mówię o siedzeniu z problemem i szkicowaniu całościowego projektu, który mówi, w jaki sposób problem powinien zostać rozwiązany wystarczająco szczegółowo, aby każdy, kto pracuje nad problemem, wiedział, co architektura i wzorce, których powinni używać oraz gdzie nowy kod powinien zostać zintegrowany z istniejącym kodem)

Myślę (i być może wychodzę tutaj), że WSZYSTKIE projekty powinny mieć trochę klasycznego wodospadu: wstępna faza analizy i specyfikacji jest niezbędna. Musisz wiedzieć, co robisz i musisz to mieć na piśmie. Otrzymanie wymagań na piśmie jest trudne i czasochłonne oraz łatwe do zrobienia źle. Dlatego tak wielu to pomija - każda wymówka wystarczy: „Och, działamy zwinnie, więc nie musimy tego robić”. Dawno, dawno temu, przed zwinnością, było „och, jestem naprawdę sprytny i wiem, jak to rozwiązać, więc nie musimy tego robić”. Słowa się nieco zmieniły, ale piosenka jest zasadniczo taka sama.

To oczywiście wszystko byk: musisz wiedzieć, co masz robić - a specyfikacja to sposób, w jaki programista i klient mogą komunikować, co jest zamierzone.

Kiedy już wiesz, co musisz zrobić - naszkicuj architekturę. To jest część „zrób dobry obraz”. Nie ma tu żadnego magicznego rozwiązania, żadnej właściwej drogi i żadnej metodologii, która by ci pomogła. Architektury są SYNTEZĄ rozwiązania i pochodzą z częściowo inspirowanego geniuszu, a częściowo z trudnej wiedzy.

Na każdym z tych kroków będzie iteracja: znajdziesz coś złego lub zagubionego i idź je naprawić. To debugowanie. Jest to zrobione przed napisaniem kodu.

Niektórzy uważają te kroki za nudne lub niepotrzebne. W rzeczywistości te dwa kroki są najważniejsze ze wszystkich w rozwiązywaniu każdego problemu - zrób je źle, a wszystko, co nastąpi później, będzie złe. Te kroki są jak fundamenty budynku: Zruj je i masz Krzywą Wieżę w Pizie.

Kiedy masz CO (to jest twoja specyfikacja) i JAK (to jest architektura - która jest projektem wysokiego poziomu), masz zadania. Zwykle jest ich dużo.

Rozwijaj zadania w dowolny sposób, przydzielaj je w dowolny sposób. Użyj dowolnej metodologii tygodnia, która Ci się podoba lub która Ci odpowiada. Wykonaj te zadania, wiedząc, dokąd zmierzasz i co musisz osiągnąć.

Po drodze będą fałszywe szlaki, błędy, problemy ze specyfikacją i architekturą. To skłania do takich rzeczy: „Cóż, wtedy całe planowanie było stratą czasu”. Który też jest bykiem. Oznaczało to po prostu, że masz MNIEJ faulów, z którymi musisz sobie poradzić później. Gdy znajdziesz problemy z wysokopoziomowymi rzeczami z wczesnych dni, NAPRAW JE.

(I na marginesie: tutaj pojawia się wielka pokusa, by próbować spełnić specyfikację, która jest droga, trudna, a nawet niemożliwa. Prawidłowa odpowiedź to pytanie: „Czy moja implementacja jest zepsuta lub czy specyfikacja jest zepsuta? ”Ponieważ jeśli problem można rozwiązać szybko i tanio, zmieniając specyfikację, to właśnie powinieneś to zrobić. Czasami działa to z klientem, a czasem nie. Ale nie będziesz wiedział, czy nie pytaj.)

Wreszcie - musisz przetestować. Możesz korzystać z TDD lub czegokolwiek innego, ale nie gwarantuje to, że na koniec zrobiłeś to, co powiedziałeś. Pomaga, ale nie gwarantuje. Musisz więc wykonać test końcowy. Właśnie dlatego rzeczy takie jak weryfikacja i walidacja są nadal ważnymi elementami w większości podejść do zarządzania projektami - czy to w rozwoju oprogramowania, czy w produkcji buldożerów.

Podsumowanie: Potrzebujesz wszystkich nudnych rzeczy z góry. Używaj rzeczy takich jak Agile jako sposobu dostawy, ale nie możesz wyeliminować staromodnego myślenia, specyfikacji i projektu architektonicznego.

[Czy poważnie spodziewałbyś się zbudować 25-piętrowy budynek, umieszczając 1000 robotników na miejscu i każąc im tworzyć zespoły do ​​wykonania kilku prac? Bez planów. Bez obliczeń strukturalnych. Bez projektu lub wizji tego, jak powinien wyglądać budynek. I wiedząc tylko, że jest to hotel. Nie - nie sądzę.]

Nadal jestem zdumiony, że wiele osób uważa, że ​​TDD oznacza najpierw pisanie testów jednostkowych. Nie, to oznacza pisanie testów, których będziesz potrzebować przed napisaniem kodu. Test faktycznie może być testem jednostkowym, testem integracyjnym, testem end-to-end i oczywiście testem wydajności (cóż, prawdopodobnie nie napiszesz testu wydajności przed testowanym kodem, ale nie oznacza to, że nie powinieneś go pisać). Potrzebny typ testu powinien być widoczny z definicji „zrobione” dla historii użytkownika. Jeśli jedno z kryteriów akceptacji dla historii użytkownika mówi, że ta funkcja powinna zapewnić wynik w ciągu 500 ms dla 50 równoczesnych użytkowników, historia użytkownika nie może zostać uznana za ukończoną, dopóki nie zostanie przeprowadzony test wydajności, który wykaże, że te kryteria akceptacji są spełnione. Po automatycznym teście możesz codziennie sprawdzać, czy mija, gdy dodajesz inne funkcje.

Wygląda na to, że kryteria akceptacji nie zostały poprawnie zdefiniowane, dlatego nie można było przetestować swojej wydajności. Może się jednak zdarzyć, że aplikacja źle się sprawdzi po wdrożeniu w prawdziwym środowisku i użytkowaniu pod dużym obciążeniem, ale zawsze może być uważana za awarię wymagań (jeśli nie określono wymagania, programista nie bierze tego pod uwagę podczas pracy nad kod) lub zespół programistów (niewystarczające testowanie w stosunku do zdefiniowanych wymagań).

Kolejną interesującą rzeczą jest to, że programiści w twoim zespole koncentrują się na historii dla jednego użytkownika. Zwinność polega na komunikacji, więc programiści powinni przekazywać informacje o wymaganiach użytkowników i ich wpływie na resztę aplikacji - współpraca jest koniecznością. Test powinien to również obejmować, więc jeśli jeden programista złamie wymaganą funkcjonalność dla innej historii użytkownika, powinien być widoczny w testach automatycznych. Jeśli nadal uważasz, że to nie wystarczy lub nie działa, możesz wprowadzić spotkanie architektury, w ramach którego cały zespół współpracuje i dyskutuje architekturę aplikacji. Zwykle wystarczy takie spotkanie raz w tygodniu.

Wiele rzeczy z procesu wodospadu zastępuje się komunikacją i automatycznymi testami. Nikt nie mówi, że nie można napisać żadnej dokumentacji lub projektu na wysokim poziomie! Możesz i wiele zespołów używa do tego np. Wiki.

[nasz produkt] był zbyt wolny w użyciu, zawierał błędy, stawał się labiryntowo złożony i całkowicie nieelastyczny.

To nie ma nic wspólnego ze zwinnością, to znak, że programiści nie wykonują właściwie swojej pracy.

Jedną z podstawowych koncepcji zwinności jest to, że zespół ma pełną kontrolę nad procesem. Oznacza to, że muszą uzgodnić ilość planowania, dokumentacji, testów i sposobu postępowania z refaktoryzacją. Cała ta moc jest świetna, ale wiąże się również z odpowiedzialnością i prawdopodobnie w tym miejscu zawiódł twój zespół. Zaakceptowali swoją wolność, ale zaniedbali swoje obowiązki.

Ostatecznie chodzi tylko o wyjaśnienie jakości kodu i próbę uzgodnienia sposobu jego zwiększenia i utrzymania w ten sposób. Naprawdę obowiązują normalne praktyki programowania.

Wskazówka: skorzystaj z „Definicji ukończenia”, aby to wymusić. Upewnij się, że wszyscy się na to zgadzają i umieść to dla wszystkich. Użyj go jako ścisłego strażnika przy podejmowaniu decyzji, czy historia jest ukończona, czy nie. Możliwe jest nawet dodanie wymagań niefunkcjonalnych (takich jak wydajność) do tej listy.

Tak. Twoi koledzy z drużyny są idiotami. Twój projekt był do bani dzięki Agile. Czuć się lepiej? OK, przejdźmy dalej. : P

Myślę, że ty i twój zespół będziecie w stanie skuteczniej komunikować się na temat tego, co poszło źle, jeśli mniej skoncentrujecie się na nazwach swoich metodologii Capital-M, a bardziej na tym, dlaczego napisane przez was oprogramowanie było tak powolne i błędne. W ogóle nie używaj terminów Agile ani waterfall . Są wyraźnie załadowane emocjonalnie w twoim biurze.

Zwinne czasami działa. Tym razem nie działało to dla twojego zespołu. Niektórzy powiedzą, że to dlatego, że źle zrobiłeś Agile. W końcu Agile działa, więc gdybyś zrobił to dobrze, zadziałałoby, prawda? Cokolwiek.

Nie brzmi to tak, jakby nikt nie zgadzał się z porażką, ale nie zdobędziesz przyjaciół, nie wpłyniesz na ludzi ani nie zrobisz nic lepszego następnym razem, jeśli obwiniesz metodologię. To prawdopodobnie nie miało wiele wspólnego z tym, co poszło nie tak.

Zamiast tego skoncentruj się na ustaleniu najbardziej bezpośrednich przyczyn niepowodzenia i współpracuj z zespołem, aby upewnić się, że nie powtórzą się one ponownie. Będzie to wymagało umiejętności ludzi.

Mówiąc o umiejętnościach ludzi, nie powinieneś się dziwić, że twój zespół nie docenił tego, że źle wyglądasz, wykonując całą pracę i robiąc to lepiej niż oni. Robiąc to „pod radarem” możesz uszkodzić niektóre relacje, które musisz teraz odbudować, aby być skutecznym członkiem zespołu.

Uważam, że najlepszym sposobem na przyjrzenie się takiej sytuacji jest wzięcie pod uwagę całkowitej długoterminowej wydajności zespołu jako całości. Tym razem mogłeś zaoszczędzić tydzień, ale na dłuższą metę mogłeś lepiej zrobić, budując lepszy zespół .

Mówię ci te wszystkie rzeczy, ale myślę, że prawdopodobnie znasz już większość z nich i mógłbyś wyjaśnić je komuś innemu, gdybyś nie był tak blisko tej sytuacji.

Jeśli chcesz dodać do dyskusji gruby cytat, Eisenhower miał dobry:

„Plany są niczym; planowanie jest wszystkim”.

http://www.brainyquote.com/quotes/quotes/d/dwightdei149111.html

Miał na myśli, że powinieneś spodziewać się zmiany swoich planów, a więc nie przykładaj zbyt dużej wagi do planu, jaki istnieje, ale jednocześnie proces planowania gwałtownie skoncentruje twoje energie w kluczowy sposób. Musisz zaplanować, zanim będziesz mógł je przetestować i udoskonalić.

+1 To najlepszy opis zwinności przedsiębiorstwa, jaki ostatnio przeczytałem.

Każdy, kto dogaduje się ze zwinnym, zauważa, że ​​nigdy nie miało to oznaczać, ale kiedy wszyscy zostaną przyłapani na pomiarach, właśnie to otrzymujesz od zespołu, który nie ma pasji do jakości produktu i który ma obsesję na punkcie testowanie przede wszystkim lub dotrzymywanie cotygodniowych terminów dostaw, niezależnie od kąta, w którym pomalowali wszystkich innych, ponieważ to wszystko sprawia, że ​​dochodzi to do poziomu zarządzania co tydzień.

Nigdy nie widziałem tego naprawionego z niczym innym niż reorganizacją. Jeśli jesteś firmą średniej klasy, która nie ma nic specjalnego do przyciągnięcia naprawdę pełnych pasji ludzi, to nawet tego nie naprawi, chyba że kolejne zarządzanie czasem zmieni metodologię.

Zwinność wydaje się działać dobrze tylko w organizacjach, w których zespół deweloperów dba na tyle, aby stworzyć dobry produkt, pomimo dodatkowej, niewymienionej pracy, która jest wymagana. Skutecznie muszą zadbać o to, aby był dobry w swoim czasie, walczyć o poprawę (i być gotowym spalić wiele dodatkowego czasu na powtórzenie testów w niektórych przypadkach TDD)

Oczywiście zależy ci na wysyłce dobrego produktu, oczywiście zależy im na wykonaniu skryptu i otrzymaniu wypłaty za ciągłe sprzątanie bałaganu, jaki popełniają.

Szukałbym mniej irytującego zatrudnienia gdzie indziej, czy to zwinnego, czy nie.

Jeśli jesteś całkowicie wypalony zwinnie, istnieje wiele miejsc, które nadal stosują inne metodologie. Na przykład prawie wszystko w ofercie lub kontrakcie.

Zazwyczaj używam czegoś w rodzaju hybrydy. Ogólny plan to wodospad, ale wykonanie jest zwinne.

Domyślam się, że jeśli sytuacja jest tak zła, jak mówisz, twój zespół tak naprawdę nie używa zwinności, są po prostu leniwi lub niezdyscyplinowani. Zwinność nie polega na nieplanowaniu, chodzi jedynie o elastyczność i, cóż, zwinność.

Z niektórymi pracownikami mamy te same problemy.

Zasadniczo „Nie wiem, dopóki go nie napiszę” to ulubione stwierdzenie. Więc poszliśmy w drugą stronę, pracowaliśmy z klientem, aby zdefiniować produkty z punktami podpisu. Ostatnim z nich jest „teraz napisz kod, aby wykonać X”.

Jeśli mamy „pisać projekt / testowanie / plan itp.” W tym samym sprincie do dostarczania co „zrób zabawny i interesujący kod”, to pierwsza część nigdy się nie wydarzy ...

ALE jeśli umieszczę „nie zrobisz żadnego fajnego i interesującego kodu, dopóki nie powiesz, co zamierzasz zbudować, a klient się wyloguje”

• po pierwsze dostajesz narzekającą akceptację, a kilka łez i ja musiałem dużo wypełnić wypełnianie pustych miejsc i dodatkowy wysiłek ...
• wtedy zaczyna się rozpoznawać, gdy pytasz ich „więc jak przebiegał proces”, że lepiej wypróbować pierwszą wersję na papierze
• masz przypadki testowe, które programiści mogą zobaczyć, i możesz dokładnie wskazać oczekiwanie „co to znaczy znaczy”.
• wtedy klienci podpisują się na rozwoju ma 80% mniej odrzucenia ...
• a także obserwujesz, jak wszyscy programiści chodzą i trzymają dokumenty projektowe i rozmawiają ze sobą o projektach ... zaczynają to naprawdę rozumieć.
• Następnie zastanawiasz się, jak rozbić plan projektu na kawałki wielkości kęsa i zrobić z niego proces.

Zwinna część pojawia się wtedy, gdy klient następnie zmienia plan i możesz dostosować się w ciągu 2 tygodniowego cyklu NIE latać przy siedzeniu spodni i nadrobić to po drodze.

W naszym przypadku „duży projekt z góry” został podzielony na 9 etapów (faktyczne wydania produkcyjne) ze średnią 5 podstacji. Projektanci i programiści dotrzymują kroku sobie nawzajem, projektanci są 1-3 podstopniami wyprzedzającymi programistów ... za daleko, a odkrycia w rozwoju przełamują zbyt wiele elementów projektu, zbyt blisko i poprawiają się, aby zaprojektować koszty w takim stopniu, w jakim były już wprowadzono „osadzony w kamieniu” w ramach rozwoju. Każda podstacja kosztuje 2-4 sprinty dla 1 dewelopera.

W mniejszych projektach mamy tego samego programistę, który najpierw projektuje> podpisuje się> wystawia fakturę> rozwija> podpisuje się> wystawia fakturę ... w cyklach.

Problem z nazewnictwem testowym

Testowanie ma wiele twarzy, formalnie istnieje około 7 kategorii testów, każda z podsekcjami ... jedną z tych późniejszych jest „zapis automatycznych testów jednostkowych”.

To zła nazwa, że ​​„testuj pierwszy rozwój” tylko dlatego, że programiści rozumieją, co znaczy „testy” w tym kontekście, widzą testy jako pisanie rzeczywistego kodu testu przeciwko interfejsowi implementacji. Jeśli wcale nie jest tak, że ... możesz to zrobić, jeśli chodzi o pisanie kodu, ale naprawdę „sprawdza poprawność projektu pod kątem przypadków użycia i historii użytkowników PRZED rozpoczęciem pisania kodu” ... zrobione poprawnie to usuwa wiele problemów normalnie wykrywanych podczas opracowywania, gdy wciąż znajduje się w znacznie tańszej wersji „papieru, który można wyrzucić”.

Jednym z kluczowych elementów Agile jest pomysł ciągłego doskonalenia oraz pomysł, że cały zespół jest właścicielem projektu. Tak więc poprawne podejście polegałoby na sprawdzeniu problemów z zespołem i poproszeniu zespołu o podjęcie decyzji, jak to naprawić.

Jeden członek zespołu odszedł sam, porzucając wszystkie zasady Agile i robiąc wszystko po swojemu, może spowodować, że niewielka ilość kodu będzie działała dobrze, ale tak naprawdę nie przyspiesza całego projektu w pozytywny sposób.

Jednym ze sposobów, aby je uruchomić, może być utworzenie mapy T, która obejmie wszystkie dzienniki sprintu

Każda drużyna ma wątek, każdy sprint to kropka. Wszystko wiąże się razem (wydaje się, że Twoja drużyna się przewraca). Przypnij to gdzieś i uzyskaj magnesy reprezentujące pary / podzespoły. Mogą nawet „ścigać się”. Ale wszyscy wiedzą, gdzie są oni i inne zespoły. Umieść tutaj zależności, jeśli takie istnieją.

Chodzi o to, że przekazujesz cały proces, ale także rozkładasz go na sprinty. Nawet jeśli zostanie tam uruchomiony tylko pierwszy sprint, a pozostałe okresy będą puste, powinno to stanowić doskonałą mapę drogową do ukończenia projektu.

Masz dwa problemy: niewystarczający kształt wymagań i słabą architekturę.

Wymagania

Potrzebujesz zarówno ogólnego celu końcowego, jak i szczegółowej mapy drogowej, jak się tam dostać.

W świecie wodospadów celem końcowym jest specyfikacja funkcjonalna, a planem dojazdu do niej jest plan projektu.

W zwinnym świecie jednym ze sposobów jest uchwycenie go w epickiej historii użytkownika. Następnie mapa drogowa to szczegółowe historie użytkowników, które dopracowują szczegóły eposu.

Nigdy nie byłem do końca zadowolony z tej historii, ponieważ epicka historia nigdy nie zawiera wystarczającej ilości mięsa, aby przejść przez cały pomysł. Więc zwykle używam dokumentu wymagań systemowych wysokiego poziomu w połączeniu z epicką historią użytkownika lub dwoma. Następnie mapa drogowa zawiera szczegółowe historie użytkowników.

Zaletą posiadania dokumentu wymagań systemowych jest to, że można wyciągnąć kryteria akceptacji wielu historii użytkowników.

Pomyśl o dokumencie dotyczącym wymagań systemowych na wysokim poziomie jako o „arkuszu”, który marketing może wykorzystać do sprzedaży produktu doświadczonemu klientowi technicznemu.

Architektura

Jedną z rzeczy, które daje ci „arkusz cięty”, jest to, że wyznacza granice projektowanego systemu. Dzięki temu możesz wcześnie podejmować świadome decyzje dotyczące używanej architektury.

Gdyby twój zespół miał taki dokument wcześnie, nie musiałbyś później przechodzić przez proces przebudowy systemu.

W rzeczywistości trzecim problemem, jaki masz, jest zła komunikacja. Komunikacja to ulica dwukierunkowa (lub wielokierunkowa między wieloma osobami). Jednak to tylko ludzka porażka i potrzeba (czasem) nadludzkich wysiłków, aby naprawić problem.