Dzisiaj zaglądamy pod maskę Jiry i zastanawiamy się czy wybrać workflow, czy subtask. Przy okazji porozmawiamy sobie o tym, w jaki sposób ułożyć sobie nasz proces zarządzania zadaniami i jakie są dobre praktyki. Gotowi?
#białko agile blog
Oto wszystkie teksty na naszym zwinnym blogu:
Spotkałem się ostatnio z ciekawą tezą, która głosi, że zespół musi dojrzeć do Scrum, żeby umieć w pełni go wykorzystać. Czy taki „zespół długodojrzewający” to kierunek w którym powinniśmy podążać? Czy faktycznie musimy mieć czas, aby się rozpędzić?
Chyba nikt w naszym kręgu kulturowym nie powinien mieć wątpliwości, co do tego, że centralne sterowanie nie działa. Z drugiej zaś strony, mało kto słyszał o genchi genbutsu. Co to za zwierz i jak się on ma do naszego zwinnego światka?
Teoretycznie proste rzeczy mają tendencję do bycia trudnymi w praktyce. Historyjki Użytkownika, a bardziej ogólnie – wymagania w podejściu zwinnym – są na tyle ogólne, że bardzo łatwo zacząć robić nieme założenia… i totalnie rozminąć się z potrzebami.
Mini-waterfall w ramach dwutygodniowego Sprintu to „3 dni analizy, 4 dni dewelopmentu, 3 dni testów”. Niestety, samo przejście na Scrum nie oznacza jeszcze, że zaczniemy pracować w zwinny sposób…
Model Spotify to nasze agile’owe nemezis. I wcale nie chodzi o to, że jest w nim coś z gruntu złego. Ale ta dobra w swoich założeniach idea wyrządziła wiele szkody naszemu zwinnemu środowisku.
System pracy ciągnionej (ang. pull system) jest cechą charakterystyczną jednej z naszych ulubionych metodyk zwinnych, czyli Kanbana. Czym charakteryzuje się ten system i dlaczego jest tak istotny z punktu widzenia samoorganizujących się Zespołów Deweloperskich?
Gdybym dostawał złotówkę, za każdym razem, gdy słyszę „specyfika naszej pracy nie pozwala nam działać w ten sposób”, to wypiłbym już za te pieniądze parę dobrych piw.
W kontekście Scrum często mówi się o świniach i kurczakach (ang. pig and chicken)? Po 183 tekstach na naszym blogu nadszedł wreszcie czas, aby poruszyć ten niezwykle istotny problem. Za górami, za lasami…
Jak głosi stary dowcip, na wielu scrumowych tablicach kolumny nazywają się „to do, in progress, done, really done, this time it’s tested & done” oraz „we just need to polish it next Sprint”. Skąd bierze się problem z „almost done”, czyli rzeczami oznaczanymi jako „prawie skończone”?
Strona [tcb_pagination_current_page] z [tcb_pagination_total_pages]