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

50

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)


źródło
26
Pierwszy akapit brzmi jak zwrot przeciwko zwinnemu. Reszta wciąż brzmi jak rant, tylko przeciwko reszcie twojego zespołu. Możesz sparafrazować.
1
+1 bardzo zainteresowany tym, jak ludzie rozwiązują to w pragmatyczny sposób, który pozwala ci korzystać z tego, co najlepsze, zarówno wodospad, jak i zwinny. Nawiasem mówiąc: zwinny nie jest równoznaczny z „brakiem projektu”, ale design jest zwykle pierwszą ofiarą w nieustannym cyklu sprintu ...
Marjan Venema
5
No cóż, do pewnego stopnia mam to aż po szyję z „zwinnym”. Wydaje się, że za każdym razem zwinność powstrzymuje każdego od napisania przyzwoitej linii kodu, a wszystko zaczyna się od zwinnego założenia „nie dokumentujemy”, którego następstwem jest „nie planujemy”. Nie chcę nienawidzić zwinności, ale o ile widzę, o ile zachęca to ludzi do nieplanowania swojego oprogramowania, to w najlepszym wypadku jest ono nieproduktywne, aw najgorszym niebezpiecznym.
9
@Marjan Venema - to moja sprawa. Jestem pewien, że zwinny nigdy nie oznaczał „brak projektu” jak „nie przedwcześnie optymalizuj” nie znaczy „nie pisz wydajnego kodu”. Ale wydaje się, że jest to interpretacja rynku masowego. Sposób, w jaki zwinny akcentuje komunikację, jest świetny i naprawdę odświeżająca zmiana, ale wydaje mi się, że w zwinnym świecie samo oprogramowanie jest bardziej przemyślane.
9
Oczywistym jest, że jesteś sfrustrowany słabym stosowaniem zwinnych zasad, ale wydaje się to rantem ledwo zamaskowanym jako pytanie. Żeby było jasne: Agile preferuje „reagowanie na zmianę w porównaniu z realizacją planu”, co oznacza, że ​​„chociaż w elementach po prawej stronie jest wartość , bardziej cenimy przedmioty po lewej”. Z pewnością można docenić stosowanie zbyt małego planu , co wydaje się mieć miejsce w tym przypadku.
Rein Henrichs

Odpowiedzi:

51

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

szybko
źródło
11
+1. +10, gdybym mógł. Jeśli nie masz dobrego pojęcia o tym, co ostatecznie budujesz - co może pochodzić tylko z niektórych prac projektowych, nawet jeśli później zmodyfikujesz ten projekt - to paradygmat programistyczny, który obserwujesz, to „rzut bzdur przy ścianie i zobacz, co się trzyma ”.
Ant
5
-1. Nie lubię szczegółowych specyfikacji, ponieważ ludzie / klienci cały czas zmieniają zdanie, co sprawia, że ​​specyfikacje i projekty z góry są bezcelowe, nie wspominając o marnotrawstwie. Dlatego zamiast marnować czas na „zbieranie wymagań” i tak dalej, powinieneś stworzyć działające oprogramowanie, które pokażesz swojemu klientowi tak szybko, jak to możliwe, abyś mógł uzyskać prawdziwą informację zwrotną na następny krok. Zamiast zgadywać i spekulować. Jeśli chodzi o „specyfikacja jest środkiem komunikacji”: wolę rozmawiać z moimi klientami i pracować iteracyjnie, ale hej, chyba każdy z nich.
Martin Wickman
6
+1. +10, gdybym mógł +1. Jestem totalnym frajerem oprogramowania do budowania jest jak budowanie analogii do budynku, bo tak po prostu jest. Tak, oprogramowanie nie jest fizyczne, tak wykonane poprawnie, może być wysoce modułowe i oddzielone. Ale uczynienie go wysoce modułowym i oddzielonym jest bardzo trudne; to zajmuje czas i planowanie. Zrozumiałem, że zawsze będą dwa obozy w inżynierii oprogramowania: ci, którzy myślą, że planowanie to strata czasu, i ci, którzy tego nie robią. I wiesz, zdałem sobie również sprawę, że ludzie nie zmieniają obozów, no cóż, nie bardzo. Pracowałem w wysoce zaplanowanym środowisku i ...
6
Zgadzam się z tobą, ale to, co opisujesz, jest naprawdę zwinne. Agile mówi „bez dużego projektu z góry”, a nie „bez projektu”. Zostało to powiedziane w odpowiedzi na ogromne, sztywne projekty wielkich potworów z przeszłości. Nie jako wymówka, aby nie projektować i nie znaleźć dobrej architektury dla swojego kodu. Chodzi o to, aby nie spędzać tygodni lub miesięcy na projektowaniu WSZYSTKIM przed rozpoczęciem kodowania, ponieważ projekt BĘDZIE błędny, a im dalej go zauważysz i naprawisz, tym lepiej. Uzyskaj szybką informację zwrotną, iterację, poprawę itp.
sara
5
Kai - Widzę, że Agile jest pretekstem, by nie robić specyfikacji, nie planować, tylko nurkować. I to po prostu źle.
szybko_niedz.
36

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.

Ladislav Mrnka
źródło
7
+1 doskonała odpowiedź. Historia jest celem - to wierzchołek góry lodowej, symbol zastępczy do przyszłej rozmowy, pierwszy krok w podróży; to nie jest cała podróż! Opisy testów są łącznie wymaganiami, przypadkami użycia i kryteriami akceptacji. Projektowanie nie jest ignorowane, projektowanie ogranicza się do historii i testów, ale rób tyle projektowania, ile potrzebujesz . Każdy, kto pomija projektowanie i twierdzi, że jest to zwinny sposób, albo nie rozumie (przeczytaj ponownie książkę XP), nie chce (kodowanie krów yee-haw!), Albo jest po prostu leniwy . I nadanie Agile złego imienia.
Steven A. Lowe
16

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

Martin Wickman
źródło
1
„Zaakceptowali swoją wolność, ale zaniedbali swoje obowiązki”. Może powinien być transparent na zwinnej ścianie „Czy zaakceptowałeś swoje obowiązki wraz ze swoją wolnością?”
Andy Dent,
Świetna odpowiedź, czy mogę zasugerować dodanie, że kiedy użyjesz DoD jako kontraktu w ten sposób, stanie się on również centralny w retrospekcji? W jaki sposób ten DoD pomógł nam w zwiększeniu wartości dodanej dla naszych klientów?
Graham Lee
11

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.

PeterAllenWebb
źródło
9

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

jhocking
źródło
9

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

Rachunek
źródło
1
To właściwie najgorsza definicja zwinności, którą przeczytałem. Deweloperzy nie muszą wykonywać dodatkowej i niewymienionej pracy. Ponadto tylko idioci działają we własnym czasie. Czas poświęcony na testowanie kodu to dobrze zainwestowany czas.
BЈовић
Nie mogę zgodzić się więcej, zwinny, kiedy zamienił się w bestię, że często zdarza się, że biurokracja na poziomie przedsiębiorstwa jest najgorszą możliwą zwinnością. W innym niż korporacyjne środowisku w kolorze taśmy zespół robiłby te rzeczy albo jako historie, albo zanim zaczął opowiadać. Kiedy Agile staje się wskaźnikiem wskaźników korporacyjnych, elastyczność jest zwykle pierwszą rzeczą.
Bill
4

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ść.

Richard
źródło
Też tak myślę. Jestem pewien, że prawdziwa zwinność nie polega na nieplanowaniu, to tylko jedna z jego interpretacji.
Istnieje duża różnica między kapitałem - zwinnym „A” i małymi literami - zwinnym „a”.
Aaronaught
Pssst ... nie mów zwinnym ludziom, ponieważ tak robią prawie wszyscy ludzie wodospadu, ponieważ to działa. Nadal uważają, że WSZYSCY programiści wodospadu budują monolityczne dokumenty bez pisania kodu do samego końca i na każdym kroku wszystko jest nie tak, ponieważ nie ma implementacji.
Dunk
4

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ć”.

Robin Vessey
źródło
3

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.

Dave
źródło
Wydaje mi się, że realizacja projektu była dokładnie tym, co zrobiła . „Przegląd z zespołem” nie jest tak naprawdę rozwiązaniem, jest jedynie sposobem na odroczenie rozwiązania i rozłożenie odpowiedzialności.
Aaronaught
Zespół jest już odpowiedzialny za wynik. Potrzebują tylko, aby ktoś powiedział: „Zepsuliśmy się, jak zmienimy naszą metodologię?” Potem to naprawiają.
Dave
2
Mam wrażenie, że ten konkretny zespół potrzebuje, aby jego członkowie nauczyli się myśleć samodzielnie, zamiast ślepo postępować zgodnie z procesem, którego nie rozumieją. Rozmowa nic nie da, jeśli jest to już komora echa.
Aaronaught
2

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

Mapa T

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.

Pureferret
źródło
1

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.

Peter K.
źródło