Czy zwinny jest rozwój lub zarządzanie?

Podczas debaty na temat tego, o co chodzi w Scrumie, stwierdziłem, że być może zupełnie nie zrozumiałem zwinności. Wydaje mi się, że Scrum (który z pewnością jest uważany za proces zwinny) polega na zarządzaniu funkcjami i sprintami oraz rolami i innymi rzeczami, nie mając nic wspólnego z TDD, programowaniem par, CI, refaktoryzacją i innymi technikami i praktykami skoncentrowanymi na programistach, które myślałem ( do teraz) są sercem zwinnym. Teraz mam trudności!

1) Czy Scrum jest niezależny od tego, czy programiści stosują zwinne praktyki?

2) Czy możesz wdrożyć Scrum w zespole, który nie korzysta z automatycznych testów? nie dokonuje refaktoryzacji lub nie stosuje zwinnych praktyk programistycznych?

Powszechnym błędem jest myślenie, że Scrum jest równy Agile.

Bycie zwinnym postępuje zgodnie z czterema zasadami Manifestu Zwinności . Scrum to proces zarządzania projektami zgodny z tymi zasadami, ale sam w sobie nie jest zwinny. XP (TDD, programowanie par) jest procesem programistycznym, również zgodnym z tymi zasadami i zgodnym ze Scrumem, ale nie jest zwinny. Ciągła integracja, ciągła dostawa, DevOps, wszystko zgodne z zasadami Agile.

Postępuj zgodnie z zasadami przede wszystkim. Wszystkie te zwroty są tylko metodologiami, które ludzie odkryli, pomagając im przestrzegać zasad. Ale główną częścią „bycia zwinnym” jest możliwość dostosowania procesów do woli, tam gdzie nie są zgodne z zasadami zwinności.

Czy Scrum jest niezależny od tego, czy programiści stosują zwinne praktyki?

Scrum to zestaw wskazówek, które zachęcają zespół do zwinności.

Czy potrafisz wdrożyć Scrum w zespole, który nie korzysta z automatycznych testów? nie dokonuje refaktoryzacji lub nie stosuje zwinnych praktyk programistycznych?

Bardzo trudne, ponieważ pod koniec każdego sprintu musisz mieć działający produkt. Jeśli musisz wykonać pełny ręczny test regresji, aby udowodnić, że działa, prawdopodobnie nie będzie to możliwe.

Alistair Cockburn (jeden z twórców ruchu Agile) mówi to o Crystal Clear (jeden aspekt jego metodologii Agile):

Crystal Clear można opisać słuchaczowi poziomu 3 następującymi słowami:

„Umieść 4-6 osób w pokoju ze stacjami roboczymi i tablicami i dostępem do użytkowników. Niech dostarczą działające, przetestowane oprogramowanie użytkownikom co miesiąc lub co dwa miesiące, a w przeciwnym razie zostaw je w spokoju. ”

Jest to definicja sprawnego, co prawda, doświadczonego personelu programistycznego, który wie, co robi i można mu ufać, że się do tego zabierze. Czy to oznacza, że musisz używać CI, TDD i programowania pary oraz wszystkich innych modnych rzeczy? Po prostu ... Nie.

Zwinność nie polega na przestrzeganiu zestawu procesów, ale na skuteczności. Co to oznacza dla Ciebie, zależy od Twojego zespołu i jego działania, co uznasz za przydatne. Jeśli TDD nie pomoże ci stworzyć działającego kodu, przestań słuchać mniejszych świateł, które krzyczą o nim w Internecie i nie używaj go! Jeśli programowanie w parach naprawdę pomaga twojej drużynie skoncentrować się i załatwić sprawy, zignoruj ​​każdego, kto mówi, że to strata czasu i zorganizuj swój zespół jak 3-nogowy wyścig w szkolnym dniu sportu.

Zwinnie działałem wiele lat temu, tak wielu, że nawet nie zdawaliśmy sobie sprawy, że działamy zwinnie - co miesiąc dostarczaliśmy iteracje produktu, cyklicznie naprawialiśmy błędy i regularnie dodawaliśmy nowe funkcje. Zrobiliśmy absolutnie zerowe testy jednostkowe, ponieważ takich rzeczy nie wynaleziono, a książka refaktoryzacji nie została napisana. Więc tak, absolutnie możesz robić zwinne bez żadnej z tak zwanych zwinnych praktyk.

Alistair mówi również o Kent Beck:

Zapytany o XP i pięć poziomów „Modelu dojrzałości zdolności” Instytutu Inżynierii Oprogramowania, odpowiedział trzema poziomami dojrzałości XP:

1. Rób wszystko zgodnie z opisem.

2. Po wykonaniu tej czynności eksperymentuj z różnymi zasadami.

3. W końcu nie przejmuj się, czy robisz XP, czy nie.

W końcu nie przejmuj się, czy robisz XP, czy nie ... mądre słowa, które powinny przypominać ci, żebyś nie wpadł w tę pułapkę .

Scrum to smak zwinny, który jest zgodny ze specyficznym wzorcem, aby osiągnąć cele metodyki zwinnego rozwoju. Nie możesz podążać za Scrumem i nie być zwinnym, ale możesz być zwinny i nie podążać za Scrumem.

Scrum nie ma wpływu na stosowanie testów automatycznych, zwinny zwykle je faworyzuje, ale nie są one w żaden sposób wymagane. Refaktoryzacja powinna być celem zwinnym i Scrumem, ale często jest ignorowana. brak zamiaru refaktoryzacji nie jest tak zwinny.

Czy zwinny jest rozwój lub zarządzanie?

Agile to zestaw praktyk opracowywania oprogramowania, które spełniają wymagania rynku i szybko zmieniają się fazy - lub tak zwane przyspieszone dostarczanie . Tak więc, ogólnie rzecz biorąc, chodzi o elastyczne podejście do spełniania zmieniających się złożonych wymagań klienta poprzez dzielenie pracy w małych pomieszczeniach i zapewnianie funkcjonalności w szybkich iteracjach 2-4 tygodniowych.

Aby jednak osiągnąć tę elastyczność, zespół programistów musi przećwiczyć praktyki programowania zwinnego .

Opis z Wiki dotyczący tworzenia oprogramowania Agile :

Zwinne tworzenie oprogramowania to grupa metod opracowywania oprogramowania opartych na iteracyjnym i przyrostowym rozwoju, w których wymagania i rozwiązania ewoluują dzięki współpracy między samoorganizującymi się, wielofunkcyjnymi zespołami. Promuje planowanie adaptacyjne, ewolucyjny rozwój i dostarczanie, iteracyjne podejście czasowe oraz zachęca do szybkiej i elastycznej reakcji na zmiany. Jest to ramy koncepcyjne, które promują przewidywane interakcje w całym cyklu rozwoju.

Rzeczywiście, możesz używać scrum w projektach, które nie mają nic wspólnego z tworzeniem oprogramowania. Jest to metoda zarządzania projektami / zarządzania zespołem.

1) NIE !!!! Scrum jest zwinny, co oznacza, że ​​zwinne praktyki deweloperów (TDD, programowanie par, CI, refaktoryzacja itp.) Są bardzo ważne dla wszystkich aspektów projektu Scrum. O wiele trudniej będzie ustalić tempo biegania zespołów, oszacować pracę, ustawić odpowiedni rozmiar sprintu itp., Jeśli nie stosujesz tych praktyk.

2) Tak, możesz wdrożyć Scrum w zespole, który nie przestrzega zwinnych praktyk, ale uważam, że to naprawdę ogranicza potencjał zespołu. Duża część tego, dlaczego Scrum / Agile odnosi tak duże sukcesy, to wzrost wydajności i jakości uzyskany dzięki praktykom programistycznym Agile, które są kluczowe w dostarczaniu pełnych funkcji od początku do końca podczas każdego sprintu.

Jeśli ktoś w twojej grupie próbuje cię przekonać, że praktyki deweloperskie Agile są stratą czasu, myślę, że powinieneś poświęcić trochę czasu, aby podkreślić, dlaczego praktyki te są zawsze stresowane przez Scruma, a także Agile jako całość. Naprawdę robią różnicę.