Temat: Negatywne aspekty scruma

Zasadniczo wszyscy doceniamy zalety i korzyści płynące ze stosowania scruma w projektach. Typowe jest też mocno entuzjastyczne podejście do tego sposobu zarządzania, poczucie znalezienia złotego środka, klucza do sukcesu, trwałej przewagi konkurencyjnej, obrania jedynej właściwej drogi. Przekłada się to na bardzo pozytywne postrzeganie wszystkich technik i narzędzi z pod znaku agile oraz lekko pogardliwą niechęć do "tradycyjnych" metod zarządzania projektami. Krótko mówiąc stosując scruma czujemy się lepsi od reszty świata, która go jeszcze nie odkryła / nie doceniła. Popadamy w mentorski ton. Sam często się na tym łapię. Pytanie brzmi: czy potrafimy dostrzec również negatywne praktyczne aspekty scruma, skutki uboczne jego zastosowania?

Jako inicjator tego wątku postaram się pierwszy udzielić odpowiedzi. Według mnie negatywne mogą być:
- opisane powyżej poczucie zaślepienia - "jeśli mamy scruma, to jesteśmy najlepsi"
- nadawanie scrumowi/agile wymiaru uniwerslanego "scrum jest [optymalną] metodologią robienia czegoś" - "bo scrum jest wszechstronny"
- zapominanie o tym, że "self management does not lack of discipline" - skuteczny scrum jest wtedy, kiedy w jego wdrożenie włożymy dużo pracy
- brak konsekwencji w stosowaniu reguł scruma, łatwość modyfikacji... "na pure scrum mamy czas"
Tymczasem reguły scruma gwarantują jego spójność. Ken Schwaber twierdzi, że scrum powinien być stosowany kompleksowo z całym dobrodziejstwem inwentarza, a każde odejście od jego zasad i ew. modyfikacje mogą być wprowadzane jedynie przez bardzo doświadczone i zgrane zespoły, z ich własnej inicjatywy - nigdy odgórnie. Nawet najmniejsze zmiany powinny być implementowane bardzo ostrożnie, ponieważ scrum został bardzo dobrze opracowany i dogłebnie przetestowany w bardzo wielu projektach, w wielu organizacjach - jego pierwotnie zdefiniowany kształt jest sprawdzony, a jego skuteczność potwierdzona empirycznie.
- skłonność do przeciążenia / przeformalizowania (poczucie braku "ciężkich narzędzi") - nawyki z tradycyjnych projektów prowadzą do nadbudowywania scruma kolejnymi, sztywnymi zasadami i instrumentami (np. wykresami Gantta) - odbywa się to kosztem elastyczności i utraty zdolności do improwizacji - scrum przestaje być "lekki". Świnie tracą pole manewru do samoorganizacji.
- trudności z przekonaniem klienta do współpracy opartej na regułach scrum - "no fixed price, no deadline" jest ciężkie do zaakceptowania, a rola product ownera wymaga sporego zaangażowania

Podsumowując; zauważyłem, że w/w czynniki negatywne nie są wadami scruma samego w sobie, ale ograniczeniami mentalnymi. "Scrum, najbardziej wprawiający w zakłopotanie i paradoksalny proces do zarządzania skomplikowanymi projektami".Bartosz Kramek edytował(a) ten post dnia 16.02.08 o godzinie 14:46

Temat: Negatywne aspekty scruma

Halo! Co w scrumie jest nie-halo?

Temat: Negatywne aspekty scruma

Scrum jest trudny. To jest jego największą pułapką - z pozoru prosta metodyka, ale jest wiele pułapek.
Po pierwsze wymaga bardzo dobrych zdolności komunikacyjnych. Wszystkie sprawy muszą być rozwiązywane w bardzo krótkim czasie.
Kolejną rzeczą o której trzeba pamiętać jest to, że Scrum wymaga dużego zaangażowania obu ze stron (klient i wykonawca) inaczej bardzo dużo traci ze swojego uroku.
Po trzecie trzeba mieć świetny micromanagement. Planujemy krótkie sprinty, więc często jest tak, że mamy bardzo dużo rzeczy do upchnięcia w krótkim czasie. Zdarzają się sytuacje, kiedy z dnia na dzień pojawia się potrzeba nowych informacji, aby móc kontynuować projekt. Jeżeli nie zostanie to dobrze zorganizowane to projekt będzie leżał i czekał, aż informacje się pojawią.
Planowanie w trakcie realizacji projektu potrafi być dość kłopotliwe i mimo wszystko powinno być ograniczane do minimum. Sprint planning powinien wyłapać jak najwięcej potencjalnych problemów i od razu je zabezpieczyć.
Oprócz tego jest jeszcze wiele innych pułapek w Scrumie...Robert Nasiadek edytował(a) ten post dnia 14.10.08 o godzinie 23:05

Temat: Negatywne aspekty scruma

Bartosz Kramek:
Halo! Co w scrumie jest nie-halo?

Nie każdy :
* projekt nadaje się do scruma
* pamięta o tym żeby znać przynajmniej 1 skuteczną metodykę oprócz SCRUMa
* klient nadaje się na Product Ownera
* Developer nadaje się na Scrum Mastera
* kto twierdzi że Scrumuje Scrum realizujePiotr T. edytował(a) ten post dnia 14.10.08 o godzinie 22:13

Temat: Negatywne aspekty scruma

Robert Nasiadek:
z pozoru prosta metodyka, ale jest wiele pułapek.

Agreed. Jedną z trudniejszych do uniknięcia jest pakowanie na siłę nowych zadań (bugfixy, funkcjonalności które "też miały być w tym") do sprintu, który miał się skończyć "wczoraj", zamiast zwyczajnie zostawić pewne rzeczy rozgrzebane i niedokończone, do połatania w następnym sprincie.
Przedłużający się sprint - choćby i była to wyłącznie kwestia zmiany numerka w bugtrackerze - działa demotywująco na developerów i powoduje zmęczenie psychiczne, jak każde sukcesywne odsuwanie celu w miarę kolejnych kroków.

[nie każdy] * Developer nadaje się na Scrum Mastera

A ktoś twierdził że każdy się nadaje? Nie oddam za nic przyjemności pisania kodu, w zamian za zadanie bardzo managementowe i "miękkie" (nietechniczne) ;)

Temat: Negatywne aspekty scruma

Tomasz Stachewicz:

[nie każdy] * Developer nadaje się na Scrum Mastera

A ktoś twierdził że każdy się nadaje? Nie oddam za nic przyjemności pisania kodu, w zamian za zadanie bardzo managementowe i "miękkie" (nietechniczne) ;)

To tak na wszelki wypadek ;) .Piotr T. edytował(a) ten post dnia 15.10.08 o godzinie 09:05

Temat: Negatywne aspekty scruma

Piotr T.:

Nie każdy :
* projekt nadaje się do scruma

Bo? Przyklad?

* pamięta o tym żeby znać przynajmniej 1 skuteczną metodykę oprócz SCRUMa

Waterfall znaja juz wszyscy, ale do czego to jest w Scrumie potrzebne?

* klient nadaje się na Product Ownera

Dlaczego?

* Developer nadaje się na Scrum Mastera

A kto mowi, ze developer ma byc Scrum Masterem? Scrum Master moze byc zupelnie spoza Delivery Teamu.

* kto twierdzi że Scrumuje Scrum realizuje

W jakim sensie jest to wada Scrumu? Rownie dobrze mozna wysnuc stwierdzenie ze wada samochodow jest to, ze nie kazdy kto ma prawo jazdy potrafi dobrze jezdzic :)

Piotr T.

edytował(a) ten post dnia 14.10.08 o godzinie 22:13

Temat: Negatywne aspekty scruma

Właśnie, cały czas nie rozumiem dlaczego to klient ma być (w opinii niektórych) Product Ownerem, zamiast po prostu zaufanego człowieka ze strony klienta, któremu ten ostatni powierza odpowiedzialność za wspólną wizję?

Temat: Negatywne aspekty scruma

Tomasz Stachewicz:
Właśnie, cały czas nie rozumiem dlaczego to klient ma być (w opinii niektórych) Product Ownerem, zamiast po prostu zaufanego człowieka ze strony klienta, któremu ten ostatni powierza odpowiedzialność za wspólną wizję?

Może być nim również analityk biznesowy (klienta) lub PM (dostawcy lub klienta) .
Poza tym klient wcale nie musi uważać że SCRUM jest dla niego korzystny a sami reprezentanci klienta nie muszą być świadomi swojej roli.Piotr T. edytował(a) ten post dnia 15.10.08 o godzinie 22:01

Temat: Negatywne aspekty scruma

Krystian K.:

Piotr T.:

Nie każdy :
* projekt nadaje się do scruma

Bo? Przyklad?

*Krótszy niż tydzień. Bo stracisz 30% czasu na demo,planowanie i prezentację.
*Projekty typu "wszystko albo nic" ponieważ częściowe wdrożenie projektu generuje straty.

* pamięta o tym żeby znać przynajmniej 1 skuteczną metodykę oprócz SCRUMa

Waterfall znaja juz wszyscy, ale do czego to jest w Scrumie potrzebne?

Żeby użyć innej metodyki jeśli lepiej się nadaje do projektu.

* klient nadaje się na Product Ownera

Dlaczego?

Bo nie chce nim być lub stosuje inną metodykę lub wykazuje niewłaściwą postawę .

* Developer nadaje się na Scrum Mastera

A kto mowi, ze developer ma byc Scrum Masterem? Scrum Master moze byc zupelnie spoza Delivery Teamu.

To kto powinien być scrum masterem Tester,Wdrożeniowiec,Analityk,PM,Architekt,KAM ? Chyba że to dodatkowe stanowisko pracy :).

* kto twierdzi że Scrumuje Scrum realizuje

W przypadku RUPa , programowania odkrywczego , metodyk "bez znanej nazwy" nie spotkałem się z taką sytuacją a przy SCRUMie tak i to kilkakrotnie (w 3 różnych projektach). Chociaż sądzę że to kwestia postrzegania zwinnych metod wytwarzania oprogramowania .

Piotr T.

edytował(a) ten post dnia 14.10.08 o godzinie 22:13

Temat: Negatywne aspekty scruma

Piotr T.:

*Krótszy niż tydzień. Bo stracisz 30% czasu na demo,planowanie i prezentację.

Dlaczego? Na treingu robilismy projekt,ktory w sumie mial 59 minut, kazdy sprint trwal 8 minut. I udalo sie. W tygodniowym projekcie wogole nie planujesz, bo nie ma czasu? I okazuje sie ze wypuszczasz cos, co nie jest zgodne z potrzebami klienta, co wtedy? Jeszcze jeden tydzien i ta sama historia?

*Projekty typu "wszystko albo nic" ponieważ częściowe wdrożenie projektu generuje straty.

Nie wiem co to za typ projektu "wszystko albo nic", ale przypuszczam ze chodzi o pelna wersje produktu jak na przyklad projekt migracji.
Wowczas:
1. Szybciej poznajesz problemy z nowa technologia
2. Jestes w stanie szybciej ocenic
3. Moze sie okazac, ze na release klient tak na prawde nie potrzebuje pewnych rzeczy, ktore juz tam byly i mozna to zrobic w fazie maintenance.
4. Jesli jednak trzeba dostarczyc wszystko, to postep jest widoczny jak na dloni i na podstawie Backlog Burndown mozna oszacowac velocity i probowac zwiekszyc team, albo liczbe teamow jezeli nie mozna zmienic daty releasu. Szybciej wiesz, ze bez kontraktorow nie pociagniesz, albo ze nie ma wystarczajacych kompetencji w zespole i sa porzebni konsultanci.

To ze pojdziesz waterfall, nie oznacza ze dostarczysz szybciej i lepiej. Prawdopodobnie obetniesz testowanie, bo nie bedzie czasu i klient dostanie nowa platforme, ktora ma wiecej bugow i rozwiazan na skroty niz poprzednia. Myslisz ze projekt jest wtedy sukcesem? Ze dostaniesz kolejne zlecenie?

* pamięta o tym żeby znać przynajmniej 1 skuteczną metodykę oprócz SCRUMa

Waterfall znaja juz wszyscy, ale do czego to jest w Scrumie potrzebne?

Żeby użyć innej metodyki jeśli lepiej się nadaje do projektu.

Lepiej sie nadaje, czy latwiej jest sie obrazic na Scrum i sie nie meczyc? :-)

* klient nadaje się na Product Ownera

Dlaczego?

Bo nie chce nim być lub stosuje inną metodykę lub wykazuje niewłaściwą postawę .

Jaka metodyke stosuje klient? :-) Jezeli klient jest dobrze poinformowany o postepach, problemach i ryzyku latwiej moze dostosowac swoje procesy, na przyklad wstrzymac marketing. Klient moze tez latwiej zmienic priorytety i zdecydowac ze feature K jest wazniejszy niz A i powinien byc w nazstepnym sprincie. Jezeli klient po kazdym Sprincie ma dzialajaca wersje poduktu, ktora potencjalnie mozna dostarczyc i za kazdym razem ma wiecej featurow, ktore moze sprzedac, dlaczego ma byc ne zadowolony ze Scrumem?
I co to znaczy ze klient ma nie wlsciwa postawe? Nie kazdy jest developerem i ludzie z podejsciem biznesowym maja inne podejscie do proektu. Moze trzeba sobie zadac pytanie: tworze oprogramowanie, zeby robic to co lubie, czy sprzedac je i zadowolic klienta, zbudowac relacje? Moze to Ty masz zla postawe?

* Developer nadaje się na Scrum Mastera

A kto mowi, ze developer ma byc Scrum Masterem? Scrum Master moze byc zupelnie spoza Delivery Teamu.

To kto powinien być scrum masterem Tester,Wdrożeniowiec,Analityk,PM,Architekt,KAM ? Chyba że to dodatkowe stanowisko pracy :).

Czasem to jest dodatkowe stanowisko pracy, jak juz wspominalem Scrum Master moze pracowac z kilkoma zespolami. Kazda z wymienionych przez Ciebie osob moze byc Scrum Masterem, z tym ze, trzeba byc ostroznym z PM. Zespol moze na spotkaniach raportowac do niego, zamiast do zespolu i ukrywac problemy w Sprincie. Slyszalem wlasnie o teamie, ktory mial 2 Sprint Burndowny: 1 na scianie, ktory byl calkiem ladny, drugi schowany i ten byl realny. Wszystko wyszlo na jaw po sciagnieciu zewnetrznego Scrum mastera na konsultacje.

* kto twierdzi że Scrumuje Scrum realizuje

W przypadku RUPa , programowania odkrywczego , metodyk "bez znanej nazwy" nie spotkałem się z taką sytuacją a przy SCRUMie tak i to kilkakrotnie (w 3 różnych projektach). Chociaż sądzę że to kwestia postrzegania zwinnych metod wytwarzania oprogramowania

metodyk "bez znanej nazwy" - lubisz tworzyc terminologie, co? :-)

Jak juz ylo tutaj wspomniane Scrum jest trudny, wymaga dyscypliny. Co mozna zrobic zle w waterfallu? Idziesz krok po kroku, a potem najwyzej sie okaze, ze zabraklo czasu.

Temat: Negatywne aspekty scruma

Krystian K.:

Piotr T.:

*Krótszy niż tydzień. Bo stracisz 30% czasu na demo,planowanie i prezentację.

Dlaczego? Na treingu robilismy projekt,ktory w sumie mial 59 minut, kazdy sprint trwal 8 minut. I udalo sie. W tygodniowym projekcie wogole nie planujesz, bo nie ma czasu? I okazuje sie ze
wypuszczasz cos, co nie jest zgodne z potrzebami klienta, co wtedy? Jeszcze jeden tydzien i ta sama historia?

trening to trening jak zrobisz projekt 3 dniowy SCRUMem to będziesz miał się czym pochwalić. Analiza wykonalności,wyznaczenie ścieżki krytycznej,wytworzenie,testy,wdrożenie.

*Projekty typu "wszystko albo nic" ponieważ częściowe wdrożenie projektu generuje straty.

Nie wiem co to za typ projektu "wszystko albo nic", ale przypuszczam ze chodzi o pelna wersje produktu jak na przyklad projekt migracji.
Wowczas:
1. Szybciej poznajesz problemy z nowa technologia
2. Jestes w stanie szybciej ocenic
3. Moze sie okazac, ze na release klient tak na prawde nie potrzebuje pewnych rzeczy, ktore juz tam byly i mozna to zrobic w fazie maintenance.
4. Jesli jednak trzeba dostarczyc wszystko, to postep jest widoczny jak na dloni i na podstawie Backlog Burndown mozna oszacowac velocity i probowac zwiekszyc team, albo liczbe teamow jezeli nie mozna zmienic daty releasu. Szybciej wiesz, ze bez kontraktorow nie pociagniesz, albo ze nie ma wystarczajacych kompetencji w zespole i sa porzebni konsultanci.

To ze pojdziesz waterfall, nie oznacza ze dostarczysz szybciej i lepiej. Prawdopodobnie obetniesz testowanie, bo nie bedzie czasu i klient dostanie nowa platforme, ktora ma wiecej bugow i rozwiazan na skroty niz poprzednia. Myslisz ze projekt jest wtedy sukcesem?

* pamięta o tym żeby znać przynajmniej 1 skuteczną metodykę oprócz SCRUMa

Waterfall znaja juz wszyscy, ale do czego to jest w Scrumie potrzebne?

Żeby użyć innej metodyki jeśli lepiej się nadaje do projektu.

Lepiej sie nadaje, czy latwiej jest sie obrazic na Scrum i sie nie meczyc? :-)

To brzmi już cokolwiek fanatycznie. PM który zna jedną metodykę to jak programista co zna jeden Framework .

* klient nadaje się na Product Ownera

Dlaczego?

Bo nie chce nim być lub stosuje inną metodykę lub wykazuje niewłaściwą postawę .

Jaka metodyke stosuje klient? :-) Jezeli klient jest dobrze poinformowany o postepach, problemach i ryzyku latwiej moze dostosowac swoje procesy, na przyklad wstrzymac marketing. Klient moze tez latwiej zmienic priorytety i zdecydowac ze feature K jest wazniejszy niz A i powinien byc w nazstepnym sprincie. Jezeli klient po kazdym Sprincie ma dzialajaca wersje poduktu, ktora potencjalnie mozna dostarczyc i za kazdym razem ma wiecej featurow, ktore moze sprzedac, dlaczego ma byc ne zadowolony ze Scrumem?
I co to znaczy ze klient ma nie wlsciwa postawe? Nie kazdy
developerem i ludzie z podejsciem biznesowym maja inne podejscie do proektu. Moze trzeba sobie zadac pytanie: tworze oprogramowanie, zeby robic to co lubie, czy sprzedac je i zadowolic klienta, zbudowac relacje? Moze to Ty masz zla postawe?

postawa typu: "ależ to bardzo proste"

* Developer nadaje się na Scrum Mastera

A kto mowi, ze developer ma byc Scrum Masterem? Scrum Master moze byc zupelnie spoza Delivery Teamu.

To kto powinien być scrum masterem Tester,Wdrożeniowiec,Analityk,PM,Architekt,KAM ? Chyba że to dodatkowe stanowisko pracy :).

Czasem to jest dodatkowe stanowisko pracy, jak juz wspominalem Scrum Master moze pracowac z kilkoma zespolami. Kazda z wymienionych przez Ciebie osob moze byc Scrum Masterem, z tym ze, trzeba byc ostroznym z PM. Zespol moze na spotkaniach raportowac do niego, zamiast do zespolu i ukrywac problemy w Sprincie. Slyszalem wlasnie o teamie, ktory mial 2 Sprint Burndowny: 1 na scianie, ktory byl calkiem ladny, drugi schowany i ten byl realny. Wszystko wyszlo na jaw po sciagnieciu zewnetrznego Scrum mastera na konsultacje.

No i wyszło że nie każdy PM się nadaje na scrum mastera :).

* kto twierdzi że Scrumuje Scrum realizuje

W przypadku RUPa , programowania odkrywczego , metodyk

>"bez znanej nazwy" nie spotkałem się z taką sytuacją a przy

SCRUMie tak i to kilkakrotnie (w 3 różnych projektach). Chociaż sądzę że to kwestia postrzegania zwinnych metod wytwarzania oprogramowania

metodyk "bez znanej nazwy" - lubisz tworzyc terminologie, co? :-)

Niech Ci będzie metodyki własne organizacji.

Jak juz ylo tutaj wspomniane Scrum jest trudny, wymaga dyscypliny. Co mozna zrobic zle w waterfallu? Idziesz krok po kroku, a potem najwyzej sie okaze, ze zabraklo czasu.

Chodzi właśnie o to żeby nie zabrakło czasu .

Temat: Negatywne aspekty scruma

Piotr T.:

trening to trening jak zrobisz projekt 3 dniowy SCRUMem to będziesz miał się czym pochwalić. Analiza wykonalności,wyznaczenie ścieżki krytycznej,wytworzenie,testy,wdrożenie.

Jak na taki trafie, to go zrobie. Poki co trafiaja sie roczne i wieksze.

postawa typu: "ależ to bardzo proste"

Napisalem tylko, ze jezeli od razu nie wychodzi, to trzeba nad tym popracowac, a nie zalamywac rece i isc w to co znamy.

No i wyszło że nie każdy PM się nadaje na scrum mastera :).

Bo tak jest. Poczytaj troche artykulow na ten temat. Scrum wymaga bardzo wiele w zmiane postawy PMa jezli chce wdrozyc Scrum i jeszcze wiecej jezeli chce byc Scrum Masterem.

Polecam pogooglac za "How to fail with Agile"

Chodzi właśnie o to żeby nie zabrakło czasu .

Projekt ma 3 glowne zmienne: czas, jakosc, zasoby. Jedna z nich moze byc stala, reszty nie da sie utrzymac.

Temat: Negatywne aspekty scruma

Krystian K.:

Piotr T.:
trening to trening jak zrobisz projekt 3 dniowy SCRUMem to będziesz miał się czym pochwalić. Analiza wykonalności,wyznaczenie ścieżki krytycznej,wytworzenie,testy,wdrożenie.

Jak na taki trafie, to go zrobie.

[cut]

Ale po co? Dla zasady? Scrum to nie jest lekarstwo na wszytsko.
W mojej opini świetnie się sprawdza tam, gdzie trudno na początku dokładnie zdefiniować potrzeby biznesu, albo, co więcej, sam biznes nie do końca jest świadomy czego potrzebuje. Jeśli wymagania są jednak małe i jasno określone to szkoda zachodu. Wylejemy dziecko z kąpielą.

pozdrawiam serdeczniePrzemek Tarczyński edytował(a) ten post dnia 26.10.08 o godzinie 22:28

Temat: Negatywne aspekty scruma

Krystian K.:
Projekt ma 3 glowne zmienne: czas, jakosc, zasoby. Jedna z nich moze byc stala, reszty nie da sie utrzymac.

Czyli nie można utrzymać i czasu i jakości jednocześnie? To chyba coś nie tak z tym Scrumem ;)

Temat: Negatywne aspekty scruma

Piotr Słowik:

Krystian K.:
Projekt ma 3 glowne zmienne: czas, jakosc, zasoby. Jedna z nich moze byc stala, reszty nie da sie utrzymac.

Czyli nie można utrzymać i czasu i jakości jednocześnie? To chyba coś nie tak z tym Scrumem ;)

Jest jeszcze zakres .

Temat: Negatywne aspekty scruma

Akurat ostatnio zastanawiałem się nad SCRUMem na żywym organizmie i wyciągnąłem podobne wnioski jak część piszących. Z częścią nie mogę się zgodzić niestety.

http://blog.sielay.com/2009/02/03/scrum-a-rzeczywistosc/

Co myślicie o takim przypadku?

Temat: Negatywne aspekty scruma

hmm, jeśli dobrze zrozumiałem Twój tekst to:

- w opisanym przez Ciebie przypadku święty Boże nie pomoże. I nie jest to wina Scruma, tylko organizacji firmy. Jeśli działy prowadzą między sobą podstępną wojnę podjazdową to projekt przestaje mieć jasne cele, które można by zrealizować. A jeśli ich nie ma to na jakiej podstawie można mówić o porażce lub zwycięstwie?

- długość i zakres sprintu nie jest świętością, której nie można "bezcześcić" - jeśli w krótkim czasie diametralnie zmieniają się założenia to kończymy sprint przed czasem, wprowadzamy zmiany i zaczynamy nowy (jeśli zmiany są duże). Jeśli zmiany są niewielkie to modyfikujemy nie zrobione jeszcze tickety (co w najgorszym wypadku przedłuży nam sprint), a poprawki do tych zrobionych w zależności od potrzeb albo wrzucamy do Backlogu, albo do sprintu z wysokim priorytetem.

- abstrahując od wszystkiego. Według mnie w takiej sytuacji najlepszym rozwiązaniem jest szczera rozmowa Scrum Mastera z szefem/klientem/zarządem. Bardzo często organizacja pracy firmy znacznie się poprawia, a założenia mniej ewoluują, jeśli siły zwierzchnie mają świadomość ile przez takie zmiany traci się pieniędzy (kod, który został napisany, a który nie będzie wykorzystany), jak przedłuża się proces developerski, i że przy nowych założeniach nie ma szans na wyrobienie się na nieprzekraczalny termin, z którego ktoś (szef/zarząd/klient) będzie rozliczony przez inwestorów.

- jeśli zaś nie gonią nas ani terminy, ani budżety to postawione przez Ciebie problemy stają się jedynie (przepraszam za określenie) upierdliwościami, a nie blokerami całej metodyki.

Temat: Negatywne aspekty scruma

Dzieki. Z Twojej odpowiedzi w swoim odczuciu rozumiem, ze zrozumialem problem ponownie (nie pije do tresci bloga, ale do reakcji na miejscu). Niestety. Z mojego skromnego doswiadczenia wynika, ze takie rozmowy nie zawsze daja rade. Dlatego szukam narzedzia jeszcze bardziej elastycznego i rownie bugo-odpornego.

Dzieki :)

Temat: Negatywne aspekty scruma

Łukasz Marek Sielski:
Akurat ostatnio zastanawiałem się nad SCRUMem na żywym organizmie

Zabawne - Scrum i metodyki agile'owe, z racji transparentności (i jeszcze paru innych zmian) całego procesu tworzenia oprogramowania, wybijają "programistów-teoretyków", którzy zamiast rozwiązywania problemów wolą deliberować o projektowaniu i nie wykonywać realnej pracy nad pisaniem kodu.

Ale, jak widać, zachęca do teoretyzowania z kolei potencjalnym SMów.

Kiedy robiło się w grupie projekty na studiach, takie podejście przerywało krótkie "przestań pi*****ić, po prostu to zrób i zobacz jak działa" ;)Tomasz Stachewicz edytował(a) ten post dnia 03.02.09 o godzinie 16:33