Dlaczego programowanie ekstremalne (XP) przestało być aktualne na rzecz Agile, Kanban itp.?

Lubię XP (programowanie ekstremalne), szczególnie tę część, w której na tym samym ekranie jest 2 programistów, ponieważ rozwiązanie problemu często znajduje się szybciej, jeśli tylko wyjaśnisz, co robisz, a programowanie w parach zmusi cię do wyjaśnienia, czym jesteś robić.

W ciągu ostatnich 10 lat styl pracy XP wydaje się być nieaktualny na korzyść metodologii pracy: Agile i / lub Kanban. Dlaczego? Ponieważ XP wydaje mi się bardzo dobrym sposobem na pracę i dużo dotyczy programowania, podczas gdy Agile i Kanban bardziej dotyczą procesów.

Istnieje wiele różnych stylów, metod i sposobów myślenia związanych z rozwojem całego pola i wszystko ma swoją własną, lśniącą nazwę.

Zwinność to tylko sposób myślenia, który odchodzi od zwykłych, statycznych modeli programowania (takich jak wodospady) - jego głównym celem jest osiągnięcie bardziej elastycznego rozwoju i (na samym końcu) lepszego oprogramowania i zadowolonych klientów. Poniżej zwinnego, istnieje wiele różnych modeli, takich jak Scrum, Kanban, XP.

Zwłaszcza Kanban nie pochodzi pierwotnie z tworzenia oprogramowania, wywodzi się z budowania samochodów (przypominam, że Toyota wprowadziła go do budowy samochodów, a niektórzy programiści go adoptowali i rozszerzyli)

Programowanie w pary, przeglądy kodu i takie rzeczy to tylko narzędzia - zawsze możesz (i powinieneś) to robić podczas projektu, bez względu na to, jakiej metody używasz. Po prostu te rzeczy są bardziej rodzime dla zwinnych niż statycznych.

XP mniej więcej wprowadziło te rzeczy (lub przynajmniej nadało im lśniącą nazwę) i wszystkie poniższe rzeczy przyjęły je, ponieważ po prostu dobrze działały.

Moim zdaniem XP to praktyki programowania, Scrum i kanban to praktyki zarządzania projektami. Mają związek, ale się nie zastępują.

W naszym projekcie Kanban używamy programowania w parach (głównie w przypadku złożonych sekcji i debugowania), TDD, CI. Tak więc jest nadal używany, ale zarządzanie bardziej naciska na stronę zarządzania projektami.

Ekstremalne programowanie dotyczy mechaniki rozwoju, podczas gdy Agile dotyczy SDLC (cyklu życia oprogramowania).

Głównym powodem, dla którego nie słyszysz już o „Ekstremalnym programowaniu” z nazwy, jest użycie terminu „Ekstremalny” jako pozytywnego przymiotnika. Jest to przestarzała rzecz z lat 90. na początku 00, która jest teraz postrzegana jako banalne. Jest to głównie ofiara marketingu. Właśnie dlatego prawie wyłącznie słyszysz, że to „XP”, nawet werbalnie.

Mam kilka przemyśleń na temat programowania par.

Dla mnie jest to coś, co robisz, gdy utkniesz z czymś. W tym czasie może być bardzo skuteczny, może wydostać się z koleiny. Ale jest to również męczący i sposób pracy, że programista typu stereo nie lubi robić więcej niż czasami.

Jeśli kopiesz dziurę, niewiele osób miałoby nic przeciwko otrzymaniu pomocy od współpracownika. Ale gdy tylko pojawia się kreatywność, ludzie wolą robić rzeczy po swojemu, niż po czyjejś. Napięcie jest więc zawsze bliskie, chyba że nikogo to nie obchodzi w ten czy inny sposób lub jeśli jego rolą jest jedynie sugerowanie.

Tam, gdzie pracuję, programowanie w parach nie jest sformalizowane, ale mamy sesje ad hoc, które zazwyczaj są krótkie. To nie będzie tak: „Hej, współpracowniku, a może jakieś ekstremalne programowanie?” Najczęściej zaczynał się od „Czy możesz spojrzeć na mój ekran?” i wyciągając dla nich krzesło.

Nie sądzę więc, aby programowanie w parach było martwe lub mniej popularne, jest to tylko jedno z tych narzędzi, z których nie korzysta się zbyt często, ponieważ jest kosztowne, a nie przede wszystkim dlatego, że dwie osoby pracujące nad jedną rzeczą są opłacane.

Zwinność jest bardziej zbywalna, ponieważ angażuje różnych interesariuszy o różnych rolach i obowiązkach związanych z procesem tworzenia oprogramowania.

Kiedy w drugim wydaniu Kent Beck rozszerzył zakres uczestników w XP, było już późno: ludzie przyjęli już inne metodologie, ponieważ pierwsza wersja XP jest skierowana do osób wykonujących kod, a to, o czym publiczność wciąż pamięta, albo nieświadomie, albo nie. XP nie był zbywalny od urodzenia.

Zawsze uważałem, że Scrum był wersją Agile, którą najłatwiej sprzedać kierownictwu: deterministyczne szacunki, jego doktrynalna, dobrze zdefiniowana natura („tak naprawdę nie robisz Scruma - poczuj się winny!”) ...

Rozciągnij swoje sprinty wystarczająco długo i weź te małe „karty pokera” wystarczająco poważnie, a Scrum może bardzo łaskotać to samo swędzenie, co metody Wodospadu. To niekoniecznie jest złe, ale nie chowajmy się tutaj za dymem i lustrami.

Po stronie XP, programowanie parami zasadniczo nie odwołuje się do zarządzania, zwłaszcza zarządzania nietechnicznego.

Aby umieścić go w formacie analogii SAT, Scrum: XP :: The Monkees: The Beatles