Czy dobrze jest mieć osoby z wieloma rolami w zespole Scrum?

Oceniam kilka metodologii zwinnych w celu wprowadzenia do mojego zespołu. Czy w Scrumie jest dozwolone, aby ta sama osoba pełniła wiele ról? Mamy mały zespół czterech programistów i projektanta stron internetowych; tak naprawdę nie mamy wiodącej roli (spełniam tę rolę), testerów kontroli jakości ani analityków biznesowych, a wszystkie nasze zadania programistyczne pochodzą od CIO. Zautomatyzowane testy są postrzegane jako całkowita strata czasu, a wszystko koncentruje się na szybkości, a nie na jakości.

To, co się stanie, to CIO wymyśli zadanie programistyczne (czy to funkcję, czy błąd) i przekaże je programistom (a nie całemu zespołowi, osobie, często prywatnie lub nieoczekiwanie), która jest wtedy oczekuje się, że zostanie ukończony. CIO nie spełnia wymagań wykraczających poza początkowy pomysł (i to nas ugryzło wcześniej, ponieważ zaimplementujemy coś tylko po to, aby dowiedzieć się, że żaden z użytkowników końcowych nie może korzystać z tej funkcji, ponieważ nie skonsultowano się z nią ani nawet nie poinformowano o niej zanim go opracowaliśmy, w panice powiedziano nam, aby cofnąć zmianę), ale wymaga wyrażenia zgody na wszystko, co robimy.

Po pierwsze, czy styl Scrum jest czymś, co należy rozważyć, aby wprowadzić pewne standardy i praktyki? Z lektury Scrum zdaje się polegać na nieco większym zaufaniu i komunikacji i bardziej koncentruje się na zarządzaniu projektami niż na rozwoju, czego jesteśmy całkowicie pozbawieni, ponieważ nie mamy obecnie żadnych pozorów zarządzania projektami.

Po drugie, jeśli to może zadziałać, czy nie jest rozsądne, aby ktoś, powiedzmy, działał zarówno jako ScrumMaster, jak i programista? Lub też, aby programista był również właścicielem produktu (chociaż są szanse, że będzie to dyrektor IT, który nie jest programistą)? Zdaję sobie sprawę, że Scrum Master i właściciel produktu powinni być różnymi ludźmi, ale jednocześnie nie sądzę, że mamy kogoś, kto ma cechy właściciela produktu (są szanse, że zmieni się w „Potrzebuję wszystkich tych historii, ja nie obchodzi mnie, jak to zrobić ”. umowa i / lub każde zamrożenie zostanie odmrożone na podstawie kaprysu).

Wydaje mi się, że być może będę musiał wybrać fragmenty Scrum / XP / Lean, aby zrekompensować to, jak się obecnie rzeczy mają, ponieważ jest bardzo mało prawdopodobne, aby mentalność mogła zostać zmieniona; na przykład programowanie w parach nigdy nie latałoby (postrzegane jako marnotrawstwo, wykonujesz połowę zadań, jeśli potrzebujesz do wszystkiego dwóch osób), TDD byłoby trudną sprzedażą, ale mile widziane byłyby krótkie cykle.

Scrum, Kanban lub inny metodologii Agile jest przede wszystkim metoda koncentruje się na rozwoju oprogramowania projektów . Innymi słowy, jest to z natury praktyka zarządzania projektami.

O ile desperacko chcesz, abyś ty i twój zespół wykonywali prace projektowe, przekonasz się, że Agile po prostu nie będzie pracować w twojej organizacji, ponieważ tak naprawdę nie wykonujesz pracy „projektowej” lub poświęcasz się zespołowi, aby „zobowiązanie projektowe”.

Możesz zorganizować mini projekt wokół złożonej funkcji, ale w rzeczywistości nie masz połączenia z analitykami biznesowymi lub użytkownikami końcowymi, więc jak możesz sprawdzić, czy dostarczasz Historie użytkowników, skoro nie możesz naprawdę wiedzieć, co to jest użytkownik chce?

Twoim jedynym interesariuszem jest twój szef, a on zasadniczo zapewnia, że ​​twój zespół nie istnieje, aby służyć innym interesariuszom projektu, istniejesz jako zespół, który służy mu i jego potrzebom, niezależnie od tego, jak wpłynie to na innych interesariuszy.

Co więcej, daje indywidualne zadania poszczególnym osobom i prawdopodobnie natychmiast zmienia ich priorytety, gdy decyduje, że powinny odejść. Nie możesz funkcjonować w metodologii zwinnego projektu, jeśli poszczególne zasoby projektu zostaną ponownie ustalone priorytety w odpowiednim momencie lub jeśli sprint zostanie zawieszony.

To nie powinno tak działać

Sprint jest zaangażowanie przez cały zespół do dostarczania podzbiór historie użytkowników w określonym terminie. Po uruchomieniu sprint powinien zostać zakończony, zanim nastąpi zmiana priorytetów lub zmiany. Jak należy zarządzać projektem, gdy jest on przeprowadzany w tak chaotycznym środowisku ad-hoc?

Nie pracujesz w środowisku sprzyjającym metodom Agile do zarządzania projektami. Nie pracujesz nawet w środowisku sprzyjającym metodom Waterfall. Pracujecie w monarchii i jesteście jedynie pionkami królów wykonującymi jego rozkazy i gaszącymi ogień.

To nie jest twórczość zespołu projektowego.

Więc w bardzo niejasny sposób odpowiadam na twoje pytanie, mówiąc, że w twojej sytuacji tak naprawdę nie ma znaczenia, czy poszczególne osoby grają wiele ról. Masz znacznie większe problemy. Pytasz, jak usunąć plamy wodne z dywanu w domu bez dachu.

Jak zauważyłem tutaj , jeśli Scrum Master lub Właściciel produktu mają wykonalne zadania, są również członkami Zespołu.

To powiedziawszy, będziesz mieć poważne problemy z Agile, chyba że będziesz mieć prawdziwe zaangażowanie zarówno od swojego CIO, jak i klientów. Czy Twój CIO jest skłonny pogodzić się z faktem, że nie może dodać przedmiotu pracy w trakcie sprintu, ale będzie musiał poczekać do następnego? Czy chce ustalić priorytety przedmiotów, które mają być opracowane? Z tego, co napisałeś, wygląda na to, że jest właścicielem tego, co robisz, i dlatego powinien być właścicielem produktu. Jeśli on nie chce, nie odniesiesz sukcesu tak jak obecnie.

Scrum może być dobrym rozwiązaniem dla twojego problemu związanego z przypisywaniem pracy CIO do programisty ad hoc, ale tylko wtedy, gdy CIO włączy się do procesu. Podejrzewam, że twojemu dyrektorowi IT nie spodoba się zabranie bezpośredniego zlecenia. Ale jeśli uda Ci się przekonać CIO do pomysłu pisania przez niego historii użytkowników, a następnie nadawania im priorytetów, może znaleźć bardzo skuteczny sposób na zarządzanie. Ale zacznie się od przekonania CIO do trzymania się tego procesu.

Oczywiście Scrum jest czymś do rozważenia. Jest jednak coś do powiedzenia na temat włączenia wszystkich zaangażowanych w tę samą stronę i zaakceptowania kilku zmian w strukturze, a także uzyskania co najmniej kilku sprintów w celu wypracowania różnych początkowych problemów w stosowaniu tej metodologii.

Właściciel produktu powinien znajdować się poza zespołem programistów, ponieważ w przeciwnym razie wystąpiłby zły konflikt interesów. Scrum Master może być programistą, ponieważ w tym przypadku konflikt nie jest tak zły.