Jak radzisz sobie z kosztami zbyt szybkich zmian?

Jak większość współczesnych programistów cenię zwinne zasady, takie jak współpraca z klientem i reagowanie na zmiany, ale co dzieje się, gdy właściciel produktu (lub ktokolwiek określa wymagania i priorytety) zbyt często zmienia wymagania i priorytety? Jak kilka razy dziennie?

Niedawno odziedziczyłem niewielką bazę kodu, która była błędna, niekompletna i nie mogła nawet poradzić sobie z najprostszym scenariuszem, jaki powinna. Mogę poradzić sobie z problemami technicznymi, ale dostaję kilka e-maili, SMS-ów lub telefonów dziennie z informacją: „OMG, MUSISZ już nad tym pracować PRAWO! NAJWYŻSZY PRIORYTET! Co gorsza, większość rzeczy to drobne szczegóły, które nie są nawet istotne w odniesieniu do tego, co oprogramowanie faktycznie powinno robić, a wdrożenie i tak zajęłoby dni. Próbowałem wyjaśnić, że jest tylko tyle czasu i że najpierw powinniśmy skupić się na najważniejszych rzeczach, ale coś wydaje się gubić w tłumaczeniu, ponieważ to samo dzieje się dzień lub dwa później.

Czy istnieje jakaś rola właściciela produktu, dogłębne studium, metafora lub cytat, który może mi pomóc zmniejszyć ilość zmarnowanego wysiłku lub przynajmniej wyjaśnić koszty tego chaotycznego zachowania?

Do tego służy zaległość. Nowe żądania są umieszczane w zaległości, a priorytety mogą się zmieniać tylko na granicach iteracji. Średnio tygodniowe opóźnienie (połowa dwutygodniowego sprintu) jest wystarczająco sprawne, aby poradzić sobie z wszystkimi, oprócz najbardziej nagłych, sytuacjami kryzysowymi.

Oto jak poradziłem sobie z podobnym problemem. W czasach, gdy byliśmy zwinni przed Agile.

Dla każdego żądania zmiany klient ustawia priorytet. Deweloper może i musi jedynie przerwać pracę nad zadaniem, aby pracować nad zadaniem o wyższym priorytecie. Równie priorytetowe zadania to harmonogramy w kolejności przybycia. (Priorytetu zadania nie można zmienić po rozpoczęciu pracy).

Będzie to bolało, gdy powiesz klientowi, że nie możesz pracować nad jego zadaniem, ponieważ pracujesz nad nieistotnym zadaniem X, które ma taki sam priorytet jak jego ostatnie żądanie. Następnie powiesz mu, że na tym poziomie priorytetu jest 50 trywialnych i nieważnych zadań przed jego ostatnią prośbą. Teraz prawdziwy haczyk - wszystkie te zadania są na poziomie priorytetu 1 (Najwyższy), ustawionym przez ... NIEGO ... Więc nie może cię odrzucić zadania, które wykonujesz. Teraz, kiedy skończysz przesuwać ramkę okna o 3 piksele w lewo, aby zrobić miejsce na dłuższe słowo w tłumaczeniu na islandzki w rzadko używanej opcji konfiguracji .....

Zamykam także drzwi do biura SD, zamykam je i zdejmuję telefony. E-maile były ignorowane aż do 10 rano, 12 po południu i 2 po południu. Pomimo tego, co ludzie myśleli i czuli, świat wciąż krążył wokół Słońca, wykonaliśmy naszą pracę, a „Klientom” dostarczono oprogramowanie szybciej i lepiej niż kiedykolwiek wcześniej.

Kilka tygodni zajęło ustalenie priorytetów na coś bardziej realistycznego, byliśmy w stanie odblokować drzwi itp. Ale system pozostał dość długo. Być może nie musisz być tak ekstremalny (my tak zrobiliśmy) i potrzebujesz wsparcia ze strony kierownictwa wyższego szczebla. Ale to zadziała ....

MACZANKA. Standardowa procedura operacyjna (lub przynajmniej luźny protokół podpisany przez zespół zarządzający). Twój dział musi go opracować lub współpracować z zespołem zarządzającym, aby go opracować. Osoby, z którymi musisz porozmawiać, znajdują się powyżej właściciela produktu / menedżera konta.

Kilka przykładów tego, co powinna zdefiniować SOP.

• Jakie procedury należy stosować, gdy klient lub jednostka wewnętrzna żąda zmiany
• Jakie są implikacje i / lub wpływ na kontrolę jakości lub weryfikację tego produktu?
• Jaka jest metoda rozsądnego ustalenia ram czasowych dostawy? Ta iteracja? Następna wersja?

Bez takich procedur wszyscy będą na ciebie biegać, jakby ścigali ich zombie i oczekują wszystkiego TERAZ TERAZ TERAZ. Tacy ludzie nie będą szanować twojego grzecznego „nie” lub „proszę czekać”. Mając ustaloną politykę, ci mutanci, którzy pragną kodu, zrozumieją, że nie mają racji, prosząc o rzeczy w tak luźny sposób.

Rezultat końcowy jest niezadowolony i nie leży to w najlepszym interesie Twojej firmy.

Na marginesie, być może odziedziczyłeś czyjś bałagan spowodowany tak rażącym brakiem szacunku dla jego pozycji i obowiązków. Ludziom w takiej sytuacji trudno jest wyprodukować produkt wysokiej jakości. Czy to dziwne? Inżynieria oprogramowania 101.

Bardzo trudno jest pracować w warunkach „gotowości, strzału, celu”. Brzmi dla mnie tak, jakbyś otrzymywał wymagania od bardzo niepewnej osoby, której opinia zmienia się za każdym razem, gdy wyżej postawiona osoba sugeruje pomysł koncepcyjny.

W tego rodzaju sytuacjach uważam, że warto czekać NAJMNIEJ godzinę na odpowiedź na e-maile. (Zignoruję te teksty, chyba że SMS-y znacznie zastąpiły e-maile przez całą organizację.) Być może przeczytaj je, ale nie odpowiedz. W ten sposób możesz poświęcić czas na skupienie się na faktycznej pracy, którą musisz wykonać, a nie na dyskusji o przypadkowych pilnych sprawach, które jutro mogą stać się nieistotne, a nawet o dwóch lub trzech e-mailach później. W mojej ostatniej pracy, jeśli coś było NAPRAWDĘ pilne, ktoś przyszedłby ze mną porozmawiać osobiście, zakładając, że nie widziałem jeszcze e-maili (jeśli pracujesz zdalnie, rozmowa telefoniczna z faktyczną rozmową dwukierunkową może być odpowiednik).

Gdy rozmawiasz twarzą w twarz lub rozmawiasz przez telefon, dobrze jest powtórzyć to, o co prosi dana osoba, a następnie zadać pytania dotyczące nowych wymagań i priorytetu. „Jeśli dobrze rozumiem, mówisz, że powinniśmy przestać pracować nad bieżącym najwyższym priorytetem X, a teraz skupić się na priorytecie minuty Y. To duża zmiana. Czy możesz wyjaśnić zmianę w firmie? Może potrzebuję więcej informacji praca, a nie tylko zmiana interfejsu użytkownika. Czy będą zmiany w innych procesach biznesowych, takich jak fakturowanie lub inwentaryzacja (na przykład)? Czy spodziewasz się, że te nowe elementy danych pojawią się we wszystkich raportach miesięcznych? ” Przydatne jest również powiedzenie czegoś, co brzmi: „Rozumiesz, że jeśli będziemy kontynuować ten nowy wysiłek, opóźni to wydanie Bieżącego najwyższego priorytetu X o co najmniej (tydzień, miesiąc,

Jeśli jest to nagły wypadek, wnioskodawca powinien być w stanie odpowiedzieć na tego rodzaju pytania lub natychmiast skierować Cię do kogoś, kto mógłby. Jeśli nie jest to nagły wypadek, ten rodzaj rozmowy zmusi osobę żądającą zwolnienia i określi, jak ważna jest zmiana, biorąc pod uwagę, że musi ona uzyskać więcej informacji. Często widzą, że to, co jest już w potoku, jest ważniejsze, a przynajmniej nie warte zatrzymania, a nowe żądanie może znaleźć się na liście.

Jeśli okaże się, że zmiany są konieczne, uznam za użyteczne spisanie żądanych informacji i zrozumienie zmian w wiadomości e-mail, a następnie wysłanie ich do pierwotnego wnioskodawcy z pytaniem, czy zgadzają się na zakres zmiany, ponownie, jako wyjaśnienie. W ten sposób napisałeś dokumentację dotyczącą tego, co należy zrobić i dlaczego została o to poproszona, na wypadek, gdyby pojawiło się cokolwiek, dlaczego nie pracujesz już nad bieżącym najwyższym priorytetem X, lub musisz wyjaśnić, dlaczego nie upłynęły pierwotne terminy do spełnienia

Mam nadzieję, że powinno to poprawić relacje z wnioskodawcą, ponieważ demonstrujesz swoją wiedzę i upewniasz się, że pracujesz nad tym, czego chcą, ale jesteś uczciwy w kwestii tego, co trzeba zrobić, aby wprowadzić zmiany. Pytając o prośbę szczegółowo, widzą, że myślisz z wyprzedzeniem i zastanawiają się nad rzeczami, których pierwotnie nie mieli.

Wygląda na to, że nikt jeszcze o nim nie wspominał, Sprint i jego historie użytkowników ideally should be locked till the next sprint(typowy sprint zajmuje 2-4 tygodnie). Blokując - mam na myśli, że do już uruchomionego Sprint nie należy dodawać żadnych dodatkowych zadań.

Jeśli historia użytkownika jest na tyle duża, że ​​nie mieści się w sprincie, spowolnij ją do mniejszych, możliwych do wykonania zadań podczas sprintu. Ponadto, jak wspomniano, nawet zaległe zadania muszą pozostać w zaległościach , a podczas następnego planowania sprintu wysoki priorytet po podniesieniu flagi :)

Edycja: tylko niewielkie zmiany można wprowadzić wiosną. jeśli mają stan wyjątkowy. Jeśli jednak podczas sprintu zawsze zdarza się kilka sytuacji awaryjnych, wówczas w planowaniu sprintu należy coś zmienić.

Scrum ma rolę Scrum Master, czyli osobę, która powinna zająć się wspomnianymi przez ciebie problemami.

Jeśli jest ktoś taki jak lider zespołu, kierownik projektu, mistrz scrum itp., Który jest odpowiedzialny, porozmawiam z tą osobą.

Próbowałem wyjaśnić, że jest tylko tyle czasu i że najpierw powinniśmy skupić się na najważniejszych rzeczach, ale coś wydaje się gubić w tłumaczeniu, ponieważ to samo dzieje się dzień lub dwa później.

Myślę, że będziesz musiał to wyjaśniać raz za razem. Wygląda na to, że musisz zaakceptować fakt, że niektóre osoby, z którymi współpracujesz, mają nieprzydatne nawyki. Jeśli masz szczęście, w końcu zobaczysz zmianę.

Zwinny Manifest mówi, że jednym z najbardziej podstawowych zasad jest:

Witamy zmieniające się wymagania, nawet w późnej fazie rozwoju. Zwinne procesy wykorzystują zmiany w celu uzyskania przewagi konkurencyjnej klienta.

Nie wierzę jednak, że oznaczały one zmianę na codzień. Może zaistnieć potrzeba zmiany ceny podstawowej produktu wiele razy dziennie, ale bez zmiany sposobu, w jaki produkt może być sprzedawany wiele razy dziennie. Raczej przepływ pracy przy sprzedaży produktu może się zmieniać co tydzień (w szybko reagujących i dynamicznych firmach).

Ponownie, choć przepływ pracy sprzedaży produktu może się zmieniać co tydzień, myślę, że ogólny produkt nie będzie zmieniany co tydzień. Nie wyobrażam sobie Microsoft, który dziś daje nam Office, ale jutro dostanie Offooose, a tydzień później Offasooooooooooos.

Nie, to nie to, co zwinny oznacza przez zmianę. Wierzę, że wynika to z kiepskich wizji i dużego głębokiego niezrozumienia pojęcia zmiany.

Nie wspominając już o tym, że zmiana nie jest mile widziana w sprincie, w którym programiści udają się do swoich jaskiń i muszą skoncentrować się na tym, co robią. Zmiany należy raczej dodawać do Backlogu Produktu oraz analizować i ustalać priorytety, zanim zostaną one dostarczone do rąk zespołu scrumowego. Innymi słowy, Backlog Sprint nie jest niezmienny. Należy dążyć do większej zwinności przy użyciu krótszych sprintów, a nie poprzez wstrzykiwanie zmian bezpośrednio do pomieszczeń programistów, wiele razy dziennie.