Nowe, nieznane wymaganie podczas planowania sprintu

Scrum umożliwia Product Ownerowi dokonywanie zmian w backlogu produktu w każdym momencie, gdy uzna, że kolejność elementów backlogu jest niewłaściwa, albo gdy trzeba usunąć jakieś wymaganie lub dodać nowe. Brak ograniczeń oznacza, że takich zmian Product Owner dokonać może tuż przed planowaniem sprintu, albo choćby podczas planowania. Z drugiej strony zespół developerski ma ostatnie słowo…

Definicja gotowości czy stan gotowości?

Od czasu do czasu w dyskusjach o Scrumie i związanych z nim praktykach przewija się temat Definition of Ready (definicji gotowości). Niektórzy niesłusznie uważają, że jest ona częścią definicji metody, inni są przekonani, że choć nie jest elementem Scruma, ułatwia pielęgnację backlogu produktu i ma pozytywny wpływ na kondycję tego scrumowego artefaktu. Tymczasem, jak każda…

Ofiary źle robionego Agile

W artykułach i dyskusjach często podkreślam jak ważne jest, by rozumieć i poprawnie stosować metody, z których zdecydowaliśmy się korzystać. Bo jeśli decydujemy się na takiego Scruma lub TDD, dobrze byłoby, aby wybór ten był świadomy. Nie ma bowiem sensu robić czegoś tylko dlatego, że robią to inni. Uprawianie takiego kultu cargo rzadko kiedy ma…

Czy w Agile faza UAT ma sens?

Kiedyś wytwarzanie oprogramowania zaczynało się od zebrania „wszystkich wymagań” i ich dokładnej analizy. W oparciu o to powstawała specyfikacja produktu, który należy zbudować. W przekonaniu wielu zawierała ona odpowiedź na każde pytanie, jakie wytwórcy produktu będą w przyszłości zadawać. Następnie biznes krwią podpisywał się pod tymi dokumentami, gwarantując, że zdania nie zmieni (prawda, że nie…

13 powodów nieudanej automatyzacji testów, część 3

Dwa wcześniejsze artykuły (część pierwsza i część druga) opisywały rafy, na jakie można natrafić, rozpoczynając automatyzację testów, oraz co można zrobić, by tak się nie stało. Na koniec przyjrzyjmy się na ile organizacja, w której działa zespół zajmujący się rozwojem produktu, może wpłynąć (pozytywnie lub negatywnie) na możliwości automatyzacji testów. 11. Nie mamy czasu na…

13 powodów nieudanej automatyzacji testów, część 2

W poprzedniej części wymienione zostały różne powody, dla których zespoły developerskie nie zajmują się automatyzacją testów i nie biorą za to odpowiedzialności jako team. A przecież takie rozwiązanie jest jedynym sensownym: ludzie, którzy budują produkt, powinni zapewnić, że on działa, czyli przetestować go. Niestety z faktu, że developerzy będą tego świadomi wcale nie wynika, że…

13 powodów nieudanej automatyzacji testów, część 1

Presja na częste wydawanie nowych wersji produktów powoduje, że wykładniczo rośnie ilość testów niezbędnych do stwierdzenia czy zmiany w najnowszym wydaniu nie psują wcześniej wytworzonych funkcjonalności. Testowanie nie oznacza bowiem jedynie sprawdzenia, że nowe rzeczy działają jak powinny, ale też zweryfikowania, czy produkt jako całość wciąż nadaje się do użytku. W miarę rozwoju produktu przybywa…

Centrum sterowania wszechświatem

Wytwarzanie oprogramowania jest nieustannym zmaganiem się ze złożonością: zmienia się technologia, potykamy się o dług techniczny pozostawiony we wcześniej wytworzonym kodzie, ludzie mają gorszy lub lepszy dzień, różne umiejętności, zdarza im się niespodziewanie odejść z pracy. O ile z tym można sobie jeszcze jakoś radzić, o tyle nie sposób uniknąć ani przewidzieć ciągłej ewolucji potrzeb,…

Dlaczego Scrum Master nie może być Product Ownerem?

Na każdym szkoleniu dotyczącym Scruma pojawia się niezmiennie pytanie o to, które role można łączyć. Oczywiście bycie tylko Developerm, Product Ownerem lub Scrum Masterem jest rozwiązaniem optymalnym, ale często w organizacjach łączenie ról jest nieuniknione. Takim typowym połączeniem jest Developero-Scrum Master, dużo rzadziej zdarza się Developero-Product Owner. Na szczęście do wyjątków należą osoby, które próbują…

Przepis na retrospektywę sprintu

Na początku tego roku Scrum Masterka w jednym z zespołów, z którym rozpoczynałem współpracę jako Agile Coach, opowiedziała mi o problemie z organizowaniem retrospektyw na koniec sprintu. Bo jest to zgrany team, ludzie pracują ze sobą już od dawna, znają swoje możliwości i przywary – nie wydaje się, by retrospektywa miała ujawnić cokolwiek, o czym…