„Nie mój problem!” brzmi jak wymówka albo próba uniknięcia odpowiedzialności. Takie są pierwsze myśli, jakie większości osobom przychodzą do głowy. A co, jeśli to faktycznie prawda i próbujemy obarczyć kogoś czymś, na czym tej osobie w ogóle nie zależy?
#białko agile blog
Oto wszystkie teksty na naszym zwinnym blogu:
To, że Scrum można stosować nie tylko w IT wie już chyba każdy. A czy uwierzycie, że ten framework może być skutecznie używany przez przestępców? Przecież kto jak nie oni mają na co dzień do czynienia z nieprzewidywalnością i ryzykiem? Nierzadko mierzą się też z problemami, które wymagają kreatywnego rozwiązania.
Zwinne podejście przewiduje ciągle ulepszanie sposobu pracy – w nieskończoność. Czy jest to możliwe, żebyśmy kiedykolwiek trafili do punktu, gdzie już nie ma co ulepszać? Zdarzało mi się spotykać zespoły, które tak właśnie twierdzą. W dzisiejszym poście je opiszę – i opowiem, jak z nimi pracować.
Review, ze względu m. in. na prostotę powinno być dobrze rozumianym i przeprowadzonym wydarzeniem. Często tak jest, ale nasza praktyka pokazuje jednak, że jak każde inne scrumowe wydarzenie, Review może być problematyczne. Dlaczego tak jest? Dlaczego Sprint Review jest takie trudne?
Wygląda na to że im wyższa temperatura, tym poważniejsze przemyślenia. Podobnie jak to miało miejsce w ostatnich kilku tekstach i filmach, dzisiejsze pytanie „Komu robimy dobrze?” jest co najmniej dwupoziomowe.
Im bardziej ostatnio zastanawiam się nad tym, czym się zajmujemy, tym bardziej dochodzę do wniosku, że nie powinniśmy bawić się „w zwinność”, tylko nazywać to po prostu optymalizacją procesów. I wcale nie powinno być to trudniej sprzedawać niż „agile”.
Miałem na dzisiejszy wpis dwa dobre pomysły. Nie mogąc się zdecydować rzuciłem monetą i wgrał ten opisujący „typy” Product Ownerów. Dlaczego napisałem o typach? Sprawa z punktu widzenia frameworku Scrum jest prosta, sprawa z punktu widzenia praktyki nieco się komplikuje. Można powiedzieć, że komplikujemy ją sobie sami.
Często ludzie pytają nas, czy praca Product Ownera to praca na 100%? Przecież PO odpowiedzialny jest „tylko” za Backlog, jak może to zajmować więcej niż jedną godzinę dziennie? Wy pytacie, ja mówię – sprawdzam!
Gdybyśmy mieli zdefiniować składniki niezbędne do tego, aby nasze scrumowe przedsięwzięcie się powiodło, byłby to zupełnie inny zestaw niż ten opisywany w Scrum Guide. Ale czy na pewno?
Wymaganie niefunkcjonalne należą do moich ulubionych typów wymagań. Mówię to oczywiście z delikatnym przymrużeniem oka. Wiadomo, że wszyscy skupiamy się na dostarczeniu tej „klikalnej” i użytecznej części rozwiązania. Kiedyś jednak musi nadejść chwila realizacji zadań „mniej biznesowych”, a czasem wręcz mocno technicznych. Kiedy jest ten czas? Jak źle zarządzać wymaganiami niefunkcjonalnymi?
Strona [tcb_pagination_current_page] z [tcb_pagination_total_pages]