Jakiego oprogramowania używasz do planowania pracy zespołu i dlaczego?

Planowanie jest bardzo trudne. Nie jesteśmy naturalnie dobrzy w szacowaniu własnej przyszłości, a wiele uprzedzeń poznawczych zaostrza problem. Planowanie grupowe jest jeszcze trudniejsze. Niekompletne informacje, niespójne poglądy na sytuację i problemy z komunikacją komplikują trudność.

Metody zwinne zapewniają jedną strukturę do organizowania planowania grupowego - dzięki czemu planowanie jest widoczne dla wszystkich (historie użytkowników), dzielenie go na mniejsze części (sprinty) i zapewnianie analizy retrospektywnej, dzięki czemu można lepiej planować. Jednak znalezienie dobrych narzędzi wspierających te praktyki okazuje się trudne.

Jakiego oprogramowania używasz do osiągnięcia tych celów? Dlaczego korzystasz z tego narzędzia? Jakie sukcesy pan miał z konkretnego narzędzia?

OmniPlan

Narzędzie do planowania Mac OS X.

Pivotal Tracker

Przydatne, nawet jeśli nie robisz „zwinnego” rozwoju.

FogBugz

Niezwykle przydatne i polecane śledzenie problemów.

Używam ich w połączeniu. OmniPlan doskonale nadaje się do rozłożenia wszystkich zadań do wykonania i podzielenia ich między zespół. Możesz skonfigurować ścieżki krytyczne (rzeczy, które muszą się zdarzyć do ukończenia) i podzielić ogólny wysiłek. Świetnie również wizualnie do zarządzania.

Pivotal jest doskonały do ​​utrzymania tempa rozwoju. Jeśli w pełni zasubskrybujesz zwinną metodologię, jest to doskonałe, ale nadal bardzo przydatne do śledzenia funkcji, komponentów zależnych i aktualnie aktywnego statusu.

FogBugz zapewnia łatwy w użyciu interfejs dla nie-programistów do przesyłania błędów lub żądań funkcji i monitorowania postępów. Pojawiające się problemy są oceniane i rejestrowane w Pivotal. Następnie zostają przeniesione do OmniPlan, jeśli staje się większym zadaniem z wieloma komponentami.

Używamy Redmine -> http://www.redmine.org/

Rejestrujemy tam wszystkich naszych programistów wraz z wezwaniami do pomocy technicznej, abyśmy mogli zobaczyć, ile czasu możemy przeznaczyć na sprint na naszym najnowszym etapie rozwoju. Jest przydatny, ponieważ ładnie łączy się z naszym systemem poczty e-mail i naszym systemem kontroli wersji (w naszym przypadku Git, ale działa z innymi).

Łatwo się uruchamia po wyjęciu z pudełka (napisane w Rubim, będzie działać na większości małych serwerów) oraz z dość mocnymi dodatkami, które są łatwe w instalacji i obsłudze.

Czy nic nie odpowiada ?

Wydaje się, że sugerujesz, że narzędzia programowe są wymagane do skutecznego planowania agile. Nie zgadzam się Jeśli Twój zespół prawidłowo używa Scruma lub XP („przy książce”), nie powinieneś w ogóle używać żadnych narzędzi programowych do planowania.

W wielu przypadkach dodanie narzędzi programistycznych do sprawnego procesu jest tylko sposobem na uniknięcie konieczności radzenia sobie z rzeczywistym problemem leżącym u podstaw słabej komunikacji lub zaufania. Takie problemy najlepiej rozwiązać innymi sposobami.

Zalecam, aby zacząć bez żadnych narzędzi cyfrowych i dodawać je później, gdy naprawdę zrozumiesz, dlaczego ich potrzebujesz.

(Rozproszone zespoły to szczególny przypadek)

Użyłem zarówno Rally, jak i JIRA z Greenhopper .

Zacznę od JIRA. JIRA to doskonałe narzędzie do śledzenia błędów. Greenhopper to dodatek, który umożliwia zespołom rozpoczęcie pracy z agile. Ponieważ od samego początku nie zostało zaprojektowane jako zwinne narzędzie, niektóre procesy są niewygodne. Narzędzie jest również czasochłonne i trudne w użyciu. Jest to jednak wyjątkowo konfigurowalne. Zasadniczo wydaje się, że jest to narzędzie, w które trzeba wcisnąć sprawne procesy.

Rajd został zaprojektowany od podstaw, aby był zwinnym narzędziem i pokazuje. Bardzo dobrze śledzi wiele zwinnych procesów i uzupełnia proces. Użyłem tego narzędzia w niezwykle zwinnej organizacji, dzięki czemu mogliśmy śledzić zależności między zespołami i skomplikowane projekty, w które zaangażowanych jest kilka zwinnych zespołów. Koordynacja między zespołami to coś, z czym zmagają się inne narzędzia, ale Rally poradziło sobie dobrze. Rally ma również doskonały interfejs API oparty na usługach internetowych. Pozwoliło to mojemu zespołowi napisać niestandardowe oprogramowanie przy użyciu Rally jako naszego zaplecza, a także wygenerować niestandardowe raporty.

Używamy TFS do kontroli źródła i śledzenia elementów pracy (niestety), a ja używam menedżera elementów pracy Telerik, aby pomóc mi nagrywać plany sprintu i utrzymywać synchronizację tablicy zadań. Jeśli jesteś zmuszony do korzystania z TFS, telerik sprawia, że ​​jest to mniej bolesne.

Używamy narzędzia do śledzenia problemów o nazwie FIT (pracuję dla tej firmy jak na zleceniodawcy zewnętrznym, więc to był mój wybór, którego użyć). Fogbugz był drogi w porównaniu. Ma niewielką powierzchnię, jest oparty na sieci, niedrogi i wykonuje zwykłe czynności. Patrzyłem na Redmine, który jest cudownym pakietem, ale zarządzanie było niespokojne, jeśli chodzi o pakiet open source, który wciąż był niesamowity.
W przypadku narzędzia takiego jak narzędzie do śledzenia problemów nie chciałem go utrzymywać, aktualizować ani dostosowywać: chciałem, aby działało od razu po wyjęciu z pudełka i pozostało w tym stanie.