Scrum i Kanban.
Co w nich lubicie a co was w nich denerwuje?
0
0
Lubię w nich fajne brzmienie i to że pozwalają zapełnić CV. Czego nie lubię - żadnego z nich nie rozumiem :(
3
Ja nie lubię, bo wiem o co w nich chodzi, więc muszę codziennie patrzeć jak wszelkie zasady są gwałcone w brutalny sposób. Na przykład, pracujemy w 'scrumie' ale nie robimy retrospektywy bo szkoda czasu.
0
Scrum posiada jeden plus, tzn. daily. Cała reszta IMO to syf, który można olać.
Kanban natomiast może spełniać się przy pracy taśmowej (helpdeski, wklepywanie danych itp.). Jeśli twoje jednostkowe zadanie może się diametralnie różnić od drugiego jednostkowego zadania to IMO też nie ma racji bytu - czyli to jest po prostu codzienność u zdecydowanej większości ludzi pracujących w projektach oraz na wyższych stanowiskach procesowych.
Z tego co zauważyłem zarówno "agile", "kanban" i "scrum" to w korporacjach głupie hasełka dla menedżerów i wszelkiej maści specjalistów od tych metodyk.
0
Uwazam, że scrum moze fajnie dzialac, tylko czesto dochodzi do patologii gdzie jest tylko ciągłe gadanie na meetingach. A scruma trzeba skroic na miare pod siebie.
Pracowalem w scrumie ze sprintami tygodniowymi, 5 os team. Planowanie jakies 1h, retri 15-30 min maksymalnie, grooming ~45min i codziennie daily ~ 10 min.
Nie dosc, ze Scrum nie przeszkadzal, to jeszcze pomagal.
Najfajniejsza to chyba jest jakas wizualizacja progresu na porządnie zrobionym boardzie na ktorym 'wszystko widac'.
3
Bzdety i zabawa dla duzych dzieci w przedszkolu typu openspace korporacja. Zlej to i zacznij czytać kod, książki i tzw white-papers róznych uczelni z tematów, które lubisz.
0
One Hacker Way - Erik Meijer
https://vimeo.com/110554082
0
Zakręcony Pomidor napisał(a):
Bzdety i zabawa dla duzych dzieci w przedszkolu typu openspace korporacja. Zlej to i zacznij czytać kod, książki i tzw white-papers róznych uczelni z tematów, które lubisz.
white-papers róznych uczelni czyli wlasciwie co? mozesz podac przyklad?
0
Kanban - przekonanie, że to, co się sprawdziło w hali fabrycznej sprawdzi się w zespole developerskim. Plus Kanban jest oczywiście pochodną "podejścia naukowego", tzn. zakłada, że wszystko co istotne da się zmierzyć.
Scrum - sama metodyka jest ok do pewnych zastosowań. Tyle tylko, że uważa się ją za uniwersalną. Jest takie powiedzenie: "Kiedy masz tylko młotek, to wszystko zaczyna przypominać gwóźdź", a wszelkiej maści Scrummasterowie zazwyczaj nie znają innych narzędzi.
0
Ponton napisał(a):
Zakręcony Pomidor napisał(a):
Bzdety i zabawa dla duzych dzieci w przedszkolu typu openspace korporacja. Zlej to i zacznij czytać kod, książki i tzw white-papers róznych uczelni z tematów, które lubisz.
white-papers róznych uczelni czyli wlasciwie co? mozesz podac przyklad?
np to: http://www.cs.zju.edu.cn/~gpan/course/materials/SURF.pdf
tego jest duzo w zaleznosci od specjalizacji, w której pracujesz. Kanban zlej to ci nic nie da bez wiedzy i doświadczenia.
1
Pracowałem w waterfall'u w poprzedniej pracy. Teraz w Scrumie, i co? W obecnej firmie, w tym samym okresie i zasobach ludzkich czasu potrafimy dowieźć około 3-5x więcej tasków. Jako, że scruma wcześniej nie było, to do wdrożenia pomocna również była i jest retrospektywa, na którą tak tu psioczą specjaliści ;) Ze sprintu na sprint jest coraz lepiej. Przyjemniejsza praca, wydajniejsza praca zespołu. Widać postęp. Podejrzewam, że osoby które tutaj tak wrzucają na Scruma są często źródłem problemu w zespołach :)
0
Nie będę się powtarzał, więc dam linka: Scrum nie działa
0
Co mi się bardzo podobało w SCRUM:
- zespół wspólnie dyskutuje nad estymatami, dzięki czemu estymaty odzwierciedlają opinię różnych osób i pewne kompromisy z tym związane
- retrospektywy: pod warunkiem, że są dość krótkie i staramy się rzeczywiście wyciągać wnioski z rzeczy, które nie do końca działają
- regularne dema wymuszane przez zakres sprintu
- stand-upy: pod warunkiem, że osoba biorąca udział w tego typu meetingu nie poświęca zbyt dużo czasu na wypowiedź, pozwalają w wygodny sposób zobaczyć co się dzieje w zespole. Jeśli stand-up nie działa być może warto zastąpić go np. krótkimi wiadomościami na firmowym czacie. Co robiłem wczoraj, co robie dziś.
- inwestor ma pewną wizualację tego w jaki sposób spalane są jego zasoby (burn down chart)
- miękka rola SCRUM mastera, który usuwa przeszkody przeszkadzające pracować deweloperom (większe projekty, na mniejszych nie ma to sensu)
Co mi się nie podoba:
- zbyt przesadne podejście do realizacji tylko zadań zaplanowanych w danym sprincie: to dość mało elastyczne, czasem zdrowy rozsądek wymaga po prostu, aby coś przesunąć
- SCRUM totalnie nie nadaje sę do zespołów 2-3 osobowych wtedy już lepiej używać znacznie bardziej zwinnej metodyki jaką jest XP, gdy projekt robi 1 osoba uważam to za kompletną stratę czasu
- zdarza się, że stand-upy są zbyt długie
Szczególnie miło wspominam pracę w niewspomnianej metodyce XP w momencie, gdy w projekcie mamy niedużą liczbę osób, dużą swobodę i bezpośrednich przedstawicieli klienta, którzy bardzo chętnie angażują się w rozwój systemu. Można sobie pozwolić na znacznie lepszą wydajność i szybsze dowożenie / demowanie niż w przypadku typowego SCRUM. Najważniejszy jest tutaj product owner, który jest w zasadzie częścią zespołu deweloperskiego, nawet jeśli jest to przedstawiciel klienta. Oczywiście to zadziała tylko dla specyficznych rodzajów projektów.
Kanban jest mi obcy. Waterfall jest mi obcy. W praktyce zdrowy rozsądek i tak wymusi pewne podejście hybrydowe niezależnie od tego jaka metodyka jest stosowana. Nie wierzę w fanatyczne podejście do SCRUM. Trzeba sobie wyselekcjonować konkretne praktyki, które odpowiadają potrzebom konkretnego zespołu. Jeśli coś nie działa należy to odrzucić.