Czy Agile zmusza programistów do spędzania większej ilości czasu na pracy?

Patrząc na powszechne zwinne metody, wydaje mi się, że (umyślnie czy nieumyślnie?) Zmuszają deweloperów do spędzania większej ilości czasu na pracy, a nie na czytaniu blogów / artykułów, rozmowach, przerwach na kawę i po prostu zwlekaniu.

W szczególności:

1) Programowanie par - największy pracownik zmuszający, tylko dlatego, że niewygodne jest robienie tego odkładanie na później, gdy jest was dwóch.

2) Krótkie historie - kiedy masz OGROMNĄ część pracy, którą trzeba wykonać np. W ciągu miesiąca, dość często zwlekasz w pierwszych trzech tygodniach i przełączasz na tryb OMG DEADLINE na ostatni.

A przy małych kawałkach (które muszą być wykonane w ciągu jednego dnia lub krócej) jest dokładnie odwrotnie - czujesz, że czas jest napięty, nie ma miejsca na manewrowanie, a wkrótce będziesz odpowiedzialny za to zadanie, więc zaczynasz działa natychmiast.

3) Komunikacja w zespole i spójność - gdy osiągasz słabe wyniki w wolnym, odległym i cichym otoczeniu, może wydawać się to w porządku, ale kiedy pod koniec dnia na spotkaniu w Scrumie wszyscy chwalą się tym, co osiągnęli, i nie masz nic do powiedzenia, że ​​możesz się czuć zawstydzony.

4) Testowanie i informacje zwrotne - ponownie uniemożliwia utrzymanie zadań „w 99% gotowych” (gdy w rzeczywistości jest to około 20%), dopóki nie nadejdzie termin.

Czy uważasz, że pod Agile pracujesz więcej niż przy „konwencjonalnych” metodologiach? Czy presję tę rekompensuje wygodniejsze otoczenie i poczucie szybkiego robienia właściwych rzeczy?

Główną ideą metod zwinnych jest pomoc w produktywności - w pozytywnym sensie. Nikogo to nie obchodzi, jeśli codziennie spędzasz godzinę na surfowaniu, jeśli dotrzymasz terminu. Wszyscy się wściekają, jeśli codziennie surfujesz pół godziny, ale nie dotrzymujesz terminu. Rozwiązanie: Ułatw sobie dotrzymanie terminu.

Jak zauważyłeś, programowanie w parach zapewnia koncentrację (wśród wszystkich innych zalet, takich jak poprawa rozpowszechniania umiejętności / wiedzy, lepszy kod, mniej błędów, jednolity wygląd itp.).

Przekonałem się, że dyscyplina zawsze jest dla mnie walką. Jeśli połączę się z kimś, istnieje szansa, że ​​jedno z nas chce dziś trochę pracy, a drugie ciągnie za sobą. Tak więc „praca przez miesiąc” często zamienia się w „pracę przez tydzień”, dziwiąc się, jak ogromna ilość pracy została ostatecznie rozwiązana, spędzić około jednego dnia na regeneracji (refaktoryzacja, poprawianie TODO w kodzie, dodawanie kilka testów, surfowanie z czystym sumieniem), a następnie podjęcie kolejnego miesiąca pracy.

Wynik netto: Jestem znacznie bardziej zrelaksowany (bardziej, niż pomimo stałego nadzoru), spójność zespołu jest znacznie lepsza, praca jest wykonywana szybciej, ludzie nie trzymają się jakiegoś drobnego problemu przez godziny, a nawet dni (ponieważ ktoś inny może wykryć problem znacznie szybciej).

Kiedy mówisz „możesz się wstydzić”, czy to nie jest dobra rzecz? Oznacza to, że czujesz, że popełniłeś błąd i powinieneś. Nie zarabiasz za nic. Nie zrobienie niczego sprawia, że ​​czujesz się bezradny, nieszczęśliwy, niegodny, nieszczęśliwy. Zamiast zawstydzić się, cofnij się i pomyśl „Dlaczego dzisiaj nic nie osiągnąłem?” Potrzebujesz pomocy? Czy jest coś, czego nie rozumiesz? Czy bieżące zadanie jest zbyt trudne? Nie podoba ci się Może możesz zmienić zadanie z kimś innym. Może ktoś inny może ci pomóc. Zwinne oznacza: Przyjmij odpowiedzialność zamiast być mikro-zarządzanym jak marionetka na sznurkach. Potrzebujesz narzędzia? Idź do swojego szefa i poproś o to. Naucz się kłócić. Naucz się wstawać i krzyczeć, kiedy musisz.

Jeśli chodzi o testy, to jest dobry moment, gdy kod nagle zamienia się z „miłego” na „doskonały”. W tym momencie zauważysz, że musisz zaimplementować funkcję X i pomyślałeś, że to będzie koszmar i nagle zrozumiesz, że kod już prawie jest. Tylko małe refaktoryzacja tu i tam. Nowa klasa i gotowe. Cztery tygodnie pracy nagle stały się dniem. Zwycięstwo! Zwycięstwo!

Zgadzam się.

Programowanie w parach

Jest to bardzo intensywny i wyczerpujący sposób pracy i nigdy go nie stosuję, chyba że mam programistów, którzy muszą być szkoleni przez innych (na przykład nowi użytkownicy)

Krótkie historie

Komunikacja w zespole i spójność

Testowanie i informacje zwrotne

Tak Zwinny, a szczególnie Scrum jest ogromnym czynnikiem zwiększającym produktywność. Przy prawidłowym zastosowaniu obrót może wynosić do 20% (1 programista na 5 opuszcza firmę).

Powód jest prosty: Scrum nie zapewnia większej wydajności it provides the whole company with much more visibility on what's going on(w tym oczywiście w zarządzaniu).

• Uniemożliwia programistom zrobienie absolutnego minimum. Nagie minium jest teraz średnią drużynową!

• Uniemożliwia to zarządowi niewłaściwą współpracę.

Dlatego powiedziałem (w moich innych odpowiedziach w podobnych pytaniach), że zwinność NIE jest dla każdej organizacji (i dla wszystkich).

Na przykład sektor publiczny naprawdę nie jest odpowiedni dla Agile.

Zwinność jest używana jako narzędzie nacisku? Oczywiście widziałem to wiele razy. To tylko pogarsza sytuację.

Czy uważasz, że pod Agile pracujesz więcej niż przy „konwencjonalnych” metodologiach? Czy presję tę rekompensuje wygodniejsze otoczenie i poczucie szybkiego robienia właściwych rzeczy?

To sprawia, że ​​pracuję więcej, ale przede wszystkim sprawia, że ​​pracuję nad właściwą rzeczą. W każdej chwili wiem, co powinienem robić .

To rodzaj dodatniej presji. Jest to zupełnie inne niż niektóre zewnętrzne „jesteś już za opóźnieniem, pracuj więcej, nadgodziny kodu!” rodzaj presji.

Właściwie jestem o wiele bardziej produktywny, kiedy używam konwencjonalnych metod. Za pomocą konwencjonalnej metody tworzę np. Szczegółową analizę wymagań, studium wykonalności, specyfikację funkcjonalną, specyfikację techniczną i wiele protokołów ze spotkań, a wszystko to w ciągu zaledwie kilku miesięcy! Mogę nawet utworzyć kilka wierszy kodu po zakończeniu analizy wpływu!

Zwinne, wszystko, co tworzę, to kilka rezultatów.

W naszej firmie

Programowanie w parach - gdy coś naprawdę złożonego i wymaga szerokiej analizy, nawet połączylibyśmy ze sobą dwie doskonałe osoby i szybko wykonałyby to zadanie. Tutaj złożoność zadania decyduje o potrzebie programowania w parach.

Krótkie historie - Potem odpoczywam przez 3 tygodnie (około 5-6 godzin dziennie) i pędzę w ostatniej chwili (około 12 do 14 godzin dziennie) jako programista Nie lubię oscylacji w obciążeniu pracą. Pracuj około 8 godzin dziennie i utrzymuj stabilny harmonogram, a to zawsze będzie fajne.

Komunikacja w zespole i spójność - podczas spotkania scrumowego dzielimy się nie tylko statusem zadania, ale także przeszkodami. Tutaj, gdy ktoś naprawdę potrzebuje pomocy, inni członkowie wymyślą swoje pomysły, aby mu pomóc. Ale na pewno potrzebujesz do tego doskonałego zespołu, a my jesteśmy :)

Testy i opinie - Z pewnością jako programista nie chcę być w końcu obciążony błędami, w następnej chwili po znalezieniu błędu trzeba było go naprawić i ponownie, to pozwoliłoby mi mieć dobrą prognozę dotyczącą tego, co powinno / może należy zrobić następnie i odpowiednio zmienić termin (w razie potrzeby).

Dlatego jako programista jestem bardzo zadowolony z rodzaju zadania, które podejmuję, i do cholery mogę powiedzieć, że nigdy nie czułem PRAWDZIWEJ presji terminu.

Czy uważasz, że pod Agile pracujesz więcej niż przy „konwencjonalnych” metodologiach?

• Jeśli masz na myśli, czy czuję się bardziej produktywny pod Agile, powiedziałbym, że to zależy .
   
  _{Zwykle myślę o tym w kategoriach Ferrari (jako konwencjonalny) vs Landrover (jako Scrum). Podczas jazdy autostradą Ferrari pokonuje Landrovera.
   
  To teren, kiedy trzeba jeepa, a nie samochodu sportowego - to znaczy, jeśli twoje wymagania są nieregularne i / lub jeśli praca w zespole i doświadczenie w zarządzaniu nie są tak dobre, będziesz musiał wybrać Scrum - po prostu dlatego, że próba pójścia konwencjonalnym dostanie utknąłeś - jak Ferrari utknie w terenie.}

Jeśli chodzi o „więcej pracy” , myślę, że ktoś, kto spodziewa się czegoś takiego, prawdopodobnie nie docenia IQ programisty i jego zdolności do przystosowywania się do różnych form demencji zarządzania .

Do tej pory uczestniczyłem w dwóch zespołach Scrum wykonujących całkiem różne projekty w różnych firmach. W obu zespołach nie zauważyłem żadnych zmian w moich nawykach w porównaniu np. Z wodospadem / iteracją.

Z dumą mogę stwierdzić, że dzieje się tak, ponieważ jestem wyjątkowy i niezwyciężony, ale szczerze mówiąc, widziałem, że zwyczaje wszystkich innych facetów w zespole też są niezwyciężone.

Zwinne zmusza programistów do wykonywania bardziej pożytecznej pracy, ponieważ różne techniki zwinnego rozwoju eliminują pracowitość i pracę, która po prostu nie jest potrzebna.

niewygodne jest robienie tego odkładanie na później, gdy siedzi was dwóch.

Nie zgadzam się. Pracowałem z grupą palaczy i wszyscy zdołali zrobić sobie przerwę na dłuższy czas, ponieważ „wszyscy to robili”.

często ustępuje w ciągu pierwszych trzech tygodni

Jest to oznaka złego zarządzania niezależnie od metodologii. Nawet jeśli za miesiąc nadejdzie ogromna porcja, spodziewam się, że zobaczę coś pod koniec pierwszego tygodnia.

nie masz nic do powiedzenia, możesz się wstydzić.

Jeśli masz ochotę ćwiczyć przez trzy tygodnie, pomyślisz o bzdurach do powiedzenia.

4) Testowanie i informacje zwrotne - ponownie uniemożliwia utrzymanie zadań „w 99% gotowych” (gdy w rzeczywistości jest to około 20%), dopóki nie nadejdzie termin.

Projekty wodospadów mogą mieć testy i codzienne wersje.

Osobiście nie chciałbym pisać kodu i nie mam z tym nic wspólnego przez miesiąc. Wolę pętlę krótszego sprzężenia zwrotnego w moim kodzie, niezależnie od tego, czy jest to recenzja kodowana, czy podpis użytkownika. Popieranie innych przeze mnie pracy jest satysfakcjonujące. To tak, jakby kot upuszczał mysz na progu twojego mieszkania, żebyś wiedział, że wykonuje swoją pracę.

Zwinny nie zmusza programistów do większej pracy , ale do wydajniejszej pracy

Sformułowanie pytania „zmuszanie programistów do większej pracy” wydaje się nieco negatywne, ale z pewnością jest pozytywne, jeśli faktycznie wykonujemy więcej i opóźniamy?

To powiedziawszy, to dobra uwaga. W tym roku czułam się trochę zmęczona zwinnością, ale to ogromna niepisana korzyść, której nie dostrzegałem.

Zgadzam się, że zwinność może prowadzić do zwiększenia produktywności programistów. Twoje uwagi na temat widoczności, rozliczalności i tendencji do odkładania na później środków są bardzo prawdziwe.

Ale zwinna może i powinna również prowadzić do cięższej pracy programistów z pozytywnych powodów - marchewka kontra kij. Sprawnie wykonane, zwinne zapewni programistom większą interakcję z użytkownikami, mniej beuracracy, większą kontrolę nad ich pracą, a wszystko to może prowadzić do uzyskania większych korzyści z Twojego zespołu.

więcej pracy nadal nie jest semantycznie poprawne lub istotne dla Agile, celem jest zwiększenie wydajności . W szczególności koncentruje się na mniejszej pracy na niewłaściwej rzeczy, a bardziej na normalnej pracy na właściwej rzeczy; co nie oznacza więcej pracy , tylko bardziej produktywne .

Efektem ubocznym jest to, że bardzo szybko ujawnia luźnych i nieefektywnych lub nieudolnych. Co brzmi bardziej jak to, co masz.

Metodologia nie ma znaczenia, czy programista nie działa . Proces polega na tym, że nawet w wodospadzie przeglądy zarządzania i przeglądy kodu mogą również ujawnić te nic, tylko nie tak przejrzyste, jak większość metodologii Agile.

„Broń nie zabija ludzi. Ludzie zabijają ludzi!” Podobnie jest z Agile. Zwinność nie sprawia, że ​​ludzie pracują więcej, menedżerowie sprawiają, że ludzie pracują więcej.