Jak napisać „SMART” Cele jako zwinny programista?

Jak wiele korporacji firma, dla której pracuję, przechodzi na system oceny wyników oparty na celach SMART . Mój zespół to sprawnie działający zespół programistów wykorzystujący praktyki z Extreme Programming . Na naszą wielką korzyść nasze stosowanie zwinnych praktyk ma pełne wsparcie bezpośredniego i wyższego kierownictwa.

Aby wykonać pracę, nasz zespół wykorzystuje trzytygodniowe iteracje. Poza bezpośrednią iteracją mamy ogólny plan podzielony na ćwiartki. Oznacza to, że to, co osiągniemy za kilka kwartałów od teraz, jest znacznie bardziej ryzykowne niż to, co osiągniemy w najbliższym kwartale. Z pewnością mamy ogólny pogląd na to, dokąd zmierza nasz projekt, ale słowo kluczowe jest tutaj ogólne .

Biorąc pod uwagę nasze podejście do planowania projektów, członkowie mojego zespołu, w tym ja, mają trudności z pisaniem celów, które są konkretne, mierzalne, osiągalne, istotne i określone w czasie (SMART).

Dwa istniejące pytania dotyczące SoftwareEngineering.se dobrze rozwiązują niektóre z naszych problemów:

• Jaki jest przykład dobrego celu SMART dla programisty?
• Czy cele SMART są przydatne dla programistów?

Jednak pytania wywołały bardziej ogólne odpowiedzi niż szczegółowe informacje dotyczące radzenia sobie z celami SMART podczas pracy w zwinnym zespole programistycznym. Jako sprawny programista, jak piszesz cele trwające od pięciu do siedmiu lat, które są konkretne, mierzalne, osiągalne, istotne i określone w czasie?

Ta odpowiedź została napisana z perspektywy kogoś, kto miał taki system zarządzania wydajnością wdrożony w zespole Agile; podobnie jak ty, wszyscy w zespole zdawali sobie sprawę z trudności / bezużyteczności rocznych celów SMART zastosowanych do grupy Agile, gdzie, przy pełnym funkcjonowaniu, wdrożenie Agile można uznać za nierozerwalnie / już SMART.

Nie naprawdę! Nazywaj to racjonalizacją, jeśli potrzebujesz (jeśli logika jest na wpół wypalona ...), ale wyjaśnienie jej recenzentom spoza bezpośredniej organizacji przygotowało grunt pod rzeczywiste „cele”, które stawiamy w systemie zarządzania wydajnością.

• S dla konkretnych : podczas każdego planowania sprintu zespół uzgadnia określony zestaw zadań do wykonania i zobowiązuje się do ich wykonania. Zadania (i historie użytkowników) odpowiadają na pytania o to, co chcę osiągnąć, cele / korzyści związane z osiągnięciem celu, kto jest zaangażowany, gdzie ma miejsce i jakie są ograniczenia.
• M dla wymiernych : lista tych zadań, a także ruch biletów w trakcie sprintu, od rozwoju przez przegląd kodu do kontroli jakości do wydania (lub jakikolwiek jest twój przepływ), odpowiada na pytania o to, ile pracy i kiedy zostanie zrealizowane .
• A do osiągnięcia : funkcjonujące grupy zwinne zazwyczaj nie angażują się w coś na etapie planowania, chyba że jest to wyraźnie możliwe do osiągnięcia - wszystkie elementy są w stanie wiedzieć, jak to osiągnąć
• R dla istotnych : pytania takie, czy warto, czy jest to właściwy czas, czy pasuje do naszych innych wysiłków - historie i zadania nie są wciągane w sprint i podejmowane, chyba że odpowiedź na wszystkie te pytania jest twierdząca ( zazwyczaj ... YMMV)
• T jak na czas : sprint jest koniecznie na czas, czy to 2 tygodnie, 3 tygodnie, więcej czy mniej.

Jeśli zrozumiecie / przekonacie się, że wasza kwartalna praca (a więc i całoroczna praca) sama w sobie jest jednym wielkim SMARTOWYM celem i że wiecie, że osiągacie swoje cele, ponieważ zespół dobrze sobie radzi, prędkość jest pozytywna, premiery się zdarzają , przechodzisz do sedna pytania, które ostatecznie polega na przełożeniu procesu SMART na zestaw celów SMART z korzyścią dla kogoś innego.

W przeszłości mogłem to robić z powodzeniem, pisząc coś, co dla mnie wygląda niejasno i, cóż, niezbyt inteligentnie, ale w rzeczywistości jest całkowicie akceptowalne dla innych.

Kilka przykładów, które przekazały mi gdzie indziej:

• „Chcę wypuszczać nową wersję WidgetMaker co trzy miesiące w następnym roku, postępując zgodnie z naszym wewnętrznym procesem rozwoju oprogramowania, aby dostosować się do ogólnego harmonogramu rozwoju produktu (bla bla)”.

• „Chcę zwiększyć szybkość rozwoju zespołu o n% od wydania A do wydania B, koncentrując się na stopniowych zmianach procesu zalegania zaległości, w celu zwiększenia naszej skuteczności i zmniejszenia opóźnień w wysyłce produktu”.

Wiesz i wiem, że nie są to zasady przewodnie twojej faktycznej grupy programistycznej, ale nie są one całkowicie niezwiązane, a z mojego doświadczenia wynika, że ​​tego rodzaju rzeczy wydają się naprawdę INTELIGENTNE i przydatne dla osób spoza twojej bezpośredniej organizacji (bez bycie jawnym kłamstwem lub całkowicie kulawym).