Dzięki za zainteresowanie artykułem. Chodziło mi o to że SCRUM narzuca pewien porządek podczas tworzenia oprogramowania. Nie ma w nim miejsca na jakieś samowolki, a nawet jeśli coś takiego się wydarzy to na najbliższym Daily jest szansa to wychwycić i poprawić. Jeśli na Daily to nie wyjdzie to na zakończenie spintu już na pewno. A jak nikt tego nie kontroluje zespół nie współpracuje między sobą nie robią spotkań nie ma osoby odpowiedzialnej tylko kierownik który sprawdza ilość zamkniętych zadań to wtedy wychodzą właśnie takie sytuacje. Ja opisuje swoje doświadczenia. Często rozmawiam ze znajomymi programistami i słyszy się że jakaś firma dała ciała bo mimo dobrego zespołu nikt nie był w stanie tego dobrze zorganizować. Oczywiście nie musi tak być i znam firmy które dobrze działają w tak zwanych płaskich strukturach o których wspomniałeś.
Jeśli na Daily to nie wyjdzie to na zakończenie spintu już na pewno.
Powiedzmy sobie szczerze najbardziej kosztowne są błędy architektoniczne i źle dobrana technologia. W jaki sposób Daily i koniec Sprintu moją to wykryć skoro to wychodzi najczęściej gdy appkę trzeba skalować albo gdy istnieje potrzeba przebudowania/dodania modułu po jakimś czasie działania aplikacji - gdy już jest za późno czyli.
Jak ktoś coś zrobił wybitnie nie tak to to wyjdzie od razu na code review albo przy testach. Tutaj też daily czy zakończenie sprintu nic tak naprawdę nie daje. Przecież code review to nie jest tylko sprawdzenie kodu, przynajmniej nie powinno a można powiedzieć, że rozwiązanie drugi raz zadania.
Daily są krótkie mówiłeś to co robisz a i tak jak masz większy problem to musisz podejść do kolegi i on ci musi poświęcić czas na wytłumaczenie tak jak przy płaskiej strukturze.
Moim zdaniem to wszystko zależy od kompetencji zespołu, mówisz że nie ma miejsca na samowolkę w SCRUMie - to potrafi być dużą wadą. Przykładowo jako programista widzisz, że to co ci dał architekt do zrobienia jest bez sensu i trzeba to zrobić całkiem inaczej - typ ewidentnie nie wie co robi i teraz tak - Musisz iść do niego i się z nim kłócić albo musisz iść do scrum mastera i się poskarżyć. Scrum Master musi to przeanalizować - nie wiadomo czy będzie miał sam pojęcie - tak czy inaczej powiedzmy scrum master stwierdza, że masz rację więc musi iść do analityka i musi iść do product ownera, trzeba napisać nową historyjkę i tak dalej. Teraz jakby to wyglądało w płaskiej strukturze? Programista dyskutuje z innymi programistami, którzy pełnią również rolę architektów. Później mówią szefowi, że to będzie działało tak jak on chce ale z zmianami A i B bo ciężko by było je zaimplementować przy obecnej architekturze, szef mówi ok i wszystko jest zrobione.
W małych firmach często skąpią na dobrych programistów i dlatego te projekty są często fatalnie napisane. Wiadomo na SCRUMa sobie nie pozwolą bo za drogi, ale jestem ciekawy jakby wyglądała sytuacja gdy masz zawodników klasy A, którzy pracują w płaskiej strukturze i którzy pracują w SCRUMie - czy różnice byłyby znaczące a jeśli tak to czy na korzyść SCRUMa
Dzięki za zainteresowanie artykułem. Chodziło mi o to że SCRUM narzuca pewien porządek podczas tworzenia oprogramowania. Nie ma w nim miejsca na jakieś samowolki, a nawet jeśli coś takiego się wydarzy to na najbliższym Daily jest szansa to wychwycić i poprawić. Jeśli na Daily to nie wyjdzie to na zakończenie spintu już na pewno. A jak nikt tego nie kontroluje zespół nie współpracuje między sobą nie robią spotkań nie ma osoby odpowiedzialnej tylko kierownik który sprawdza ilość zamkniętych zadań to wtedy wychodzą właśnie takie sytuacje. Ja opisuje swoje doświadczenia. Często rozmawiam ze znajomymi programistami i słyszy się że jakaś firma dała ciała bo mimo dobrego zespołu nikt nie był w stanie tego dobrze zorganizować. Oczywiście nie musi tak być i znam firmy które dobrze działają w tak zwanych płaskich strukturach o których wspomniałeś.
Powiedzmy sobie szczerze najbardziej kosztowne są błędy architektoniczne i źle dobrana technologia. W jaki sposób Daily i koniec Sprintu moją to wykryć skoro to wychodzi najczęściej gdy appkę trzeba skalować albo gdy istnieje potrzeba przebudowania/dodania modułu po jakimś czasie działania aplikacji - gdy już jest za późno czyli.
Jak ktoś coś zrobił wybitnie nie tak to to wyjdzie od razu na code review albo przy testach. Tutaj też daily czy zakończenie sprintu nic tak naprawdę nie daje. Przecież code review to nie jest tylko sprawdzenie kodu, przynajmniej nie powinno a można powiedzieć, że rozwiązanie drugi raz zadania.
Daily są krótkie mówiłeś to co robisz a i tak jak masz większy problem to musisz podejść do kolegi i on ci musi poświęcić czas na wytłumaczenie tak jak przy płaskiej strukturze.
Moim zdaniem to wszystko zależy od kompetencji zespołu, mówisz że nie ma miejsca na samowolkę w SCRUMie - to potrafi być dużą wadą. Przykładowo jako programista widzisz, że to co ci dał architekt do zrobienia jest bez sensu i trzeba to zrobić całkiem inaczej - typ ewidentnie nie wie co robi i teraz tak - Musisz iść do niego i się z nim kłócić albo musisz iść do scrum mastera i się poskarżyć. Scrum Master musi to przeanalizować - nie wiadomo czy będzie miał sam pojęcie - tak czy inaczej powiedzmy scrum master stwierdza, że masz rację więc musi iść do analityka i musi iść do product ownera, trzeba napisać nową historyjkę i tak dalej. Teraz jakby to wyglądało w płaskiej strukturze? Programista dyskutuje z innymi programistami, którzy pełnią również rolę architektów. Później mówią szefowi, że to będzie działało tak jak on chce ale z zmianami A i B bo ciężko by było je zaimplementować przy obecnej architekturze, szef mówi ok i wszystko jest zrobione.
W małych firmach często skąpią na dobrych programistów i dlatego te projekty są często fatalnie napisane. Wiadomo na SCRUMa sobie nie pozwolą bo za drogi, ale jestem ciekawy jakby wyglądała sytuacja gdy masz zawodników klasy A, którzy pracują w płaskiej strukturze i którzy pracują w SCRUMie - czy różnice byłyby znaczące a jeśli tak to czy na korzyść SCRUMa