Scrum jest najlepszy dla zespołów z członkami ogólnych, czyli zespołów, w których co najmniej 2 osoby mogą wykonywać te same zadania. Moim głównym zmartwieniem jest znalezienie dobrych rozwiązań dla dostosowania scrum (co zatrzymać, co usunąć, co poprawić) dla zespołów złożonych ze specjalistów?
Załóżmy, że masz zespół 5 programistów (nie jest prawdziwy, tylko na przykład):
- Jeden matematyk z silnymi umiejętnościami w C;
- Jeden programista DB;
- Jeden programista internetowy;
- Jeden programista UX / GUI;
- Jeden architekt oprogramowania;
Tutaj wszyscy są specjalistami i nikt nie może zastąpić kogoś innego (nie dbam o ryzyko związane z budowaniem takiego zespołu, chcę skupić się na scrumie). Tak więc, w kontekście scrum, oto moje przemyślenia:
- Bezużyteczne planowanie wiosenne: rzeczywiście, gdy matematyk mówi, że dane zadanie jest warte 2 punkty, nikt nie może głosować przeciwko niemu;
- Bezużyteczna miara prędkości zespołu: ponieważ każdy może przydzielić dowolną liczbę punktów swoim zadaniom, prędkość obliczeniowa nie ma sensu;
- Zastępuj codzienne spotkania scrum cotygodniowymi (dłuższymi) spotkaniami scrum: ponieważ każdy członek zespołu pracuje nad własnymi zadaniami, codzienne spotkania scrum powinny być naprawdę ważne, aby zachować „ducha zespołu”. Jednak codzienne spotkania scrumowe powinny trwać około 15 minut. To oczywiście nie wystarczy, aby zrozumieć, co robią i robią inni. Co więcej, matematyk przez większość czasu odpowiada na te same pytania: „Nadal wykonuję % & Lo (+? $$ + &)” ... Cotygodniowe spotkania dawałyby więcej czasu. Aby zachować ten sam czas spotkań między „początkowymi” spotkaniami scrumowymi i „cotygodniowymi” spotkaniami scrumowymi, każde cotygodniowe spotkanie scrumowe powinno trwać (5 dni w tygodniu, 4-tygodniowe sprinty, z 4-godzinnymi spotkaniami sprinterskimi i codziennymi 15-minutowymi): (4 * 60 + 20 * 15) / 4 =>
A może Scrum jest nadal użyteczny? Może należy zastosować inną zwinną technikę?
Odpowiedzi:
Scrum nie jest srebrną kulą. Nie każdy projekt musi wykorzystywać Scrum, aby odnieść sukces. Sytuacja, którą opisujesz, wydaje się jednak idealnie pasować do Lean / Kanban. Możesz to sprawdzić.
Kanban w zasadzie prosi cię o zrobienie tylko kilku rzeczy, z których żadna nie jest sprzeczna z opisywanym zespołem:
Możesz sprawdzić niektóre referencje na temat Kanban:
źródło
Koncentrujesz się trochę za bardzo na mechanice scrum / agile, nie patrząc na to, co ma zapewnić agile. Mówisz, że jeśli matematyk oceni 2 punkty, nikt nie może powiedzieć, że się myli. To nie jest cel. Celem jest uzgodnienie możliwego do osiągnięcia zestawu celów na nadchodzący sprint. Jako ekspert w tym zadaniu będzie wiedział najlepiej, jak długo to potrwa.
„A co jeśli kłamie lub po prostu się pomyli?” mówisz. Z mojego doświadczenia wynika, że ludzie nie doceniają więcej, ponieważ obawiają się, że zostaną zastrzeleni za dokładne zgadywanie. Inni niedoszacowani następnie dodają margines bezpieczeństwa, który równoważy wszystko, a dziwny leniwy przesadzi, aby nie musiał się spieszyć. Z trzech pierwszych, które zostaną wychwycone podczas śledzenia prędkości, drugi, choć brzmi źle, działa, a trzeci to coś, z czym musisz poradzić sobie poza scrumem.
Codzienne spotkanie wciąż przynosi korzyści. Istnieją zależności między członkami zespołu, nawet jeśli są oni specjalistami. Facet z interfejsu użytkownika może czekać na serwerze, aby naprawić błąd powiadomienia. Pracownik serwera może czekać na matematyka, aby dowiedzieć się, dlaczego obliczenia są nieprawidłowe. Nie chodzi tylko o to, jak ich praca wpływa na ciebie. Jeśli członek zespołu jest ciągle opóźniany z powodu „Powodu X”, ale nie poświęcił czasu na złagodzenie przyszłych wystąpień „Powodu X”, można to zakwestionować.
źródło
Jeśli masz specjalistę o kwalifikacjach takich jak te, które opisałeś, twoje przypuszczenie, że każdy pracuje nad własnym zadaniem, z rzadką koniecznością komunikowania się z innymi, jest błędne. W rzeczywistości, aby zrealizować nową funkcję („historię użytkownika”), często trzeba
Sądzę więc, że będą musieli komunikować się znacznie więcej niż w zespole generalistów, gdzie każdy mógłby pracować nad inną historią aplikacji / użytkownika, wprowadzając wszystkie niezbędne zmiany we wszystkich warstwach aplikacji. Dlatego wszystkie wymienione powyżej działania zespołu Scrum mają sens dla takiego zespołu.
źródło
Scrum z pewnością jest nadal odpowiedni dla twojej sytuacji, ale inne ramy również mogą.
Aby zapewnić nowe funkcje, prawdopodobnie potrzebujesz wszystkich lub wielu z tych umiejętności. Aby zespół mógł podejmować decyzje, które wpływają na siebie nawzajem i współpracować, będzie musiał się komunikować. Im dłuższy czas między spotkaniami Scruma, tym dłużej negatywny plan może zbłądzić drużynę. Spotykając się codziennie, zespół może szybko rozwiązać te sytuacje i opracować nowy plan.
Chciałbym również odnieść się do niektórych poruszonych tematów:
Zespoły międzyfunkcyjne Zespół zostałby uznany za funkcjonalny, gdyby posiadał wszystkie umiejętności potrzebne do osiągnięcia celu sprintu i / lub zaległości produktu. Ten sposób nie oznacza, że są 2 osoby dla każdego zadania.
Rozmiary Ważne jest, aby pamiętać, że oceniamy problem biznesowy lub potrzebę, a nie rozwiązanie lub część rozwiązania. Na przykład integracja mediów społecznościowych / Twittera z naszą witryną e-commerce to problem, który wymaga UX, projektowania interfejsu użytkownika, programowania, bazy danych i znajomości interfejsu API Twittera. Zespół powinien oceniać to jako jednostkę, ponieważ jako zespół zamierzają zapewnić tę funkcjonalność. Ten rozmiar nie będzie w 100% dokładny, ale okazuje się, że w sumie prognozy oparte na względnym rozmiarze są bardziej dokładne. Oznacza to, że niektóre będą wysokie, niektóre będą niskie i razem wzięte obliczona prognoza jest dokładniejsza niż szacowany czas trwania.
Bezużyteczne planowanie wiosenne Planowanie sprintu to czas współpracy w zespole Scrumowym (zespół programistów + właściciel produktu + Scrum Master) w celu ustalenia, co należy wyprodukować i opracowania planu na początek. Niektóre zespoły podzielą wybrane pozycje Backlogu Produktu na zadania, podczas gdy inne wymyślą własną drogę do postępu, na przykład testy, które muszą przejść (pomyśl XP).
To dwukierunkowa współpraca. Przypisywanie zespołowi zestawu PBI i powiedzenie „idź” to rola dyktatora. Zespół negocjuje z właścicielem produktu, aby zmaksymalizować czas w sprincie.
Bezużyteczne mierniki prędkości zespołu Dzięki zespołom mierzącym problemy i potrzeby firmy, które przecinają architekturę / system, a wcześniejsze doświadczenia mówią nam, ile z tych zespołów dostarczono w spójnym przedziale czasowym (sprincie), możemy teraz przedstawić prognozę zespołu dla pozostałej części zaległości.
Ponownie, żadne dwa sprinty nie będą takie same, a im mniejszy będzie zestaw przykładowych elementów Backlogu Produktu, tym mniej rozłoży się błąd w szacunkach. Pomyśl o tym jak o giełdzie; zawsze szło w górę, ale to nie znaczy, że nie mamy lat. Łącznie możesz zarabiać pieniądze, ale w danym miesiącu, kwartale, roku zgadniesz źle.
Zamień codzienne spotkania scrum na cotygodniowe (dłuższe) spotkania scrum Daily Scrum zapewnia zespołowi 24-godzinny cykl informacji zwrotnych i możliwość planowania na następne 24 godziny. Nic dodać nic ująć. „Trzy pytania” mają ułatwić ten wysiłek.
Jeśli nie masz żadnych opinii przez 5 dni, uważam, że twoje zadania nie są wystarczająco szczegółowe. To po prostu moja opinia, ale opiera się na moim doświadczeniu jako trenera i członka zespołu. Zespoły powinny częściej rozmawiać, planować i integrować swoje wysiłki.
Podsumowanie Scrum ma na celu ułatwienie uczenia się i równoważenie uczenia się z dostarczaniem (tam, gdzie dzieje się prawdziwe uczenie). Eksperymentuj z procesami i narzędziami na przestrzeni czasu i użyj Scrum, aby sprawdzić wpływ. Spróbuj przejść z codziennych Scrumów do Scrumów i przekonaj się, czy pomaga to zespołom zapewnić odpowiednią funkcjonalność. To może ci pomóc.
źródło