K85.pl - Agile i takie tam sprawyPoniżej znajdziesz wszelkie posty oznaczone tagiem “backlog”. Miłej lektury!
Określenie “płacz i zgrzytanie zębów” to zgodnie z Wikisłownikiem fraza rzeczownikowa, rodzaj męskorzeczowy, a znaczenie jej jest następujące:
(1.1) bardzo trudna sytuacja, kłopot, zmartwienie
(1.2) ewangeliczne określenie mąk piekielnych[1] (etymologia: z Biblii: Ewangelia wg św. Mateusza 13, 41-50 i Mt 22, 13)
Chętnie dodałbym jeszcze jedno znaczenie “skutek słabego Refinementu” 🙂
W poprzednim tekście poruszyłem wątek najpopularniejszego formatu opisywania pomysłów, a mianowicie User Stories (historyjki użytkownika). Teraz czas na alternatywy.
Nasze backlogi wyglądają przeróżnie. Przykładowo czasem „taski” mają tylko tytuły i zero opisu – tłumaczymy, że ma być „lekko i zwinne”, a tak naprawdę nie chce nam się trochę i nie znamy metody jak pisać lepiej.
Bardzo długo szukałem cyfrowego Świętego Graala 😉 Potrzebowałem aplikacji do zapisywania notatek i zadań. Każda miała jakieś wady i ją porzucałem na rzecz kolejnej, która ich nie miała, ale… jak się okazywało miała wady inne. Od około roku już nie zmieniam, bo znalazłem tego Graala – przedstawiam Państwu Notion.
Bugi to naturalna sprawa. Niestety, nie da się ich całkowicie uniknąć. Czasami możemy mieć proces pierwszej klasy i produkować ich ledwie ociupinkę, ale najczęściej jednak produkujemy ich trochę więcej 😎 Każdy zespół ma swoje podejście do tego jak radzić sobie z błędami, gdy zostaną odkryte. Najczęściej nie ekscytują one programistów. Product Ownera czy Project Managera też nie. Raczej lądują w grupie “katorga”. Dużo rzadziej ktoś powie “ale wspaniały błąd, chcę to naprawiać” 🤪 Od tego już mały krok, aby zacząć je skrupulatnie kolekcjonować w backlogu i… zaczyna nam rosnąć niezły bałagan 😮
Bugi (błędy, defekty), to nieodłączna część naszej rzeczywistości. Niestety, raczej ta nieprzyjemna. Większość z nas woli skupić się na dostarczaniu nowej wartości dla klienta – to jest w końcu to co pcha nasze produkty do przodu. W celu oswojenia tej nieprzyjemnej części, nierzadko próbujemy szacować rozmiar błędów. Nie szacujmy bugów 😎 Na ogół nie ma to sensu i będzie to zwykłym marnotrawstwem. Dlaczego?