Forum Praca Praca
ZMIEŃ
    Dodaj do ulubionych

    Programiści scrumują

    IP: 95.83.206.* 09.02.13, 13:52
    Bla, bla, bla... korporacyjny bełkot.
    Edytor zaawansowany
    • Gość: qwert IP: *.156.175.9.ip.dev.euron.pl 09.02.13, 14:16
      No jasne, kolejny sposób "góry" żeby jak najwięcej zachrzaniać na akcjonariuszy za te same pln'y. Wzrost wydajności = spadek kosztów przy danym efekcie :-) a baranki idą dalej. Pracujecie aby żyć czy żyjecie aby pracować ?
    • Gość: Wróć komuno! IP: *.adsl.inetia.pl 09.02.13, 19:47
      Gość portalu: qwert napisał(a):

      > No jasne, kolejny sposób "góry" żeby jak najwięcej zachrzaniać na akcjonariuszy
      > za te same pln'y. Wzrost wydajności = spadek kosztów przy danym efekcie :-)

      Łaaaał!
      To ONI to robią DLA PIENIĘDZY?
      Może te całe ICH biznesy - też są dla pieniędzy???
      Jejku! Nie wiedzieliśmy!

      Czyli pracownikowi nie powinno zależeć na wzroście wydajności?
      No tak, mniejsza wydajność, to mniej produktu, mniejszy zysk...
      To się trzyma kupy - przecież chodzi o to, by zadusić burżuja, niech zbankrutuje, a premie i nagrody od zysku niech sobie w buty wsadzi!
      Dokładnie to samo podejście stosował niejaki Grzesiuk, ale to było w nieco innych realiach...

    • Gość: Aspa IP: 89.204.199.* 09.02.13, 22:50
      Akurat w informatyce, jeśli chodzi o tworzenie softu - tzw. wzrost wydajnosci często łączy się ze spadkiem jakości gotowego produktu.
    • Gość: K. IP: *.warszawa.vectranet.pl 10.02.13, 09:52
      Tylko dziwnym trafem akurat scrum gdzie indziej szuka wzrostu wydajności - w niedostarczaniu zbędnej funkcjonalności.
    • Gość: moe IP: *.homenett.pl 10.02.13, 12:19
      niz wy znajomych ;)
    • Gość: babulinka IP: *.neoplus.adsl.tpnet.pl 09.02.13, 14:40
      Scrum jest OK, ale wprowadzanie go w korporacjach przeważnie przynosi więcej szkod niż pożytku, gdyż ostatecznie mamy do czynienia z jakims patologicznym tworem, który tylko z nazwy jest Scrumem.

      Najczesciej wprowadza sie agile / zwinne praktyki, żeby zarzadzajacy byli zadowoleni, bo gdzies tam przeczytali czy usłyszeli, ze powinno się w firmach wprowadzać agile/scrum, gdyz to przynosi swietne efekty. A i owszem, ale tylko tam gdzie organizacja jest zdrowa i odpowiednie srodowisko, czyli nie dotyczy to 90% korporacji, gdzie przyspawani do stolkow managerowie, którzy g* wiedza o programowaniu panicznie boja się utracic kontrole nad zespolem.

      Dlatego w praktyce jest tak, ze na końcu ludzie udaja, ze prowadza projekty wg praktyk zwinnych (agile), a zarzadzajacy udaja, ze w to wierza (i mogą się tym chwalić na zewnątrz). Z tegoz samego powodu te opowieści jakichś laseczek z HRu, iz po wprowadzeniu Scruma wszelkie problemy zniknely jak za dotknieciem czarodziejskiej rozdzki można wlozyc miedzy bajki.
    • Gość: programista IP: *.dynamic.chello.pl 09.02.13, 15:34
      poza tym scrum nie nadaje sie do wszystkiego, a po wprowadzeniu w firmie jest do wszystkiego stosowany.
      potem zdziwienie ze prze zostatnie 2 lata 90% projektow padlo bez efektu koncowego, a firma nie zarabia.
    • Gość: qwert IP: *.neoplus.adsl.tpnet.pl 09.02.13, 18:25
      Najlepiej to podsumował szef Dilberta: dilbert.com/strips/comic/2007-11-26/
      U mnie też jest coś scrumopodobnego. Problem w tym, że zespół projektowy liczy jakieś 40 osób, w 4 państwach, na 3 kontynentach, więc stand-upy trwają często z godzinę i poza PMami nikt nikogo nie słucha.
    • Gość: K. IP: *.warszawa.vectranet.pl 09.02.13, 19:16
      Wydaje mi się, że każdy wie, że przy sporych projektach (a 40 programistów to nie jest mały zespół) agile się nie sprawdza. Na studiach tego nawet uczą.
    • Gość: br00net IP: 193.200.51.* 10.02.13, 15:59
      Tak to jest jak inteligenci zabierają się za scurma. Z tego co napisałeś to naruszyliście wszystkie zasady postępowania w tej metodyce, a to oznacza że nie masz prawa nazywać tego scrumem.
    • Gość: tia IP: *.play-internet.pl 10.02.13, 20:49
      w jednej z korpo, dla której pracowałem Scrum zamienił się w nak**wianie kodu na pałę, oczywiście bez żadnej dokumentacji osiągnięć. Co najwyżej jest JIRA z jednozdaniowym opisem co się robi. Testy automatyczne? praktycznie brak; Scenariusze użytkownika dla testerów - w szczątkach; a później awantura i rollbacki z komputerów klienta.

      We Wrocku jest jedna firma (polska quasi korporacja, spółeczka dwóch gigantów z branży tel-kom, wtajemniczeni po takim opisie wiedzą o co cho) i ona wypuszcza tabuny scrum masterów. Problem w tym, że tam te scrumy też różnie wyglądają (właściwie to nie wyglądają), a projekty są słabiutkie i często zakończone fail'em. Później przychodzi taki człowieczek, że chciałby do dev albo qa w innej firmie, gdzie w życiu nie uczestniczył w prawdziwym procesie tworzenia i doskonalenia softu, a o zarządzaniu to tylko słyszał... bo przez ostatnie półtora roku jedynie udawał, że scrumuje
    • Gość: Przemek IP: *.tktelekom.pl 09.02.13, 20:15
      Brawo. Też takie rzeczy widziałem. To jest książkowy antypattern, jak nie implementować scruma.
    • szmecierecie 09.02.13, 22:02
      Heh, skądś jakbym to znał. Teraz też pracuję w międzynarodowym projekcie i codzienne scrumy trwające godzinę służą głównie do przeglądania internetu.

      Scrum guide jest krótkie, bardzo treściwe i jak każdy scrum master wie cholernie trudne do wdrożenia. Z resztą tak jak ktoś napisał, nie do wszystkiego się nadaje.


      --
      Dziennikarz - osoba niekompetentna, ale za to w wielu dziedzinach. pokazywarka.pl/przygarnijlokatora
    • Gość: srommaster IP: *.adsl.inetia.pl 10.02.13, 09:44
      A ja jestem SROMMASTER 33 levelu i wszyscy przede mną klękajcie, jako że kod mój nie ma sobie równych! Jam jest Destroyer, creator of the ultimate code! Gdy zakoduję deszcz, to nadchodzi potop.
    • edeco 10.02.13, 09:48
      ... zakoduj nam deszcza, please please, please
      Ja mam lvl 0,00009 i jak zakodowałem deszcza to pies naszczał mi w kuchni....
    • Gość: srommaster IP: *.adsl.inetia.pl 10.02.13, 10:46
      Wiele jeszcze sromow przed toba mlody koderze, ale nie martw sie! Jestes na dobrej drodze. Koduj deszcze uparcie dalej, ale psa do kuwety wstawiaj najpierw, bys mieszkania nie zafajdal sobie. Gdyz jednakowoz osiagniesz poziom trzeci, zdolasz zlego somsiada swego zalac deszczem, a zatem nagroda cenna czeka ciem.
    • rmarcin555 10.02.13, 18:36
      Nie rozumiem. Stand up dotyczy zespołu scrumowego. Zespół według zasad powinien liczyć od 7-9 osób. Niech liczy 12. O czym wy przez tą godzinę każdego dnia rozmawiacie?
    • cytrynowe 10.02.13, 19:11
      przecież napisał, że ma 40-osobowy zespół. Mają standup z 40-osobowym zespołem i PM-em. Zajebiście to scrumowe.
    • meth.p 09.02.13, 20:39
      Przeciez tak jak piszesz, Scrum wcale nie jest tam wprowadzony. To nie wprowadzenie Scruma przynosi wiecej szkod niz pozytku, ale wprowadzenie metodologii ktora w opinii kadry zarzadzajacej jest Scrumem, ale w rzeczywistosci nie ma z tym nic podobnego.

      'Programista' pisze, ze maja w pracy cos Scrumopodobnego. Otoz z tego, co pisze dalej wynika, ze to nie jest podobne do Scruma w nawet najmniejszym stopniu.

      Najwiekszy problemem z agilem jest taki, ze firmy mysla ze uda im sie agile wprowadzic, ale jednoczesnie robic wszystko po staremu. Tak sie nie da.

      A sam artykuł? "Czy wiesz, że programiści mają obowiązkowe dwutygodniowe sprinty (...)". Facepalm.
    • Gość: tk IP: *.dynamic.chello.pl 14.04.13, 00:19
      potwierdzam w 100%. Scrum: [1] nie jest lekarstwem na wszystko oraz [2] ma sens tylko wtedy kiedy organizacja jest zdrowa.
    • lelontm2 09.02.13, 14:48
      Dla kogo ten artykuł? Programiści to wiedzą, a reszcie do niczego nie jest to potrzebne. Poza tym SCRUM nie nadaje się do wszystkich rodzajów projektów. A inna sprawa, że jak autor chciał wywołać sensację, to mógł napisać coś o świniach i kurczakach.
    • mikoli1 09.02.13, 16:04
      Cały ten skram, adżajl i reszta tego barachła to jeden wielki bulszit nie przynoszący żadnych korzyści, a jedynie wku...ający ludzi i pochłaniający dodatkowy czas na administrację projektem, w tym analizę debilnych burnałtów i innych bzdetów.

      Nieważne, czy jest zrobione czy nie, ważne żeby "bernałt" dobrze wyglądał. I nie piszcie mi, że na złych skram masterów czy innych prodakt ałnerów trafiałem, bo takie coś widziałem już w kilku firmach. Wszędzie te same bzdury.
    • Gość: K. IP: *.warszawa.vectranet.pl 09.02.13, 16:16
      Widać wiele zależy od polityki firmy. Jeśli scrum jest wprowadzany z głową, a nie "teraz większość firm tak robi", to przynosi efekty. Pracuję w zespole scrumowym, pracowałam też przed wdrożeniem nowej metodyki i widzę różnicę.
    • przemyslaw.rozycki 09.02.13, 20:18
      Źle zaimplementowany scrum i do tego w projekcie, który się do tego nie nadaje to faktycznie bulszit. Być może nie miałeś okazji się przekonać, jak wygląda właściwy.
    • cytrynowe 10.02.13, 19:14
      mikoli1 napisał:

      > Cały ten skram, adżajl i reszta tego barachła to jeden wielki bulszit nie przyn
      > oszący żadnych korzyści, a jedynie wku...ający ludzi i pochłaniający dodatkowy
      > czas na administrację projektem, w tym analizę debilnych burnałtów i innych bzd
      > etów.

      A poruszyłeś to na retrospekcji sprintu? :)

      > Nieważne, czy jest zrobione czy nie, ważne żeby "bernałt" dobrze wyglądał.

      To mi nie brzmi scrumowo. Jak coś nie jest zrobione, to jakim cudem burndown wygląda dobrze?
    • Gość: cminusminus IP: *.neoplus.adsl.tpnet.pl 09.02.13, 17:47
      Cały ten SCRUM to pieprzenie od rzeczy i tyle. Stwarza złudzenie, że ma się nad czymś kontrolę.
      A prawda jest taka, że jak mam problem to idę bezpośrednio do osoby, która się tym zajmuje, i obgaduję to. Nie muszę czekać na następny scrum-meeting i tam uzewnętrzniać swoje żale.
      Na papierze (szczególnie dla kllienta który czasem bywa na takich spotkaniach) wygląda świetnie: lekka metodyka wytwarzania oprogramowania - brzmi dumnie. A dla mnie to tylko strata czasu.
    • Gość: Przemek IP: *.tktelekom.pl 09.02.13, 20:08
      Pokaż mi zapis w opisie Scruma, który mówi, że nie wolno ci się kontaktować z innym programistą poza scrum meetingiem!
      Myślę, że po prostu nie zrozumiałeś na czym ta metodyka polega i albo jej nie używałeś, albo używałeś jej w projekcie, do którego się nie nadaje. Ja zauważyłem wiele pozytywnych skutków w moich zespołach, nawet jeśli nie wdrażaliśmy pełnego scruma a tylko kilka jego praktyk.
    • Gość: rob IP: *.neoplus.adsl.tpnet.pl 09.02.13, 18:40
      Mam wrażenie, że wiele firm uwierzyło, że jeśli wprowadzą agile/scrum to projekty już same będą się robić i nie będzie żadnych opóźnień. Prawda jest taka, że jeśli wymagania są klarowne i terminy realistyczne, to zespół dowiezie rozwiązanie na czas. Natomiast jeśli w wymaganiach jest burdel, a estymacje zamiast specjalistów robił management, to żadna metodologia nie pomoże.
    • Gość: Przemek IP: *.tktelekom.pl 09.02.13, 20:13
      To nie do końca tak. Scrum i agile nadaje się właśnie najlepiej tam, gdzie w wymaganiach jest burdel. Ważne jest tylko to, by Klient i management sobie zdawał sprawę z tego jak jest i że pracujemy w agile'u ze wszystkimi tego konsekwencjami. W szczególności kontrakt z Klientem też powinien uwzględniać agile'ową specyfikę pracy. Można w sieci znaleźć wiele materiałów na temat tego jak skonstruować agiele'owy kontrakt z Klientem. Samo powiedzenie sobie, że pracujemy w agile'u nie wystarczy.
    • blasphemy 10.02.13, 20:06
      >to żadna metodologia nie pomoże.
      Nie używaj słów których nie rozumiesz. Poczytaj o różnicy między metodyką a metodologią i wtedy dopiero kontynuuj publiczne kompromitowanie się ignoranctwem.
    • Gość: KasigiYabu IP: *.rdnet.pl 09.02.13, 18:41
      U nas w firmie mamy konkurencyjną metodologię:
      programming-motherfucker.com/
    • Gość: komentator IP: 176.100.196.* 09.02.13, 19:04
      Lepiej napiszcie ile kasy dostają ludzie pracujący w taki sposób... Oby dużo, bo jak dla mnie istnieje kolosalna różnica między byciem szefem dla samego siebie a codziennym porannym "staniem w kole" i opowiadaniem o tym co zrobiłem poprzedniego dnia i co planuję zrobić dzisiaj. Mnie cała ta metoda trąci jakimś sekciarstwem, a na dłuższą metę może prowadzić do poważnego rozstroju zdrowia psychicznego...

    • Gość: Insider IP: *.adsl.inetia.pl 09.02.13, 19:36
      To co opisują w artykule to sztywne stosowanie metodyki.
      A z tym jak z edytorem tekstu - dobry edytor pomaga w pracy piszącego, ale nigdy, przenigdy nie uczyni z piszącego pisarza.
      Podobnie z tą metodyką - im bardziej będziecie jej pilnować, tym większy bullshit z tego będzie wychodził. Tak samo z ITILami, metodami ścieżek krytycznych, itp.

      W realiach wygląda to tak: albo ktoś sobie radzi z zarządzaniem zespołem (i ci nad nim również), albo każda metodyka guzik wniesie.

      A ci, którzy sobie radzą, mogą się kiedyś dowiedzieć, że postępują niczym rasowy scrum master, że ich podejście jest ITILowe, itd.
    • Gość: Tirinti IP: *.dynamic.chello.pl 09.02.13, 20:57
      Dokładnie.
      Niestety wielu szefów poczytało sobie blogi i myśli, że wystarczy zrobić daili scrumy i zaraz wydajnośc pracy wzrośnie conajmniej dwukrotnie.
      Pracuję już 2 trzeciej firmie szczycącej się scrumem ale w żadnej to nie wychodziło dobrze.
    • edeco 10.02.13, 09:39
      Z tego dziennikarskiego bełkotu nie za bardzo zrozumiałem.
      cyt. "Podczas spotkania wszyscy stoją w jednym kręgu i każdy po kolei odpowiada o tym, co zrobił od ostatniego spotkania, co planuje na dany dzień i czy widzi jakieś przeszkody, które mogłyby utrudnić mu pracę. "

      Wiem, że to dla dziennikarza zbyt trudne, a to co powyżej jest głupie, dlatego zapytam:
      Czy aby przypadkiem, ten co zwołuje spędy NIE POWINIEN rozdzielić pracy? Przecież nie przychodzi taki manager i nie mówi do grupy ludzi: Napiszcie mi program na komputra. I wszyscy się rozchodzą i kazdy pisze mu ten program na komputra.
    • Gość: . IP: *.warszawa.vectranet.pl 10.02.13, 10:00
      Artykuł jest napisany fatalnie, więc jeśli nie znasz scruma, to nic z niego pewnie nie zrozumiesz.
      en.wikipedia.org/wiki/Scrum_(development) - angielska wiki jest pod tym względem lepsza.
    • cytrynowe 10.02.13, 19:21
      edeco napisał:

      > Czy aby przypadkiem, ten co zwołuje spędy NIE POWINIEN rozdzielić pracy?

      W scrumie niemile widziane jest odgórne rozdzielanie pracy.

      > eż nie przychodzi taki manager i nie mówi do grupy ludzi: Napiszcie mi program
      > na komputra. I wszyscy się rozchodzą i kazdy pisze mu ten program na komputra.

      Mniej więcej tak to wygląda. Na początku sprintu Product Owner przychodzi do Zespołu i mówi: napiszcie mi program. Wtedy Zespół siada, rozpisuje sobie, co trzeba zrobić, żeby program powstał. Potem rozchodzą się do biurek i wspólnie piszą program.
    • Gość: Przemek IP: *.tktelekom.pl 09.02.13, 20:04
      Wcale nie korporacyjny. Wdrożenie scruma daje najlepsze efekty w małych firmach a nie korporacjach. Poza tym, biorąc pod uwagę moje własne doświadczenia, to praca w klasycznym waterfallu jest tym co odczłowiecza programistę w korporacji. Scrum właśnie daje to, czego w korporacjach często brakuje.
    • Gość: Macho IP: *.myslenice.net.pl 10.02.13, 16:23
      Pierniczycie Hipolicie.
      Waterfall oczywiście ma swoje szajby, ale jest ich zdecydowanie mniej niż w przypadku Scrum.
    • rmarcin555 10.02.13, 18:37
      Waterfall nie występuje w naturze.
    • Gość: Macho IP: *.myslenice.net.pl 10.02.13, 22:50
      Dom buduje się od fundamentów w górę, a nie od dachu w dół.
    • Gość: zet IP: 95.108.95.* 25.03.13, 21:45
      tylko jest mała różnica pomiędzy kosztem projektowania domu a jego budowy, w przypadku softu to jest to jedno i to samo.
    • Gość: Tirinti IP: *.dynamic.chello.pl 09.02.13, 20:54
      Sprinty są przeważnie dłuższe niż 2 tygodniowe, a scrum master to nie szef.
    • xolaptop 09.02.13, 22:02
      Doczytaj dziennikarzu o tej metodologii zarządzania projektami. Scrum Master nie jest w niej szefem. To nie jest kierownik projektu. Taka osoba definiuje zadania, prowadzi ich ewidencję, wyznacza priorytety zadań w oparciu o to, czego oczekuje klient albo kierownik projektu. Nie może nikomu w zespole nakazać wykonania któregoś z takich zadań. Ta osoba nie jest od wydawania poleceń.
    • Gość: W. IP: *.204.18.145.nat.umts.dynamic.t-mobile.pl 09.02.13, 22:43
      Dokładnie. Scrum Master NIE jest szefem i nie może wydawać poleceń. O tym mowa też w tekście.
    • Gość: asd IP: *.allegro.pl 09.02.13, 23:29
      I to nie scrum master decyduje o priorytetach zadań a product owner. i jeśli chodzi o sam artykuł, to wcale nie jest tak, że deweloperzy sa swoimi szefami. po prostu jest takie gadanie a i tak szef oczekuje efektów i z nich rozlicza. atmosfera pracy przez to na pewno się nie poprawia
    • Gość: K. IP: *.warszawa.vectranet.pl 10.02.13, 09:53
      Poprawia, bo nikt nie wskazuje Ci zadań do wykonania, jak czynią kierownicy.
    • Gość: zenek IP: 194.25.30.* 09.02.13, 23:11
      po pierwsze scrum to zadne codowne lekarstwo. ma wady i zalety jak wszystko inne...
      generalnie scrum wcale nie jest zwiazany w szczegolny sposob z informatyka czy programowaniem. to nawet nie jest metoda zarzadzania projektami, tylko metoda wytwarzania produktow. guru scruma twierdza, ze tym samym sposobem mozna zrobic dowolny produkt. zbudowac dom, albo wykonac deske klozetowa, albo napisac system komputerowy. coz, moze to i prawda, ale ja bym nie zlecil przeprowadzenia operacji serca zespolowi trzymajacemu sie kurczowo metodyki scruma. ortodoksyjni scrumowicze tworza cos na ksztalt sekty, poza scrumem ich zdaniem nie istnieje zadna sensowna metoda na napisanie kawalka softwaru, ale szczerze mowiac zalozenia scruma sa problematyczne. np. zalozenie, ze zadowolenie uzytkownika jest wazniejsze niz trzymanie sie projektu... problematyczne kiedy sie robi projekt na zasadzie umowy o dzielo. projekt wykonany, specyfikacje gotowe, wszystko oszacowane, kwota ustalona, umowa podpisana. i chlopaki zaczynaja stroic fochy, na bierzaco wprowadzaja zmiany i przeprojektowuja wszystko co sie da... jak sie po stronie sponsora i zespolu utworzy odpowiednia konstelacja to rozpierdziela kazdy projekt. zaden budzet tego nie wytrzyma... w koncu zamiast 10 zamowionych funckji beda zrealizowane 2. Zamawiajacy bedzie super zadowolony z tych 2 funkcji, ale produktu nie bedzie mogl uzywac, bo na 8 innych funkcji zabrako pieniedzy...
      albo druga sprawa... zespoly bez zadnej hierarchii... moze super funkcjonowac w zespole zlozonym z absolutnych nerdow motywujacych sie wzajemnie do pracy. na podobnej zasadzie pracuja te wszystkie grupy tworzace linuksa. ale w prawdziwym zyciu w kazdej firmie znajdze paru innych gosci. jeden len, jeden chorowity, kilku przecietnikow. scrum przez rezygnacje z hierarchii nie daje zadnych mozliwosci dyscyplinujacych czlonkow teamu. Kto i jak lenia ma zmotywowac co zawala terminy? W normalnym projekcie robi to szef projektu. Przeprowadza meska rozmowe i w przypadku recydywy wylewa delikwenta. W scrumie nie ma takiej roli. Scrummaster? To nie jego broszka. Czlonek teamu?- Len mu moze powiedziec, zeby sie walil. Sponsor? To tez nie jego sprawa. On kupuje produkt, rozwiazanie ma znalezc team. Jasne, ze goscia ktos tam w koncu wyleje, ale to juz nie bedzie scrum...
      Albo zasada, ze dzialajacy produkt jest wazniejszy niz jego dokumentacja...
      Niby zrozumiale, tylko jak sie robi projekt przez rok i dokumentacje zostawia zgodnie z ta zasada na koniec i cala ekipa scruma leci np. do smolenska i ginie tam razem ze scrummasterem... No to po prostu zalamka. Kasa wydana, zero dokumentacji, nie istnieje nikt, kogo mozna zapytac. Mozna projekt zaczynac od nowa...
      Jednym slowem scrum czasem dziala, czasem nie. trzeba brac z niego to co dobre i sprawdzic wczesniej czy sie nadaje do zastosowania w konkretnej prawno-personalno-zadaniowej sytuacji...
    • Gość: bronek IP: *.w80-14.abo.wanadoo.fr 09.02.13, 23:28
      +
    • Gość: inz_mech IP: 31.179.195.* 10.02.13, 00:05
      Bardzo prawdziwe.
      Zadna metodologia nie dziala gdy lider projektu nie powinien byc liderem. Albo ma sie dryg do zarzadzania albo nie.
    • Gość: W. IP: *.204.18.145.nat.umts.dynamic.t-mobile.pl 10.02.13, 00:07
      Scrum rzeczywiście nie jest dla wszystkich. Zwłaszcza w dużych korporacjach, gdzie wyższe kierownictwo i szefowie projektów nie mają pojęcia o programowaniu, ani nie rozumieją Scruma i jego korzyści. Ale za to mocno trzymają się stołków i potrafią dobrze dyscyplinować leni co zawalają terminy ;-)
    • Gość: Helka Bronek IP: 109.95.239.* 10.02.13, 10:07
      +1 do sekciarstwa wyznawców scruma. Też mam takich w firmie, którzy wysiłki na rzecz opanowania i uporządkowania wszechobecnego burdelu potrafią uwalić sakramentalnym "ale to przecież jest waterfall i niezgodne z duchem scruma", koniec dyskusji. Przed wprowadzeniem tej metodologii w firmie należy chyba dokonać gruntownego przeglądu mentalności pracowników, którzy będą używać tego na co dzień. Typowy produkt polskich feudalnych uniwersytetów wytresowany do bezkrytycznej akceptacji wszelkich autorytetów i dla którego rozwiązaniem każdego problemu jest znalezienie odpowiedniego cytatu swojego mistrza (zamiast analizy stanu faktycznego i wyciągnięcia prostych i oczywistych wniosków) może doprowadzić scruma do stanu własnej parodii a firmę na krawędź upadku.
    • Gość: W. IP: *.180.22.231.nat.umts.dynamic.t-mobile.pl 10.02.13, 15:45
      Rzeczywiście jeśli ludzie tylko wykuwają na blachę regułki i ślepo w nie wierzą, bo ten czy inny guru tak powiedział, to najczęściej nie rozumieją istoty dlaczego postępować w określony sposób. Ale to jeszcze nie oznacza, że sama metodyka jest zła, problem często leży w niezrozumieniu jak działa. Czy to efekt studiów i szkolnictwa? Na pewno coś w tym jest z 4Z: zakuj, zalicz, zapij, zapomnij, ale czasem przez przypadek nie zrozum...

      Wyobraź sobie, że mamy wszechogarniający wszystko burdel. Jest wszędzie. Wszystko na co nie spojrzysz, to burdel. To się zdarza, na przykład jeśli wcześniej pędziliśmy z dostarczaniem rzeczy na czas i nie dbaliśmy, o to żeby jednocześnie utrzymywać wszystko w ładzie i porządku. No bo nie było kiedy, wszystko było do zrobienia na wczoraj. No i ten burdel składa się teraz z większych i mniejszych burdelków, burdelików, burdeleczków, burdeleńków. Wszystko ze sobą powiązane i poplątane, no ogólnie jeden wielki burdel, że aż miło. Nikt nie wie co się dzieje. Ale wreszcie zdarza się cud. Nagle ktoś oświecony wpada na niesamowity pomysł. Pomysł pochodzi wręcz nie z tego świata. Posprzątajmy! Teraz zupełnie nie da się z tym żyć, jak posprzątamy wszystko, to dopiero będzie fajnie! Miło i przyjemnie! Pomysł jest na tyle genialny, że inni go bez wahania kupują! Woww, tylko prawdziwy geniusz mógł na to wpaść! Więc teraz mówimy: szanowny kliencie, przykro nam, mamy taki burdel, że przez najbliższe pół roku będziemy mieli Cię gdzieś, musimy najpierw posprzątać, dopiero później się tobą zajmiemy. Ale na razie poczekaj... Nic w najbliższym czasie od nas nie dostaniesz... Przez pół roku czekaj, a może rok, a może dwa, a może i więcej... Poczekaj, ale za wszystko oczywiście będziesz musiał nam zapłacić... Ups...

      Scrum i metodyki zwinne mówią jedynie, że nie możemy zabrać się za wszystko na raz. Na pewno jednak możemy ustalić z klientem co jest dla niego najważniejsze i wybrać te rzeczy od których zaczynamy. Bo przyniosą największe korzyści. Jest w tych rzeczach burdel? Owszem i to jaki! Ale porządkujemy go przy okazji. Tą jedną najważniejszą rzecz w danej chwili. Krok po kroczku, jeden burdelik mniej, później kolejny i kolejny. Z burdelwszechświata zacznie powoli wyłaniać się porządek. A jednocześnie klient będzie otrzymać to czego najbardziej potrzebuje. A może okaże się, że jednak nie wszystko trzeba porządkować? Po co więc się męczyć? To przecież kosztuje.

      Podsumowując, żeby odnieść świetne efekty ze Scruma, wszyscy muszą najpierw dobrze rozumieć dlaczego działa tak, a nie inaczej, a nie przyjmować jego zasady z góry jako dogmat. Dlatego najczęściej w korporacjach powstają twory Scrumopodobne, a porażki nie przynoszą chwały metodyce. Nikt nie mówił, że będzie łatwo.
    • Gość: ixi IP: 62.61.41.* 09.02.13, 23:30
      i jedyne co sie sprawdza to pisanie testow i dzielenie problemu na jak najmniejsze moduly. Programowanie jest dosc nieprzewidywalne (nie chodzi mi o jakies trywialne wyklikanie formularza) wiec trzeba unikac tworzenia monolitow, ktore maja tendencje do zycia wlasnym zyciem. A scrumy, itp sluza wg mnie tylko do zapewnienia dobrego samopoczucia wladzy, ze ma wplyw na cokolwiek. A tak naprawde caly misterny plan bierze w leb przy byle awarii, lub jakiejs naglej pilnej robotce prosto od prezesa.
    • Gość: Macho IP: *.myslenice.net.pl 10.02.13, 16:27
      I ten pan dobrze gada.
      W końcu programowanie to opis działania które można wykonać z ręki, ale sprzęt zrobi to szybciej i powtarzalnie. Nie ma nic złego w tym, że problem zostanie rozproszkowany do takiego poziomu przy którym nie ma już wątpliwości co i jak ma działać.
    • Gość: tk IP: *.dynamic.chello.pl 14.04.13, 00:26
      > A tak naprawde caly misterny plan bierze w leb przy byle awarii

      +10

      > lub jakiejs naglej pilnej robotce prosto od prezesa.

      + 100
    • sselrats 09.02.13, 23:35
      programatorow.
    • Gość: Przemek IP: *.tktelekom.pl 10.02.13, 10:52
      To nie jest prawda, jak niektórzy sugerują, ze scrum nic nie wnosi dobrego. Problem ze scrumem jest taki, że większość klientów chce mieć agile'owe podejście do wymagań i fixed price'owe podejście do budżetu. Wyobrażają sobie, że jak dostawca pracuje w agile'u to za cenę wyszacowaną na początku projektu będą mogli do woli dokładać funkcjonalności i dokonywać korekt w już raz sprecyzowanych wymaganiach. Niestety, albo rybki, albo akwarium. Jak robimy agile, to ze wszystkimi tego konsekwencjami bo czas pracy programisty kosztuje.
    • rmarcin555 10.02.13, 18:56
      Nic dodać, nic ująć.
    • Gość: robert IP: 94.75.114.* 10.02.13, 15:21
      Scrum to nie metodyka, to framework, dobre rady, podpowiedzi jak zwał tak zwał. Odsyłam do scrum.org
    • Gość: dżonu tj. janek IP: *.ssp.dialog.net.pl 10.02.13, 16:01
      a potem podcierają swoję assy tojlet pejperem

      czy my jeszcze jesteśmy w Polsce? czy my możemy jeszcze używać języka polskiego?

      nasi dziadkowie krew przelewali za możliwość porozumiewania się w ojczystym języku, a teraz lemingi tylko szopinguję, żrą dinery, brancze, itd.
    • rmarcin555 10.02.13, 18:55
      Ale musi być wprowadzony z głową.
      Firma musi mieć albo odpowiednią strukturę organizacyjna, albo przynajmniejrozgarnięty management bo scrum wymaga trochę swobody.
      Innym nieszczęściem jest wprowadzanie scruma od A do Z bez uwzględniania specyfiki projektu i firmy. To faktycznie może zepsuć wszystko.
      Scrum wymaga też zaangażowania ze strony całego zespołu. Niestety wielu ludzi, którzy pracowali w waterfallu wcześniej przez lata uważa, że w ich pracy wszystko jest doskonałe. Ciężko się z takimi ludźmi na początku rozmawia, ale jeśli są inteligentni to szybko zaczynają dostrzegać zalety. Gorzej jeśli nie są.
      Scrum jest też bezlitosny dla obiboków. Co innego ściemniać szefowi, że zmiana tego napisu w okienku to przynajmniej 3 miesiące + testy, a co innego ściemnianie na standupie kumplom dlaczego historyjka nie skończona. Ściemniacze najgłośniej protestują przeciwko wprowadzaniu scruma.
      Scrum fajnie też integruje zespoły.
      Ale jak mówię wymaga otwartej głowy.

      Pracowałem w scrumie (jako programista i scrum master) przez 2.5 roku. Projekt miał jakieś 200 osób i 4 strefy czasowe. Scrum dał radę i było naprawdę fajnie. Ludzie naprawdę angażowali się w to co robili.
      Po zmianie pracy trafiłem niestety do Ciemnego Waterfallowa i to dopiero jest kanał:/

      pozdrawiam
    • Gość: aaa IP: *.play-internet.pl 10.02.13, 21:57
      Problem w tym, że ta integracja czasem nie działa... gorzej jak zespół, który ma robić w scurmie jest 4 kontynentach (różnice w czasie i rozjechane standupy, albo odbywające się bez części członków) i jeden ma potężną przewagę liczebną (7+1+1+1), takie zarządzania nie przewiduje żadna metodyka... żeby skoordynować tak porozrzucany projekt to trzeba mieć jajka (nawet będąc kobietą), a nie pitolić jedynie o zaletach naszej metody nad pozostałymi.

      Podałeś skrajny przykład, ja mogę podać inny. Moduły projektu mają kod typu spaghetti, który jest tylko dopisywany (bo płacone jest za nowe funkcje), a nigdy porządkowany (za jakość, dokumentację i refaktoryzację nikt przecież nie płaci!). Przychodzi opis błędu od klienta i ktoś musi usiąść do takiego modułu, prześledzić go od A do Z (wspólna odpowiedzialność to jedno, ale bieżąca analiza zmian w sporym projekcie to co innego, przy dużych zmianach czasem trzeba się uczyć spaghetti od nowa), a wyjadacze i znawcy tematu, zrzucają zadanie na innego członka zespołu i alokują czas nierealny na samą analizę modułu, a co dopiero zaklepanie modyfikacji. Nie może się zdarzyć? Zdarza się, bo przecież tylko obiboki ściemniają czas zawyżając go na zadania. Jak SCRUM to rozwiąże? Jak SCRUM sobie poradzi z osobami, które dopiero co dołączyły do projektu?
    • Gość: Macho IP: *.myslenice.net.pl 10.02.13, 22:47
      Scrum jest metodą autoterroru grupowego i to jest jedyny powód dla którego jest stosowany. Najważniejsza jest ideologia, wyniki działania jest gdzieś na dalekim miejscu.
    • Gość: filet IP: *.dynamic.chello.pl 10.02.13, 18:59
      jak zwykle "dziennikarz" wniknął głęboko w temat i bezstronnie go opisał :(
      "Każdy kolejny sprint jest ulepszony o doświadczenia z poprzednich sprintów, dzięki czemu jest on zawsze lepszy od poprzedniego." ZAWSZE! super. małe rozumki -- wielkie kwantyfikatory.
    • psu.brat 10.02.13, 23:12
      1. zadania i moduły stają się "własnością zespołu" - indywidualni ludzie są odsuwani od swojego "dzieła", co emocjonalnie ich demotywuje.
      2. zadania przechodzą z rąk do rąk - jeden już się nauczył a teraz przychodzi drugi i "kontynuuje" pracę nad kolejnym elementem większej układanki. Trzeba mu "pomagać" bo sam bez nabycia odpowiedniej wiedzy zrobi błędy. A na to nie ma czasu.
      3. sztuczne tworzenie "etapów", które tak naprawdę nie dadzą sensownej funkcjonalności osiąganej w każdym kroku, bo potem i tak trzeba przerobić tak, żeby całość miała sens.
      4. za bardzo się polega na "procesie" a za mało zauważa ludzi, którzy są kluczowi dla tempa prac.

      A to, że jednak działa, to kwestia stosowanej dyscypliny. Tyle, że jakby żelazną dyscyplinę stosować w innych podejściach, to również by działały.
    • Gość: xx IP: *.adsl.inetia.pl 11.02.13, 09:28
      Bardzo fajne wypowiedzi, które są raczej projekcjami świadomości na problem niż odniesieniem do tej czy innej metodyki.

      Ja jestem w branży od 12 lat i przez cały ten czas pracowałem raczej jako dev/team leader niż standardowy poganiacz bydła...

      Powiem jedno, z mojej perspektywy nie istnieje coś takiego jak jakość. Jest tylko i wyłącznie satysfakcja klienta. Metodyka ta czy inna w oderwaniu od konkretnego zastosowania nie służy kompletnie do niczego. Dlatego rozpatrywanie scruuma w oderwaniu od konkretnej jego implementacji w konkretnym projekcie nie ma żadnego sensu.

      Z doświadczenia nauczyłem się, że wszystko się sprowadza do możliwości spełnienia wymagań klienta. Być może działam na specyficznym rynku, bo zajmuję się w 95% projektami dedykowanymi, realizującymi specyficzne wymagania konkretnego klienta. Projekty są z przytłaczającej większości unikalne. W takiej sytuacji sprawa zamyka się w stwierdzeniu, że jeśli ja jestem w stanie spełnić wymagania za 10kPLN a ktoś inny za 8kPLN to naprawdę nie ma żadnego znaczenia czy używa od Scruuma czy tabliczek glinianych i pisma klinowego.

      Do jakości czegokolwiek to ma się tak, że nie zdarzyło mi się, aby klient był w stanie rzetelnie ją ocenić. Zawsze aplikację ocenia się obserwacyjnie, często post factum (czyli np. pół roku po zapłaceniu faktury). Dlatego faktyczna jakość kodu to tylko i wyłącznie decyzja projektowa. W istocie jakiekolwiek zarządzanie jakością ma znaczenie tylko i wyłącznie w przypadku, gdy w perspektywie czasu zakładamy konieczność rozwijania projektu przy jednoczesnej konieczności konkurencyjności cenowej.

      O co dokładniej chodzi. Z grubsza chodzi o to, że jak wchodzę do klienta z rozwiązaniem i technologią, to realnie on jest w takim stopniu tym związany, że wejście podmiotu trzeciego jest mało realne, więc funkcjonalność powinna być tworzona jak najtaniej, bo w przyszłości klient zapłaci za kolejne funkcjonalności tak czy siak... W przypadku gdy nie zakładam rozwoju aplikacji, to cudowanie z jakością zupełnie nie ma sensu...

      Reasumując, scruum - ok, może być. Waterfall - spoko, nie ma problemu. Ale co, kiedy i jak użyć to już zupełnie inna bajka.
    • Gość: michał IP: *.pwn.com.pl 04.08.14, 16:15
      Polecam scrumowcom książkę Krystiana Kaczora "Scrum i nie tylko" teoria i praktyka w metodach Agile, można ładnie uzupełnić wiedzę, pozdrawiam

    Popularne wątki

    Nie pamiętasz hasła

    lub ?

     

    Nie masz jeszcze konta? Zarejestruj się

    Nakarm Pajacyka