K85.pl - Agile i takie tam sprawyZnajdziesz tu posty dotyczące agile, Scrum, Lean itp. Trochę teorii i duuużo praktyki 🏉
Widzisz problemy w swoim zespole, ale każda Twoja próba ich rozwiązania kończy się porażką? Zaczyna Cię to frustrować, bo widzisz ewidentną potrzebę zrobienia retrospektywy, ale zdaje się, że nikt inny tego nie rozumie? I co teraz? Jak ich przekonać? W tym artykule przedstawimy Ci kilka wskazówek, które pomogą przekonać zespół do robienia retrospektywy (praktyki, pomagającej zespołom IT wprowadzać wiele usprawnień).
Kiedy metody pracy z Toyoty i Forda przestaną nas inspirować? Nie sądzę, aby nastąpiło to szybko 😊 Wciąż wychodzą kolejne publikacje. I wciąż uczą czegoś nowego.“Projektowanie przyszłości” to kolejna z takich książek. Autorzy zawarli w niej dużo ciekawych konceptów związanych z podejściem Lean (tu konkretniej Lean Product and Process Development), razem z realnymi przypadkami ich użycia.
Agile zatacza coraz szersze kręgi. Zwinnych praktyk jest całe mnóstwo i mogą pasować do wielu inicjatyw – tam gdzie mamy do czynienia z projektami, z zespołową pracą, planowaniem itp. Już nie tylko zespoły typowo deweloperskie chcą być zwinne, ale także HR, marketing i inne. Razem z Agnieszką, mieliśmy okazję przeprowadzić szkolenie w firmie AirHelp, w której wówczas wspólnie pracowaliśmy, dla działu HR właśnie. W tym poście piszemy o tym jak takie szkolenie wyglądało i co wg naszych doświadczeń może przydać się takiemu zespołowi.
Każdy kto pracuje z zespołami deweloperskimi musi rozumieć podstawy gita – nawet jeśli nie jest programistą. Dlaczego? Bo to integralna część procesu wytwarzania oprogramowania. Z tego tytułu zorganizowaliśmy wywiad, z autorem bloga Mergujmy, nikt nie woła!, Sebastianem. W wywiadzie odkrywamy kilka podstawowych pojęć związanych z gitem. Jakkolwiek sam wywiad Wam nie wystarczy, aby uznać, że rozumiecie podstawy, to liczymy na to, że dzięki niemu i dodatkowym materiałom oswoicie się z tym tematem i będziecie swobodniej go odkrywać dalej, na własną rękę. Gotowi?
Czy zgodzisz się ze stwierdzeniem, że gdy pracownicy identyfikują się ze swoimi kolegami, zespołem, produktem, to ich praca jest łatwiejsza, przynosi lepsze efekty? Ja tak 🙂 Zatem jak ułatwić taką identyfikację, zespołowi? Możemy pomóc mu wytworzyć artefakt, w postaci zespołowego logo. Rzecz, która będzie wizualną manifestacją wartości i relacji, łączących tę grupę ludzi.
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 😮