Archiwum

Maintenance w agile [agilestarter]

Kiedy rozwijamy produkt stosując agile, developerzy (programiści, testerzy, UXy) dzielą sią na zespoły. Zespoły te mają wiedzę, jak budować oczekiwane funkcjonalności i jak je dostarczać do końcowych użytkowników. Aby nowo powstałe zespoły były prawdziwie zwinne, nie powinny one czekać z dostarczaniem wymagań (poszczególnych funkcjonalności), aż cały nowy / udoskonalony produkt powstanie. Aby zrealizować to założenie, musimy być świadomi, że oddawanie po “kawałku” nowych funkcjonalności będzie powodowało “spływanie” do zespołu zgłoszeń już od momentu pierwszego wdrożenia. Użytkownicy zaczną używać produktu, a żaden produkt nie jest na początku doskonały. Powstaną zgłoszenia, czyli tzw. maintenance (utrzymanie).

(więcej…)

 

Dług techniczny [agilestarter]

Jako zespół developerski powinniście dostarczyć nowe funkcjonalności do Waszego systemu (aka produktu). Widzicie dwie drogi. Pierwsza jest szybka, ale jako zespół jesteście pewni, że podążając nią, w przyszłości będziecie pracować wolniej i wolniej. Druga droga jest trudniejsza, zajmie Wam więcej czasu, ale zrobiony kod będzie wolny od długu technicznego.

(więcej…)

 

Leasons learned książki „Jak być dobrym Product Ownerem”

Pod koniec zeszłego roku wydaliśmy (zrobiliśmy i opublikowaliśmy) książkę „Jak być dobrym Product Ownerem”. Było to prawie trzy miesiące temu, więc postanowiliśmy zebrać listę błędów/niedoskonałości/spostrzeżeń, które nam się nasunęły w związku z tą akcją. Zrobiliśmy książkę po raz pierwszy, więc tym bardziej nasze spostrzeżenia mogą być trafne (albo właśnie nie :D).
Chcemy się tą listą z Wami podzielić.

(więcej…)

 
Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x