Jaka jest rola tradycyjnego modułu do śledzenia problemów, gdy używana jest tablica Scrum / Kanban?

Z bardzo wysokiego poziomu wydaje mi się, że istnieją na ogół 2 rodzaje narzędzi do zarządzania projektami:

1. Tradycyjne narzędzia do śledzenia problemów, takie jak Fogbugz, JIRA, BugZilla, Trac, Redmine itp.
2. Karty wirtualnych kart / zwinne narzędzia do zarządzania projektami, takie jak Pivotal Tracker, GreenHopper, AgileZen, Trello itp.

Jasne, pokrywają się w taki czy inny sposób, np. Zadania Pivotal Tracker mogą być importowane do JIRA, sam GreenHopper jest implementowany na bazie problemów JIRA itp. Myślę jednak, że nadal widać różnicę w orientacji między tymi dwoma typami narzędzi.

Tradycyjne narzędzie do śledzenia problemów wydaje się być stosowane nawet w firmach, które poza tym wykonują sprawne zarządzanie projektami. Moje pytanie brzmi: dlaczego to robią? Uważam też, że powinniśmy używać modułu do śledzenia problemów w mojej firmie, ale kiedy o tym myślę, nie jestem pewien, dlaczego warto go używać.

Na przykład zarządzanie Trello wydaje się być zarządzane przy użyciu samego Trello (patrz ta wirtualna ściana ), mimo że mają dostęp do Fogbugz, jednego z najlepszych monitorujących problemy. Może więc nie potrzebujemy tradycyjnego narzędzia do śledzenia problemów, gdy wykonamy 100% naszej pracy w zwinny sposób, korzystając z jednego ze zwinnych narzędzi PM?

Istnieją (przynajmniej) trzy różne sposoby pracy zespołu. Wybierz ten, który działa dla Twojego zespołu.

1. Szczegółowość a przegląd ogólny

Użyj narzędzia do śledzenia problemów, aby śledzić poszczególne zadania. Użyj tablicy kart, aby zachować ogólny obraz głównych funkcji, jako podsumowanie zadań w narzędziu do śledzenia problemów.

2. Błędy vs. funkcje

Użyj narzędzia do śledzenia problemów, aby śledzić pojedyncze błędy i żądania obsługi klienta. Użyj tablicy kart, aby śledzić rozwój nowych funkcji.

3. Dostawa oprogramowania Milestone vs. ciągła dostawa oprogramowania

Użyj narzędzia do śledzenia problemów, jeśli nieregularnie dostarczasz duże bloki nowych funkcji (na przykład, jeśli jesteś zespołem Windows i co kilka lat pojawia się nowa wersja). Jest idealny do procesu programowania, w którym duże, ukończone projekty są dostarczane do klientów jednocześnie (w tym gry, oprogramowanie wbudowane i tradycyjne oprogramowanie oparte na wydaniach rocznych lub półrocznych).

Użyj kartonu, jeśli stale dostarczasz nowe funkcje klientom, ponieważ są one opracowywane, na przykład w zespole internetowym, który stale lub bardzo często dostarcza wartość klientom. W tym scenariuszu proces tworzenia oprogramowania jest prawie jak linia montażowa, a mniej jak projekt z początkiem i końcem.

Myślę, że najprostszą odpowiedzią jest to, że tradycyjne oprogramowanie do śledzenia problemów pomaga zarządzać zaległościami, podczas gdy tablica scrum pomaga śledzić bieżący sprint i wydanie.

Oczywiście można użyć obu rodzajów narzędzi do wykonania obu tych czynności, ale w końcu trzeba wprowadzić pewne kompromisy.

Pełne ujawnienie: jestem trochę stronniczy, ponieważ jestem menedżerem produktu GreenHopper w Atlassian, ale od dłuższego czasu jestem również zaangażowany w rozwój Agile poza Atlassian

Posiadanie tylko narzędzia do zwinnego planowania lub narzędzia do śledzenia problemów jest zdecydowanie opłacalne. Problem polega na tym, że nie jest optymalny. Z mojego doświadczenia wynika, że ​​nie jest optymalny, ponieważ:

• Planowanie produktu zwykle odbywa się na poziomie Epic i Story w zaległościach. Zwinne narzędzia do planowania są tutaj świetne
• Jednak jak mówi stare powiedzenie, żaden plan nie przetrwa pierwszego kontaktu z wrogiem. W tym przypadku po kilku pierwszych wydań jesteś związany do końca się z błędami (i inne informacje zwrotne), które są rejestrowane przez QA, klienci, wsparcie itp te muszą karmić z powrotem do planowania, ale nie przytłaczają go

W związku z tym posiadanie tylko narzędzia do zwinnego planowania jest świetne, ale gdy Twój produkt dojrzewa i dostajesz więcej zewnętrznych danych wejściowych, coraz trudniej jest skutecznie nimi zarządzać. Niektórzy z tych zewnętrznych współpracowników po prostu nie mogą wnosić wkładu w sposób typu „zarządzanego zwinnego Agile”, chcą tylko zgłosić swój problem i przejść dalej. Dzięki temu narzędzie do śledzenia problemów pozwala zaangażować tych autorów i skutecznie zarządzać bieżącą działalnością polegającą na utrzymywaniu rozwoju produktu.

Powiedziałbym, że potrzebujesz obu narzędzi. Naprawdę też potrzebujesz ich zintegrowania, w przeciwnym razie spędzisz cały swój czas starając się zachować synchronizację między nimi.

Niektóre produkty są nieco bardziej zoptymalizowane pod kątem historii i zadań niż wady, ale tak naprawdę nie ma dużej różnicy. Każde dobre zwinne narzędzie PM, które nie narzuca zbyt dużego obciążenia w zakresie wymuszonej struktury lub wymaganych pól, może być łatwo użyte do śledzenia defektów. Mój obecny projekt używa pojedynczego narzędzia zarówno do zadań, jak i wad i działa dobrze poza tym, że produkt jest POS :)

Prowadzimy narzędzie do śledzenia problemów o nazwie DoneDone, które pasuje do nr 3 w odpowiedzi Joela - bardziej tradycyjnej roli narzędzia do śledzenia błędów. Rzeczywiście, zbudowaliśmy go, ponieważ nasze doradztwo historycznie dostarcza dużo kodu (w postaci stron internetowych) w nieregularnych odstępach czasu.

Miesiąc temu zrobiliśmy trochę kontaktu z naszą bazą użytkowników DoneDone i wielu z nich poprosiło o interfejs podobny do Trello i Sprint.ly ze względu na ich bardziej ciągłe cykle kodu / wydania. Innym przydatnym spostrzeżeniem było to, że wielu z tych ludzi używa DoneDone przed rozpoczęciem kontroli jakości, więc chcieliby, aby wszystkie te dane były w jednym miejscu, gdy ich projekty (lub funkcje) przemieszczały się między cyklami.

Moje dwa centy to wszystkie dane z odrobiną przepływu pracy. Różnica polega w rzeczywistości na interfejsie użytkownika i sposobie, w jaki dostosowuje się on do zespołu oraz jakiejkolwiek metodyki i / lub fazy projektu, w której się znajdują.

Śledzenie problemów nie jest zarządzaniem projektami, mimo że wiele narzędzi zaprojektowano tak, aby umożliwić ci jedno i drugie, dlatego jeden system tak naprawdę nie zastępuje drugiego,

Tablica Kanban daje piękny przegląd aktualnej i wyjątkowej pracy, a także pozwala na pierwszy rzut oka wiedzieć, jakie są priorytety, a narzędzie do śledzenia problemów pozwala powiązać problemy z systemem kontroli wersji i działa lepiej jako sposób rejestrowania wszystkiego, co powinno znajdować się w zaległościach Kanban, ale z dodatkowymi szczegółami, które w przeciwnym razie sprawiłyby, że tablica Kanban byłaby prawdziwym bałaganem do przeczytania.

Chodzi o to, że te dwie koncepcje dobrze ze sobą współpracują i ładnie się wspierają. Oczywiście, jeśli masz system, który może dać ci to, co najlepsze z obu światów, w jednej zgrabnej aplikacji, może nieco rozmyć linie, jednak koncepcje nadal pozostają dość odrębne.

Nie wiem, czy jest jasna odpowiedź, więc po prostu zgłaszam swoje doświadczenie ...

Przez wiele lat byłem całkowicie sprzedawane na prawdziwych bugtracker, jak FogBugz, Jira, Trac itp Jednak niedawno podjął pracę gdzie jesteśmy Agile (naprawdę jest zwinny, nie tylko robi Agile). Nie mamy długich, historycznych list błędów ani ładnych przedmiotów.

Takie narzędzie po prostu nie ma sensu. Wszystko, co ważne, idziemy bardzo szybko. Coś nie tak ważnego, cóż, po co?

To dość wyzwalające, że nie mamy ogromnego portfela rzeczy, o których wiemy, że nie będziemy mieli czasu, a jednocześnie wiedząc, że każdego dnia dostarczamy najlepszą wartość.