Co zrobić z „Programowaniem opartym na niepowodzeniach”?

W naszym sklepie staramy się być zwinni. I powiedziałbym, że robimy wielkie postępy. To powiedziawszy, niektórzy z nas zauważyli wzorzec, który zaczęliśmy nazywać „Rozwój oparty na niepowodzeniach”.

Rozwój zależny od awarii można zasadniczo opisać jako zwinny cykl wydawania / iteracji, w którym błędy / funkcje są kierowane nie przez zadania i historie z kryteriami akceptacji, ale z defektami wprowadzonymi w oprogramowaniu do śledzenia defektów.

Nasz zespół ma świetnego kierownika projektu, który stara się uzyskać kryteria akceptacji od klienta (klientów), ale nie zawsze jest to możliwe. Z mojego fotela ds. Rozwoju wynika to z faktu, że klient albo nie wie dokładnie, czego chce, albo (i to jest najważniejsze) dwa różne „obozy” w głównym biurze klienta konfliktują z tym, w jaki sposób należy wdrożyć historię. Obóz A luźno dyktuje, że funkcja X działa w ten sposób , a następnie obóz B zawiedzie, ponieważ nie działa w ten sposób . Stąd termin „FDD”. Proces jest napędzany przez „awarie”.

To prowadzi do mojego pytania: czy ktoś jeszcze tego doświadczył, a jeśli tak, to jakieś wskazówki / sugestie, jak sobie z tym poradzić?

Oczywiście staraliśmy się, aby obóz A i B zgodzili się wcześniej, ale wszyscy wiedzą, że nie zawsze tak jest.

Dzięki

Bardzo sprzeczne wymagania nie są niczym niezwykłym w świecie korporacji. I to często powoduje, że projekty automatyzacji procesów biznesowych „zawodzą”. Może to być tak proste, jak „podręcznik zasad i procedur mówi, aby zrobić X”, podczas gdy ludzie, którzy faktycznie wykonują pracę, wykonują Y. Wykonanie oprogramowania na Y oznacza, że ​​ludzie płacący za oprogramowanie będą nalegać, aby oprogramowanie było wadliwe perspektywiczny. Wykonanie oprogramowania w X oznacza, że ​​ludzie, którzy faktycznie wykonują pracę, nie mogą jej wykonać.

Zwykle większość firm programistycznych wybiera to, co mówią menedżerowie, niż to, co mówią pracownicy, ponieważ w ten sposób płacone są rachunki. W idealnym świecie nie ma niedopasowania impedancji między pisemną a rzeczywistą polityką; w prawdziwym świecie większość pracy biurowej jest nieformalnie podzielona i nieudokumentowana.

Obóz A luźno dyktuje, że funkcja X działa w ten sposób, a następnie obóz B zawiedzie, ponieważ nie działa w ten sposób.

Niedopasowanie między CampA i CampB jest kwestią polityczną, a nie kwestią oprogramowania. Rozwiązanie problemu będzie wymagało rozmowy z ludźmi i zdobycia jednego wyraźnego zwycięzcy.

Jednym z głównych powodów korzystania z iteracyjnego programowania jest to, że masz grupę klientów, która nie ma dobrego pojęcia, czego chce.

To nie jest porażka. Wielu klientów po prostu nie ma pojęcia, czego dokładnie potrzebują, dopóki nie dostanie czegoś w swoje ręce. Właśnie dlatego klient po raz pierwszy widzi, że system nie powinien być wykonany po zakończeniu montażu i wykończenia. Niech zobaczą to wcześnie i często.

Innymi słowy, jeśli byłby to jedyny problem, nie ma powodu do paniki, chyba że znajdziesz się w sytuacji, w której po prostu będziesz mieć niekończące się próby.

Problem braku porozumienia między ciałem klienta to problem menedżera produktu, który nie powinien wyciekać. Najbardziej powinieneś zobaczyć zaległości / zadania / cokolwiek. Oczywiście, PM często będzie zajmował się rozwojem, ponieważ jest to jedyne miejsce, w którym mogą, ale to nie powinno na ciebie wpływać.

Sposób zarządzania będzie w dużej mierze zależał od tego, kim są obóz A i obóz B.

Jeśli obóz A i obóz B reprezentują dwa wyższe poziomy, sprowadź kogoś, kto faktycznie użyje systemu, aby powiedzieć ci, czego potrzebujesz. Czasami zdarza się, że powietrze na rozrzedzonym terenie jest rozrzedzone, co powoduje odłączenie się od rzeczywistości. Ktoś, kto jest zaangażowany, może często przejść przez idealizm i wskazać, co jest naprawdę potrzebne.

Z drugiej strony, jeśli A i B są grupami użytkowników, stosuje się odwrotną strategię nakłaniania kogoś z kierownictwa do ustanowienia prawa.

We wszystkich przypadkach doskonałość jest wrogiem wystarczająco dobrego.

To, co opisujesz, jest typową błędną implementacją Agile. Nie akceptujecie zmian, jesteście ich niewolnikami .

Czy masz właściciela produktu? Czy możesz z nimi porozmawiać w razie potrzeby? Czy robisz recenzję sprintu z użytkownikami? Czy użytkownicy są zaangażowani w proces (za pośrednictwem właściciela produktu) w planowaniu sprintu? Czy masz testerów w głównym zespole?

Gorąco sugeruję zatrudnienie trenera Agile i / lub wysłanie swojego zespołu na szkolenie.

Innym rozwiązaniem jest zaprzestanie robienia Agile.

Jeśli grają w ping-ponga (A mówi do x, B odrzuca, mówi y, następnie A odrzuca i wraca do x), wtedy twoi potencjalni klienci (PO lub cokolwiek masz) muszą pobić ich, aby podjąć decyzję. .

Jest OK, jeśli pierwsze przejście nie spełnia ich potrzeb (chodzi o to, aby dać im coś do obejrzenia), ale jeśli siedzą tam i poruszają się w przód i w tył podczas kolejnych iteracji, nigdy nie zostanie to zrobione.

Problemem tutaj nie wydaje się być: „Będę wiedział, kiedy to zobaczę”. Modele szkieletowe mogą (do pewnego stopnia) pomóc w rozwiązaniu tego konkretnego problemu.

Problem w tym, jak mi się wydaje, dwie konkurujące ze sobą frakcje w twoim kliencie. Idealnie obozy A i B miałyby jakąś wynegocjowaną wspólną wizję, którą mogliby wam przedstawić.

Być może mogą zostać zmuszeni do stołu, gdy wyjaśnisz, ile kosztuje ich walka, gdy ponownie wykonasz to, o co poprosił A (B) (lub odwrotnie).

Pomogłoby w tym zachowanie szczegółowych notatek dotyczących czasu. (W mojej pracy napisałem lekką aplikację do śledzenia czasu: łatwa w użyciu i łatwa do raportowania oraz raportująca czas w 15-minutowych porcjach. Łatwo jest powiedzieć „Spędziłem n godzin na funkcji X.”)

Oznacza to, że jesteś narażony na ryzyko zdenerwowania klienta lub złego wyglądu bez względu na to, co zrobisz, ponieważ to, co robisz dla B, może zdenerwować A (lub odwrotnie).

Mamy nadzieję, że u klienta znajdziesz bohatera, który zajmie się tobą walkami.

Moim zdaniem problem można skutecznie rozwiązać tylko w jednym miejscu u klienta, co będzie trudne.

Wspominasz, że dążysz do zwinności, więc wezmę to z perspektywy scrum, czyli zwinnego procesu, który znam najlepiej.

Według scrum, masz konkretną rolę, właściciela produktu, który jest odpowiedzialny za nadawanie priorytetu historiom / błędom / wydaniom użytkowników itp. Najlepiej powinna to być tylko jedna osoba. Jeśli istnieje wiele zainteresowanych stron o różnych poglądach na to samo oprogramowanie, to właściciel produktu odpowiada za to, aby produkt spełniał wszystkie zainteresowane strony.

Wydaje mi się, że kierownik projektu ma tę rolę. Ale ponieważ nazywany jest kierownikiem projektu, a nie właścicielem produktu, jestem przekonany, że jest on również obciążony innymi zadaniami (tradycyjne, niestabilne zadania związane z zarządzaniem?) I nie ma wystarczającej ilości czasu na realizację rola właściciela produktu.

Uważam więc, że potrzebujesz jednej osoby odpowiedzialnej za koordynację potrzeb między różnymi zespołami u klienta, upewniając się, że wymagania / historie użytkowników dostarczone do programistów zostały zweryfikowane przez oba zespoły u klienta. Wykonywanie tej roli może być z łatwością pracą na pełen etat, szczególnie u posiadanego klienta.

Idealnym rozwiązaniem byłoby przeniesienie tej odpowiedzialności na klienta, aby jeden z pracowników klienta pełnił rolę właściciela produktu. Tak długo, jak klient nie pełni tej roli, nie jest zaangażowany w rozwiązywanie własnych wewnętrznych sporów i pozostawia to Tobie rozwiązanie tego, czego najprawdopodobniej nie będziesz w stanie. I dlatego uważam, że jedynym skutecznym rozwiązaniem jest powierzenie klientowi tej odpowiedzialności.

Ale biorąc pod uwagę fakt, że już rozpocząłeś współpracę, uważam, że będzie ci ciężko wprowadzić tę zmianę.

Aby Twoje oprogramowanie zostało zaakceptowane przez klienta, musi spełniać wymagania określone przez klienta zgodnie z kryteriami akceptacji.

Masz zestaw wymagań użytkownika w postaci historii i kryteriów akceptacji, ale część organizacji klienta ma różne interpretacje historii użytkownika, co prowadzi do niejednoznaczności.

Możesz wyjść z tej sytuacji, opisując funkcjonalny projekt i wdrożone reguły biznesowe i podpisując je przez klienta. Będą wtedy sprawdzane podczas akceptacji. Musi to zostać uprzednio uzgodnione przez klienta, aby uniknąć późniejszych dyskusji na temat znaczenia całej dokumentacji.

Tak długo, jak twoja grupa nie jest w stanie opisać oprogramowania, które budujesz w taki sposób, że obie grupy się na to zgadzają, nadal jesteś w fazie analizy wymagań projektu.

Twój kierownik projektu może / powinien oferować płatne doradztwo w ramach projektu, aby rozwiązać niejednoznaczność wymagań funkcjonalnych.

Myślę, że wszyscy widzieliśmy przypadek, w którym otrzymujemy szczegółowe wymagania od użytkownika, wdrażamy je, a następnie słyszymy od użytkownika: „Poczekaj, to nie zadziała dla mnie” po jego wdrożeniu.

Jedną rzeczą, która pomogłaby, jest forma oceny jakości wymagań, podając użytkownikowi szczegółowe przykłady oczekiwanego zachowania systemu. Na przykład możesz powiedzieć: „Oto przykładowy przypadek. Jeśli zaimplementujemy X, wówczas Y będzie wynikiem, a Z jedną z konsekwencji”. W ten sposób możesz napisać „Czekaj, to nie zadziała”, zanim napiszesz kod zamiast po nim.