Agile / Scrum - początek

somekind napisał(a):

Chyba nie Uncle Bob... Z jego postów wynika, że on w ogóle nie zdaje sobie sprawy z tego, jak "agile" wygląda w praktyce i broni go jak zakonnica dziewictwa.

Ano. Poziom wpisów godny moderatora.

No dobra, ta dyskusja chyba mi wyjaśniła wszelkie zawiłości. Wystarczy po prostu tworzyć oprogramowanie i starać się to robić jak najlepiej ;)

Zwykle powtarzam, że: jeśli zespół dobry to i agile/scrum mu nie przeszkodzi.
Jakkolwiek:
w firmie gdzie obecnie pracuje całkiem ten SCRUM całkiem działa ( o zgrozo - bo nie zgadza się to z moimi uprzedzeniami i poprzednimi doświadczeniami:-) ).
Zastanawiałem się dlaczego i możliwe, że przez:

• lekkie olewanie velocity, burndown chartów i innego badziewia (to znaczy nawet czasem widzimy te wykresy, ale nikt nimi nikogo nie straszy),
• samo velocity jest co prawda używane do prognozowania.. ale uśrednione z 3 ostatnich sprintów, bo czasem mamy taki super sprint, że wyjdzie 0 (nikt nie płacze) :-),
• PO jest ludzki i jak mu mówimy, że trzeba zrefaktorować to po prostu przyjmuje do wiadomości,
• jak się nie da skończyć story dobrze z testowaniem i review - to przerzucamy na następny sprint - bez bólu,
• każdy mówi w swoim dialekcie (taki kraj) - nikt nikogo nie rozumie, więc i tak długie Stand-d**y nie mają sensu,
• robimy eksperymenty i czasem coś w procesie zmieniamy (nakaz pair programmijng, zakaz pair programming :-), itp...),
• no i my raczej utrzymanie i rozwój robimy - czasem wchodzi dużo nowych ficzerów - ale ogólnie jest technologicznie stabilnie (sąsiednie Teamy stosują kanban - co zdecydowanie bardziej pasuje do tego co robimy - u nas jakoś wygrali maniacy SCRUM (i nie moge tego ubić, a od jakiegoś czasu już mi się nie chce -skoro działa)).

Tak, że jak widać bajki się zdarzają - tym niemniej normalnie nie ryzykowałbym - nie każdy team wylosuje rozsądnego PO i managerów bez spinki.

neves napisał(a):

Scrum natomiast jest jedynie szczegółem implantacyjnym Agilu w odniesieniu do zarządzania procesem wytwarzania oprogramowania. I, tak, głównie, dotyczy mangmentu, ale proces wytwarzania oprogramowania to gra zespołowa, w której bierze udział znacznie więcej osób niż tylko programiści.

Jak Scrum ma się do Agile Manifesto, który mówi "interakcje pomiędzy ludźmi ponad procesy" (Individuals and interactions over processes and tools)?
Czy to nie znaczy przypadkiem, że Scrum to żaden agile, a jego zaprzeczenie?

somekind napisał(a):

Nie tworzy się całego systemu na raz, tylko dzieli na zadania, a tych w miesiąc już można trochę napisać. Przynajmniej tyle, by jakąś pierwszą wersję jakiegoś ekranu pokazać użytkownikowi.

Tak i w ten właśnie sposób powstaje beznadziejna architektura spaghetti.

wartek01 napisał(a):

Samo słowo Agile oznacza metodyki lekkie, tj. takie które kładą nacisk na iteracyjność procesu wytwórczego i minimalizację okładu na komunikację. Co samo w sobie jest całkiem OK.

To też ciekawe, szczególnie że jak zrobisz jakiegoś user story i widać, że czegoś zabrakło to kolejną szansę na pracę nad tym brakującym elementem możesz mieć za rok jak PO nada temu niski priorytet :) Gdzie tu więc iteracyjność procesu wytwórczego, jeżeli za rok tego taska podniesie ktoś zupełnie inny? :D

Ostatnio u Mariusza Gila ukazał się kolejny odcinek podcastu właśnie w tym temacie - pozostaje tylko odesłać: https://bettersoftwaredesign.pl/episodes/54

snakeomeister napisał(a):

Tak i w ten właśnie sposób powstaje beznadziejna architektura spaghetti.

Not even wrong.
Spaghetti wyklucza architekturę.
A to, jaki kod powstanie wynika z podejścia i umiejętności jego twórców, a nie z tego, czy tworzą cały produkt na raz, czy ficzer po ficzerze.

snakeomeister napisał(a):

Jak Scrum ma się do Agile Manifesto, który mówi "interakcje pomiędzy ludźmi ponad procesy" (Individuals and interactions over processes and tools)?
Czy to nie znaczy przypadkiem, że Scrum to żaden agile, a jego zaprzeczenie?

Oczywiście, że jest to zaprzeczenie, chociaż zwykle mało szkodliwe. Są gorsze choroby.

somekind napisał(a):

Tak i w ten właśnie sposób powstaje beznadziejna architektura spaghetti.

To akurat bzdura. Od strony technicznej dość dobrze znane są (w każdym razie w literaturze...) wzorce pozwalające uniknąć pułapek wynikających z ciągłej zmiany.

wartek01 napisał(a):

To też ciekawe, szczególnie że jak zrobisz jakiegoś user story i widać, że czegoś zabrakło to kolejną szansę na pracę nad tym brakującym elementem możesz mieć za rok jak PO nada temu niski priorytet :) Gdzie tu więc iteracyjność procesu wytwórczego, jeżeli za rok tego taska podniesie ktoś zupełnie inny? :D

Ale to nie jest wina podejścia zwinnego, że zatrudnili ci idiotę na POsa. Szczególnie, że jeżeli jest to coś potrzebnego, to powinno zostać zrobione w ramach DoD dla taska. Problem z agile jest taki, że zakłada zaangażowanie i dojrzałość wszystkich członków zespołu. A często jest tak, że połowa technicznych ma wywalone, druga połowa to miękkie faje, do tego nikt w zespole nie jest w stanie powiedzieć w ludzkich słowach dlaczego np. trzeba poprawić testy. Kończy się tym, że rolę lidera technicznego faktycznie pełni gość po jakiejś politologii.

piotrpo napisał(a):

To akurat bzdura. Od strony technicznej dość dobrze znane są (w każdym razie w literaturze...) wzorce pozwalające uniknąć pułapek wynikających z ciągłej zmiany.

Jakie to są wzorce, jeżeli można spytać?

Całe DDD, separacja warstw, wzorce projektowe dla programowania obiektowego. Do tego TTD + ciągły refaktoring.

piotrpo napisał(a):

Kończy się tym, że rolę lidera technicznego faktycznie pełni gość po jakiejś politologii.

Niech będzie nawet po wyższej szkole robienia hałasu - Tak długo jak ma wiedze i ma coś sensownego do powiedzenia.

Najgorszy jest TL, który nie ma wiedzy, nie ma nic sensownego do powiedzenia, ale za to żyję w odwrotnym przekonaniu + jest pato agile oszołomem. Miałem takiego (Dodatkowo zrobił certyfikat na Scrum Mastera :D) i nikomu nie życzę takiego "lidera". Mgr-Inż informatyki na PW.