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

73

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.

Jim G.
źródło
6
Downvotes eh ... Uważam, że niektórzy zwinni konwertyci są trochę defensywni, szczególnie gdy widzą zwinnego i kowboja w tym samym zdaniu. I nawet nie jestem tak zwinny, że irytują mnie kowboje.
sipwiz
2
Może to mieć coś wspólnego z tym, dlaczego wielu pierwotnych sygnatariuszy Manifestu Zwinności wyraża niechęć do terminu „zwinny”, jak to jest używane w większości firm. Zamiast tego rozmawiają teraz o „kunszcie oprogramowania”.
Darcy Casselman,
1
Po pierwsze, pozwól mi powiedzieć, że NIE jestem fanem zwinności. Po drugie, powiem, że z mojego doświadczenia, „capital A Agile” po prostu spowalnia wszystkich (w tym kowbojów). Nigdy nie pracowałem w sytuacji, w której czułem, że zwinny umożliwia tak zwany „kowbojski koder”.
TM.
1
Nie sądzę, aby nazywanie tego, co opisujesz, „trafnym kodowaniem kowbojskim” jest trafne. To nie jest problem indywidualny - to problem grupowy. To kiepskie zarządzanie produktem i zespołem.
matt b
3
Uważam, że myślenie z góry jest prawie bezcelowe. Iteracja w kierunku rozwiązania zgodnego z pierwszymi instynktami może być bardzo skuteczna, jeśli zastosujesz rozsądne praktyki programowania. Z mojego doświadczenia wynika, że ​​ci, którzy przedkładają znaczne plany, nie mogą zareagować na rzeczywistość po rozpoczęciu programowania.
dash-tom-bang

Odpowiedzi:

87

Cieszę się, że ma nazwę

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.

Dean Harding
źródło
17
Dilbert (zawsze) kołysze ..
TheVillageIdiot
20

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]

Huperniketes
źródło
3
Nigdy nie będzie możliwe udaremnienie kowbojów bez względu na podejście. Jednak przynajmniej w przypadku wodospadu musieliby co najmniej sporządzić dokument wymagań, dokumentację sepcyfikacji itp. Dzięki zwinności mogą w zasadzie uciec po prostu uderzając prosto w kod.
sipwiz
3
Ponownie jest to błąd w prawidłowym zarządzaniu procesem. Klient powinien informować programistów o wartości biznesowej w historii użytkownika, a testy powinny zweryfikować, czy są one zintegrowane z bazą kodu. Zaloguj obszary, w których programiści muszą odtworzyć swoje kroki. Czy nie są dobrze zaznajomieni z procesem biznesowym klienta? Czy nie są pewni co do środowiska wdrażania? Jeśli projekt wiąże się z dodatkowymi kosztami prac rozwojowych z powodu „przeróbki komponentów”, kierownictwo powinno chcieć to poprawić, aby zmniejszyć prawdopodobieństwo przekroczenia budżetu lub harmonogramu.
Huperniketes
4
Jeśli zaczniesz walić w kod, nie będziesz zwinny, nawet jeśli tak go nazwiesz. Co mnie powstrzyma od tego, że zwlekam z kodem i nazywam go wodospadem, jeśli spędzę 5 minut zastanawiając się nad wymaganiami na początku.
Craig,
1
Huperniketes ma rację, problem nie dotyczy metodologii; problem polega na tym, że zespół zarządzający pozwala kowbojom kierować działem.
Jeff Siver,
7
@sipwiz: Nawet w wodospadzie kowboje uderzyłyby prosto w kod. W końcu dokumentują wszystko, co napisali, jako specyfikację projektu.
TMN
13

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.

użytkownik2567
źródło
12

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”!

TMN
źródło
Nic nie nazywamy, ale w zasadzie tak się tutaj dzieje. W rzeczywistości mamy kilka dużych dokumentów projektowych, ale są one przestarzałe i nikt na nich nie patrzy. Zamiast tego każda nowa funkcja lub poprawka jest podyktowana wyłącznie tym, co według wiceprezesa jest gorące lub tym, co mówi sprzedaż, czego oczekują klienci, szybko zbiera się na spotkaniach i jest wyrzucany w ciężkich terminach.
CodexArcanum
+1: @TMN, @CodexArcanum: Też miałem takie same doświadczenia. Nie było mistrza użytkownika. Sprzedaż podyktowała nowe funkcje do zarządzania produktem, który następnie przekazał je do rozwoju.
Jim G.
7

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.

Morgan Herlocker
źródło
4
Problem polega na tym, że dobry projekt jest prawie niemożliwy do niczego poza trywialnymi projektami. Problemy z projektem stają się widoczne dopiero w trakcie realizacji projektu. Użytkownicy nie wiedzą, czego chcą, bez względu na to, jak są ekspertami.
Craig,
@Craig. Chociaż zgadzam się z tobą, że specyfikacje są prawie niemożliwe do dopracowania, nawet nietrywialne systemy powinny być w stanie prototypować na papierze i jest to o wiele tańsze niż pisanie całego systemu tylko po to, aby stwierdzić, że musi zostać przepisanym. Jeśli nie można go prototypować w wersji papierowej (przynajmniej w przypadku podstawowej funkcjonalności), trudno sobie wyobrazić, że dany system będzie działał dobrze lub że jego wdrożenie w końcu będzie uzasadnione. Jeśli ty i użytkownik nie będziecie mogli usiąść i przejść przez scenariusz testowy na papierze przed rozpoczęciem pracy, wystąpią poważne problemy.
Morgan Herlocker,
2
@Craig Nie zgadzam się, że dobry projekt jest niemożliwy. Znajomość każdej zawiłości systemu z góry może być prawie niemożliwa, ale nie oznacza to, że nie można stworzyć projektu przeciwko temu, co wiadomo. Mam na myśli nawet jedno zdanie w stylu „Ta aplikacja zostanie napisana jako aplikacja MVC przy użyciu struktury encji dla DAL” byłoby czymś. Poza tym widziałem przetargi, w których jest ponad 180 stron wymagań i nie możesz mi powiedzieć, że to za mało szczegółów, aby stworzyć całkiem niezły projekt.
sipwiz
sipwiz, z mojego doświadczenia wynika, że ​​liczba stron nie koreluje z użytecznością specyfikacji. To, co jest napisane, jest ważniejsze, a nie jak bardzo. Zależy to całkowicie od systemu, czy 180 stron jest dobre, czy nie. Jeśli buduję system Windows, myślę, że jest nieco lekki.
Craig,
3
Myślę też, że musisz pamiętać, że zwinność nie oznacza braku specyfikacji.
Craig,
6

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

Dziwne
źródło
4
Niepowodzenia w rozwoju nie są wynikiem obecności kowbojów. Niepowodzenia rozwojowe są wynikiem braku obecności zarządu.
Huperniketes
@Huperniketes, czyli FANTASTYCZNE wiadomości. Programiści nigdy nie są winni! Co za idealny zawód wybraliśmy!
Dziwne,
@Oddthinking, przestań ograniczać się do myślenia binarnego. Programiści z pewnością mogą być obwiniani za to, że nie osiągnęli poziomu swojego zawodu, ale programiści nigdy nie są winni za niepowodzenia projektu. To odpowiedzialność kierowników projektów.
Huperniketes
@Huperniketes, może mógłbyś wyjaśnić więcej, proszę? Początkowo mówiłeś o „niepowodzeniach programistycznych”, ale potem przeniosłeś się na „niepowodzenia projektowe”. Zgadzam się, że kierownicy projektów mogą być zmuszeni do „noszenia puszki”, jeśli jeden z ich programistów działa poniżej oczekiwań, ale trudno jest zrozumieć, w jaki sposób kowboje, którzy nie dostarczyli, nigdy nie mogą być przyczyną niepowodzenia projektu.
Oddthinking 18.10.10
@Oddthinking, miałem na myśli brak rozróżnienia między „niepowodzeniami programistycznymi” a „niepowodzeniami projektowymi”. Używa się ich tutaj synonimicznie. Pewnie, projekt mógł się nie powieść, ponieważ wysiłek programistyczny był mniejszy, ale obowiązkiem kierownika projektu jest zidentyfikowanie tych przypadków i w razie potrzeby naprawienie ich zmianami w zespole. Jego zadaniem jest zobaczyć, czy projekt się powiedzie. Musi zostać zwolniony, jeśli nie może tego zrobić. Musi więc upewnić się, że członkowie zespołu, nawet kowbojscy koderzy i programiści gwiazd rocka, wypełniają swoje zobowiązania wobec projektu lub zwalniają ich.
Huperniketes 18.10.10
5

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

TM.
źródło
3

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 .

azheglov
źródło
3

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.

Matt H.
źródło
1
Nie zapomnij o paranoicznych kontrolach „if (var! = Null)”
rozsianych
3

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.

Stoły Bobby'ego
źródło
1
Brzmi to bardzo podobnie do mojej sytuacji. I dochodzi do sedna tego całego pytania, że ​​gdyby „Agile” nie było w pobliżu, organizacje prawdopodobnie trzymałyby się wodospadu i bez względu na jego wady znacznie przewyższałoby brak procesu.
sipwiz
2

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.

Veronica Buitron
źródło
Widziałem to również (klienci, którzy widzą wczesną wersję i zbyt pochłaniają się w błędach / funkcjach, o których wiesz , że nie są jeszcze gotowi), a czasem możesz mieć trudności z uzyskaniem przydatnej opinii. Myślę jednak, że jest to kwestia edukacji twoich klientów.
Dean Harding
Prototypowanie ....
sipwiz
2

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.

TEC
źródło
Słuszne uwagi. Moje frustracje wynikają z tego, że rezultaty w podejściu zwinnym są znacznie bardziej płynne, co pozwala niekompetentnemu liderowi technicznemu na ucieczkę od wszystkiego, czego chcą i co z mojego doświadczenia nie kończy się na żadnym == kodowaniu kowboja.
sipwiz
1

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 .

Tony Andrews
źródło
zwinny bez automatycznych testów prosi o bóle głowy
Steven A. Lowe
1

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

użytkownik5206
źródło
1
Podejrzewam, że większość z nas zaczynała jako kowboje.
David Thornley,
Może masz rację, a ja nie programowałem długo, ale kiedy byłem w sklepie bez metodologii, mieliśmy kowbojów. Jestem teraz w zwinnej firmie konsultingowej, a to, co robisz, jest duże i widoczne, a tak naprawdę trudno mi sobie wyobrazić kowbojskiego kodowania korzystającego z tego środowiska.
Eric Wilson,
1

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.

Jay Godse
źródło
0

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.

Itay
źródło