Lubimy zarówno teksty z cyklu „How To”, jak i te w których na negatywnych przykładach pokazujemy „How Not To”. Dziś więc przyjrzymy się temu, jak łatwo można przedobrzyć z wprowadzaniem usprawnień.
#białko agile blog
Oto wszystkie teksty na naszym zwinnym blogu:
„Powrót do waterfall” brzmi prawie jak tytuł filmu Roberta Zameckisa („Powrót do przyszłości„) prawda? W dobie coraz częstszego narzekania na metodyki zwinne po prostu się zastanawiam – czy powrót do waterfall ma sens?
Kryteria SMART to technika, którą agile’owa filozofia przygarnęła i której już nigdy nie wypuści z ramion. W naszym środowisku najczęściej słyszymy o celach wyznaczanych metodą SMART oraz o SMART-nych akcjach z retro.
Moja dzisiejsza teza jest bardzo prosta i brzmi: większość zespołów, które widzimy na co dzień, jest za duża. Bardzo rzadko mamy do czynienia z sytuacją, w której podzielenie pracującej razem grupy osób nie wyszłoby wszystkim zainteresowanym na dobre.
Nie ma czegoś takiego jak idealny rozmiar User Story. Jedne wymagania są mniejsze, inne większe. Ważne, aby zespoły, które mają je przekształcać w działające oprogramowanie czuły się z nimi dobrze. Są jednak pewne czynniki, które warunkują rozmiar Historyjki Użytkownika.
Czytaliście o pułapce Continuous Integration? Jeśli nie, polecam zeszłotygodniowy tekst Tomka celnie opisujący to zagadnienie. Nawiążę dziś do niego, a sytuacja, którą opiszę będzie jak najbardziej z życia wzięta. Ilu z nas skazuje się na wieczne „nieukończenie” naszej pracy?
Continuous Improvement! A skoro „continuous”, to znaczy, że usprawnieniom nie ma końca. Zawsze przecież można szybciej, dalej, więcej…
Daily Scrum, zwany pieszczotliwie „standupem”, jest tym wydarzeniem, które najczęściej psuje się samo i bez niczyjej złej woli. Dziś #białko pokazuje trzy sposoby na naprawę Twojego daily.
Dziś ciekawostka – pytanie, które na naszych szkoleniach pojawia się zadziwiająco często. „Czy trzeba czekać na retrospektywę, żeby zgłosić jakieś utrudnienia?” Jego wariantem jest też „Czy muszę czekać na następny Daily Scrum, żeby zgłosić bloker?”
Z napisaniem tekstu o tym, jak zacząć pracę w Scrum nosiłem się od dawna. Kiedy dołączamy do już istniejącego zespołu, wszystko wydaje się być proste i poukładane. Mamy Product Ownera, Scrum Mastera, są koledzy i koleżanki tworzący Zespół Deweloperski. Ale co, jeśli jesteśmy na samym początku i nie mamy jeszcze nic?
Strona [tcb_pagination_current_page] z [tcb_pagination_total_pages]