Czy zwinne podejście jest zbyt wygodną wymówką dla kowbojów

Uważam, że zwinne podejście jest najlepsze w przypadku projektów, w których wymagania są niejasne i potrzeba dużej interakcji, aby pomóc w kształtowaniu pomysłów użytkownika końcowego.

Jednak ... W mojej pracy zawodowej ciągle trafiam do firm, w których „zwinne” podejście jest usprawiedliwieniem dla tego, dlaczego nie włożono żadnych wysiłków w projekt z góry; kiedy wymagania są dobrze zrozumiane.

Nie mogę przestać myśleć, że gdyby nie było zwinnego podejścia, siedziałbym tutaj z ładną specyfikacją na wysokim poziomie i nie musiałbym ponownie odwiedzać tego samego ekranu i funkcji co drugi dzień, gdy pojawia się coś innego i tak o tym nie pomyślałem.

Czy zalety zwinnych metodologii są naprawdę wystarczające, aby przewyższyć usprawiedliwienie bycia kulawym dla technicznych kowbojów?

Aktualizacja: Jak na ironię jestem teraz certyfikowanym Scrum Master. W jednym z artykułów przedstawionych na kursie Scrum zaobserwowano, że najlepszym procesem rozwoju był proces, w którym jeden ekspert lub guru podejmował decyzje projektowe, ale ma to oczywiste słabości. Scrum przenosi odpowiedzialność za produkcję wysokiej jakości oprogramowania na „Zespół”, co oznacza, że ​​zespół niespełniający standardów może uciec od produkowania spaghetti, które, jak sądzę, nie różni się od innych zwinnych i niestabilnych procesów programistycznych.

Uważam, że jeśli używasz programowania Agile jako wymówki dla programowania w stylu kowbojskim, to tak naprawdę nie śledzisz rozwoju Agile. Kowboje zawsze będą kowbojami, bez względu na proces, jaki im zapewnisz.

Zwinność nie jest bardziej winna złym praktykom programistycznym niż BDUF. Problem leży w dyscyplinie lub jej braku w stosowaniu praktyk. Celem praktyk BDUF jest identyfikacja kierunku projektu i wcześniejsze określenie ryzyka. Celem zwinnych praktyk jest utrzymanie na tyle elastycznego stanu rozwoju, aby szybko zmienić kierunek. Zwinny projekt może przygotować bardzo szczegółowe historie użytkowników, aby zespół był świadomy przyszłych kierunków i nadal wybrał tylko 2 lub 3 na iterację do pełnego wdrożenia. Problem pozostaje ten sam, niezależnie od zastosowanej metodologii: kierownictwo pozwala kowbojom uciekać.

[BDUF: Big Design Up Front]

Zwinność, jak wszystko inne , może być wykorzystana do pokrycia złego zachowania lub próby rozwiązania problemu, za który zdaniem zespołu nie są oni odpowiedzialni.

Jednak w niektórych magii Agile metodologii jak Scrum jest to, że będą one zapewnić widoczność dużo na problemy w organizacji. W tym problemy w zespole!

Będziesz wtedy miał możliwość ich rozwiązania, gdy tylko się pojawią.

Jeśli problem leży po stronie kowbojów, będzie to bardzo widoczne po pierwszej iteracji. Jeśli problem występuje gdzie indziej, wkrótce go zobaczysz.

Co dziwne, z „zwinnych” projektów, w które byłem zaangażowany, bardziej przypomina pretekst do zarządzania, aby pominąć fazę zbierania wymagań, niż kowbojską chęć po prostu zacząć pisać. Moje projekty były bardzo frustrujące, ponieważ nie mamy żadnych użytkowników końcowych do interakcji. Zamiast tego mamy dyrektora, który rozmawia ze sprzedawcą, aby dowiedzieć się, czego oczekują klienci, a następnie zwołuje spotkanie i opisuje je menedżerom, którzy następnie zaczynają przypisywać zadania programistom. Przy „dobrym” projekcie możemy mieć do czynienia z prezentacją PP, ale zwykle spędzamy codzienne spotkania na scrumie pytając, jak ma działać jakaś funkcja, a kierownik zapisuje pytania i pyta dyrektora. To ogromna strata czasu - ale „zwinna”!

Nie powiem, że jestem fanem Wodospadu, ponieważ ja również radzę sobie z coraz bardziej frustrującymi zmianami zakresu, ale zawsze postrzegałem Agile jako ustępstwo wobec problemu, a nie jako skuteczny sposób walki z nim. Dobry projekt z wczesnymi testami iteracyjnymi i mnóstwem papierowych prototypów wydaje się być znacznie bardziej skuteczny.

Widzę obronę Agile Development, która mówi, że nie jest odpowiedzialna za awarie spowodowane przez kowbojów. Sukces z Agile wymaga staranności i inteligencji.

Wydaje się to rozsądne, o ile zastosujesz tę samą koncesję do innych metodologii. Jeśli nie możesz winić Agile za niepowodzenia projektu spowodowane przez kowbojów, nie możesz winić metodologii nie Agile za niepowodzenia projektu spowodowane przez kowbojów.

Możemy następnie spierać się, czy istnieje zwartość (a nie przyczynowość!) Między Agile i kowbojami. Mam tylko anegdotyczne dowody. Czy jest to postrzegane jako dobry sposób na radzenie sobie z praktykami kowbojskimi bez wykrycia przez kierownictwo?

Oczywiście, jeśli zaakceptujemy, że kowboje mogą nie być równomiernie rozłożone na różne metodologie, i przyjmiemy, że kowboje podważają udane wykorzystanie procesu, bardzo utrudniamy sprawdzenie, czy proces się powiódł. Twierdzenie, że jeden proces jest lepszy (w kontekście), staje się bliskie niemożliwemu do zakwalifikowania. Jest to jedna z kwestii, która każe mi zawstydzić głowę moim zawodem - brak naukowych podstaw wielu twierdzeń.

(Nawiasem mówiąc, nienawidzę nazywania alternatywy dla Agile „wodospadem”, ponieważ procesy wodospadu wydają się być słaby, którego wszyscy atakują, ale bardzo niewielu ludzi faktycznie używało bez iteracji.)

Zwinność jest w porządku, o ile działa dla Twojego zespołu.

Zbyt wielu sprzedaje to jako sposób na przekształcenie złego zespołu w dobry zespół, a to po prostu nie działa. Nie możesz wziąć złych ludzi i zastosować procesu, który nagle uczyni ich przydatnymi.

Podoba mi się wiele pomysłów zwinnych, ale porażka, którą widzę raz po raz, polega na tym, że menedżerowie stosują ścisły zestaw „zwinnych procesów”, co jest sprzeczne z całą koncepcją zwinności, że zespoły powinny być sobą organizowanie

Jeśli chodzi o „kowbojów”, stwierdzam, że dla wszystkich zwinnych zespołów, w których byłem, procesy służą ich spowolnieniu bardziej, niż pozostawieniu szaleństwa. Nigdy nie doświadczyłem sytuacji, w której służył do zwinny włączyć się „kowbojski koder”.

W przypadku dobrych zespołów wydaje się, że działa dobrze (z drugiej strony większość procesów wydaje się działać dobrze, gdy masz dobry zespół, zabawne, jak to działa, prawda?).

Dla innych zespołów, z mojego doświadczenia, nigdy nie pomaga złym ludziom radzić sobie lepiej, ale czasami służy do zamaczania produktywnych ludzi.

Ogólnie rzecz biorąc, myślę, że ważne jest zbudowanie dobrego zespołu, powiedzenie mu, czego potrzebujesz, a następnie zejść mu z drogi. Nie sądzę, aby stosowanie ciągów słów kluczowych prawdopodobnie rozwiązywało problem posiadania złego zespołu.

(Jeśli nie zorientowałeś się z powyższego, nie jestem fanem „Capitol-A Agile”. Z drugiej strony nie sądzę, żeby zachęcało to również kowbojów.)

Zwinne, gdy jest właściwie wykonane, powinno skutkować ograniczeniem się w technologicznych przewodnikach „kowbojskich” i programistach „bohaterów”. Jeśli nie zauważysz tego efektu, może to oznaczać, że brakuje czegoś ważnego w Twojej zwinnej implementacji.

Chcę dodać, że „Agile” to tak naprawdę interfejs (używam tutaj metafory obiektowej) i nie można go utworzyć. Jeśli twoją konkretną implementacją jest XP , musisz postępować zgodnie z szeregiem praktyk technicznych z dużą dyscypliną, co pozostawia niewiele miejsca na programowanie kowbojów. Inną możliwością jest praca zespołowa dobrze zorganizowanego zespołu Scrumowego .

Kowbojscy koderzy mają również tendencję do pisania kodu, który nie jest zbyt testowalny i zwykle nie lubią pisać testów. Myślę, że wszyscy, którzy robią TDD, mogą pomóc w zachowaniu się w stylu kowbojskim i sprawić, że programiści jeszcze bardziej pomyślą o architekturze. Oczywiście żadna metodologia nie jest idealna.

Obecnie pracuję w sklepie, w którym tak jest, z wyjątkiem tego, że dotyczy to bardziej kultury organizacyjnej niż poszczególnych indywidualnych kowbojów.

Organizacja zawsze działała na stosunkowo luźnym, „nieformalnym zwinnym” podejściu. Nie powiedziałbym, że jest naprawdę zwinny, bardziej „zwinny w nazwie”, ale po prostu nieistniejąca metodologia w praktyce. Różne zespoły działają inaczej, ale ponieważ w ogólnej kulturze organizacyjnej nie ma żadnej metodologii oprócz bardzo luźnego procesu „zwinnego tylko z nazwy” - jest ogólnie dość kowbojski i chaotyczny - szczególnie w integracji (i jest tego dużo ).

Morał tej historii jest następujący: Tak, tak się dzieje. Gdybym w tej chwili szukał pracy, byłbym bardzo ostrożny. Jeśli sklep twierdzi, że jest zwinny - zadam kilka trudnych pytań w wywiadzie, aby upewnić się, że rzeczywiście śledzone jest coś więcej niż tylko błędna nazwa zwinnego.

Odkryłem, że użytkownicy mogą przekazać nam swoją opinię tylko wtedy, gdy mają aplikację, z której mogą korzystać, ekrany, na których mogą wprowadzać dane. Tylko wtedy naprawdę rozumieją to, co próbowaliśmy powiedzieć w dokumentach wymagań (klienci podpisują, ale każdy ma swoją własną wersję znaczenia). Jeśli nie jest to zwinne opracowanie, będzie to projekt wodospadu przekraczający budżet, ale aplikacja zmieni się po dostarczeniu. Twoja pierwsza wersja jest niczym więcej niż prototypem dla użytkowników w celu omówienia wymagań. Dlatego raczej nazywam to zwinnym niż przekraczaniem budżetu.

Myślę, że to prawda, w niektórych środowiskach zwinność jest wykorzystywana jako wymówka dla braku dyscypliny. Prawdziwy problem polega na tym, że straciliśmy z oczu, dlaczego mamy jakąkolwiek metodologię. Osobiście uważam, że metodologia jest zagadnieniem architektonicznym w tym sensie, że architektura systemu powinna uwzględniać niefunkcjonalne atrybuty jakości, metodologia powinna odnosić się do niektórych z tych samych atrybutów (łatwość konserwacji, produktywność rozwoju, transfer wiedzy, i wsp.)

Spojrzenie na metodologię jako kontrolę atrybutów procesu implikuje kilka rzeczy: 1) bez mierników nie możemy porównać skuteczności jednej metodologii nad drugą, 2) należy podjąć aktywną decyzję o tym, jakie atrybuty są ważne (czas dostawy a kod jakość a transfer wiedzy).

Nie mając zarówno wskaźników, jak i konkretnego celu, po prostu wybieramy metodologię jako nasze „magiczne pióro”, która jeśli będziemy się trzymać mocno, będziemy w stanie dostarczyć oprogramowanie.

Teraz nie-mówcy Agile, XP, Scrum itp. Mówią o kruchości tej konkretnej kategorii metodologii. Argumentem jest: po co stosować metodologię, która może być sabotowana przez osobę pozbawioną dyscypliny, aby przestrzegać wszystkich zasad? Pytanie jest ważne; jest to jednak objaw, a nie przyczyna. Jeśli dokładny i znaczący (to jest trudny element) zestaw metryk procesu zostanie zdefiniowany, przetestowany i otrzyma aktualne informacje zwrotne, sądzę, że odkryjemy, że konkretna metodologia ma niewiele wspólnego z sukcesem. (Anegdotycznie rzecz biorąc widziałem udane projekty wykorzystujące niezliczoną liczbę metodologii i dwa razy więcej niepowodzeń przy użyciu tych samych metodologii)

Więc jakie są dane? Różnią się od projektu do projektu, od zespołu do zespołu i od czasu do czasu. Przydatne, gdy harmonogram dostaw jest ważny, którego osobiście użyłem, to umiejętność szacowania i jakość. Większość programistów może dokładnie oszacować zadania trwające tydzień lub krócej. Tak więc jednym podejściem jest podzielenie projektu na zadania trwające jeden tydzień programisty i śledzenie, kto dokonał oszacowania. W miarę realizacji projektu mogą zmieniać swoje prognozy. Po zakończeniu zadania, jeśli jest wyłączone o więcej niż 10% (1/2 dziennie), traktujemy to tak samo jak błąd - identyfikujemy, dlaczego oszacowanie było wyłączone (tj. Nie uwzględniono tabeli bazy danych), określ działania korygujące (tj. zaangażuj DBA w oszacowanie), a następnie przejdź dalej. Korzystając z tych informacji, możemy tworzyć wskaźniki, takie jak liczba błędów w szacunkach na tydzień, liczba błędów na programistę,

Więc co? Właśnie wtedy pojawiają się metodologie - jeśli masz model predykcyjny, który nie spełnia jakości procesu, możesz dodać lub usunąć jakiś aspekt metodologii i zobaczyć, jak wpływa ona na twój model. To prawda, że ​​nikt nie chce bawić się procesem rozwoju z obawy przed porażką, ale już zawodzimy w niezmiennie wysokim i przewidywalnym tempie. Wprowadzając indywidualne zmiany i mierząc wyniki, możesz stwierdzić, że Agile jest idealną metodologią dla Twojego zespołu, ale równie łatwo możesz znaleźć RUP, wodospad lub po prostu zestaw najlepszych praktyk, które będą idealne.

Więc moja sugestia pozwala przestać martwić się o to, co nazywamy procesem, wprowadzić kontrole, które są istotne dla naszych celów procesu rozwoju i eksperymentować z różnymi technikami, aby ulepszyć ten proces.

Siedziałbym tutaj z ładną specyfikacją na wysokim poziomie i nie musiałbym ponownie odwiedzać tego samego ekranu i funkcji co drugi dzień, ponieważ pojawia się coś innego, a więc nie pomyślałem o tym.

Wydaje się, że jest to zgodne z doświadczeniem mojego kolegi z „zwinnego” projektu, w którym jest (nigdy sam się na nim nie brałem): jest proszony o napisanie fragmentu kodu do jakiejś specyfikacji, a potem, gdy skończył testować i jest gotowy do przejścia na nowy wymóg, który wymaga zmiany i ponownego przetestowania. Uważa to za frustrujące.

Nie walczę zwinnie, podejrzewam, że zespół nie robi tego zwinnie - ale jak mówisz, termin „zwinny” może czasem być używany przez kowbojów, aby przekonać sprytnego kierownictwa, że ​​na wpół upieczony projekt jest raczej pozytywny niż negatywny .

Zabawne, że nikt nie myśli o sobie jako o kowbojskich programistach. Zakładam się, że wiele plakatów jest lub było;)

Kowbojscy koderzy są dobrzy, ponieważ lubią szybko robić rzeczy. Często nie przejmują się problemami z dużym obrazem lub jakością kodu, dlatego „kowbojski koder” jest często epitetem. Ich metody zmniejszają ryzyko kosztów alternatywnych opóźnionej realizacji projektu.

Koderzy niebędący kowbojami lubią wykonywać swoją pracę w bezpieczny, zdyscyplinowany i uporządkowany sposób. Lubią budować to dobrze i budować raz. Są znani z tego, że zawsze zbierają informacje, zastanawiają się, co, jeśli produkują duże dokumenty, których nikt nie czyta, i dostarczają systemy późno lub bardzo późno. Ich metody próbują zmniejszyć ryzyko związane z oprogramowaniem niskiej jakości.

Doskonałość metodologii Agile polega na tym, że wykorzystują one mocne strony obu typów koderów, wymuszając krótkie iteracje robocze ograniczone w czasie, które wymagają od koderów szybkiego wykonania małych prac o wysokiej jakości. Każda iteracja zmniejsza zarówno ryzyko kosztów alternatywnych opóźnionego dostarczenia, jak i ryzyko złej jakości oprogramowania.

Powodem, dla którego zwinność kładzie bardzo mały nacisk na projekt / specyfikacje z góry, nie jest tylko to, że wymagania mogą się zmienić. Głębszy powód jest taki, że nawet gdy wymagania są stabilne, specyfikacje to:

• niepoprawny - nie udało się uchwycić wymagań.

• niespójne - pełne sprzeczności, ponieważ zawierają wystarczającą ilość informacji, aby uniemożliwić pisarzowi / czytelnikowi ich złapanie.

• odłączony - nie zawierają cennych informacji zwrotnych z działającego (choć zdegenerowanego) systemu.