Najlepsze praktyki Redmine [zamknięte]

Jakich wskazówek i „standardów” używasz w procesie zarządzania projektem Redmine?

Czy masz standardowy szablon wstawiania wiki, który możesz udostępnić, lub standardowy sposób pracy nad projektem z wykorzystaniem funkcji błędów i problemów z obsługą?

Czy pozwalasz, aby problemy i aktualizacje były wysyłane e-mailem do Redmine? Czy korzystasz z forów? Czy używasz repozytorium SVN? Czy używasz Mylyn w Eclipse do pracy z listami zadań?

Próbuję przeciągnąć nasz dept. do jakiegoś internetowego PM zamiast przesłanych e-mailem dokumentów Word o niejasnych wymaganiach, a następnie dokumentów Word wyjaśniających, jak QA i Deploy, które gubią się w stosie konkurencyjnych aktualizacji i projektów, więc zanim będę musiał coś naprawić, nikt nie może znaleźć jakąkolwiek dokumentację dotyczącą tego, jak to działa.

Tworzę i utrzymuję aplikacje wewnętrzne dla rodziny firm produkcyjnych. W chwili pisania tego komentarza jestem jedynym programistą / analitykiem w zespole IT. Podczas najgorszej recesji moje wymagania projektowe eksplodowały. W związku z tym mój projekt ORAZ zaległości w wydaniu są dość nieporęczne. Obecnie jesteśmy w trakcie restrukturyzacji mającej na celu powiększenie zespołu.

Oto, jak używam Redmine, aby trzymać głowę prosto (w takim stopniu, w jakim jest to możliwe), moi użytkownicy z daleka i, miejmy nadzieję, zapobiec zbyt dużemu trzymaniu się za ręce nowych pracowników w przyszłości.

• Używam Subversion do kontroli źródła, z TortoiseSVN i wtyczką Tortoise-Redmine o trafnej nazwie . Odświeżenie repozytorium w projekcie Redmine po zatwierdzeniu łączy problem, który pokazuje wersję problemu i aktualizuje moich interesariuszy za pośrednictwem powiadomienia e-mail.
• Opis projektu traktuję jako sposób zakomunikowania celu, zakresu i etapu życia projektu osobom, które nie są zaangażowane. W ten sposób moi użytkownicy wiedzą, co mam na talerzu i co wciąż jest na bufecie, na który patrzę z daleka.
• Używam określonych nazw ról dla moich zestawów uprawnień, które wskazują więcej niż zestaw uprawnień - znowu jako środek dokumentacji. Do moich ról należą: kierownik projektu, członek zespołu projektowego, właściciel, główny użytkownik, drugi użytkownik, obserwator, nadzorca (dla moich szefów ... zarówno zabawne, jak i niezaprzeczalnie poprawne).
• Używam Wiki i Dokumentów do dokumentacji, w zależności od tego, co uważam za stosowne.
• Wersje są dla mnie prawie bezużyteczne, więc zamiast używać ich do planowanych wydań, używam ich do grupowania powiązanych problemów w sprinty.
• Używam wspaniałej wtyczki Stuff-To-Do Erica Davisa, aby organizować / reorganizować wyżej wymienione sprinty przed masową edycją wersji docelowych w moich sprawach. Dzięki temu moi interesariusze wiedzą, nad czym pracuję i jak ustaliłem priorytety ich zainteresowań (na dobre lub na złe).
• Aby zachęcić użytkownika do interakcji, dodałem linki do projektu Redmine w menu pomocy moich aplikacji. Pole „O mnie” zawiera również link do projektu Redmine.

Przyszłe plany

• Mam nadzieję, że w pewnym momencie skończę moje rozszerzenie Visual Studio dla integracji Redmine.
• Zbuduj bibliotekę kodu, aby luźno połączyć moją aplikację z projektem Redmine: zautomatyzuj zgłaszanie błędów, ostrzegaj subskrybujących interesariuszy z zasobnika systemowego, interaktywne menu pomocy wielokrotnego użytku obsługiwane przez REST API Redmine itp. (Może zautomatyzuj części dokumentacji za pomocą Wiki?)

Jestem niezależnym programistą internetowym Ruby i Redmine, który prowadzi firmę deweloperską jednego (mnie). Więc mój Redmine jest skonfigurowany tak, aby był dość lekki i skoncentrowany na kliencie. Moja Redmine pełni również podwójną funkcję w zakresie hostowania moich projektów Open Source.

Zezwalam na wysyłanie e-mailem nowych problemów i aktualizacji i działa to świetnie dla użytkowników podłączonych do poczty e-mail (lub tych, którzy zawsze korzystają z iPhone'ów).

Używałem widoku repozytorium z repozytoriami git i działa świetnie. Przy każdym meldowaniu odwołuję się do problemu za pomocą #nnn, więc na rzeczywistej stronie problemu będą widoczne wszystkie zatwierdzenia do zaimplementowania funkcji.

Okazało się, że fora są niedostatecznie wykorzystywane. Myślę, że gdyby była jakaś integracja z pocztą e-mail, byłyby bardziej przydatne.

Przydatne okazały się następujące praktyki:

1) Ukryj trackery „Problemów” i „Wsparcie” i zgłoś wszystko jako błąd :

• oszczędność czasu dla programistów, testerów, kierownictwa;
• jeśli jakieś działania mają być rozliczane jako „dodatkowe” lub „nowe funkcje” lub cokolwiek innego, organizowane są szybkie spotkania w celu ich oceny.

2) kamienie milowe i wersje Uwielbiam to, możesz łatwo prześledzić status każdego wydania iw każdej chwili możesz pobrać starszą paczkę, tj. Aby przetestować błąd zgłoszony przez klienta.

3) Funkcja „zapisz” w zakładce „sprawy”: kolejna duża oszczędność czasu, mam zapisane różne zapytania dla wielu codziennych zadań raportowania i to wszystko, czego potrzebuję.

4) integracja wersjonowania, czyli użycie "# 123" w komentarzach tworzy odnośnik do odpowiedniego problemu: po prostu sprytnie!

W naszym systemie intensywnie używamy Redmine. Stworzyliśmy nawet projekt „Sprzedaż”, aby nasz zespół sprzedaży mógł używać go jako CRM. W tym projekcie mamy mnóstwo niestandardowych pól, które zastępują SugarCRM, którego używaliśmy wcześniej.

W ramach naszego systemu mamy projekty oprogramowania serwerowego i klienta. Projekt serwera jest podzielony na moduły podrzędne, w oparciu o to, jak ustrukturyzowałem system i repozytoria podrzędne, ponieważ Redmine lubi osobne repozytorium na projekt.

Używamy, jak zauważają inni, kodów #nnn w komunikatach dotyczących zmian w celu odniesienia do biletów. Fajne jest to, że nie musi to być bilet w tym samym projekcie. W związku z tym bilet sprzedaży może zostać zablokowany przez błąd lub żądanie pomocy technicznej.

Właśnie zaczęliśmy używać Dokumentów jako porządku dziennego / protokołów spotkań. Używamy wersji do grupowania w wydania, zarówno na kliencie, jak i na serwerze.

Aby spróbować użyć wtyczki Redmine Time Tracker do śledzenia czasu, ale zawsze zapominam o kliknięciu początku lub końca. Codziennie otrzymujemy e-maile o problemach, które nie były poruszane od jakiegoś czasu (wydaje mi się, że Redmine Whining), a których termin wykonania przypada w przeszłości lub w najbliższej przyszłości (przypomnienie zaawansowane).

E-maile wsparcia trafiają bezpośrednio do naszego projektu wsparcia, a jeśli importowanie wiadomości e-mail było nieco bardziej niezawodne (czasami nie tworzy poprawnie nowych biletów, jeśli wiersz Project: jest zawarty w wiadomości e-mail), zapytania dotyczące witryny internetowej automatycznie generują bilety sprzedaży . W tej chwili musimy tylko monitorować zgłoszenia pomocy technicznej i przenosić je do działu sprzedaży, jeśli ma to zastosowanie.

Co chciałbym móc zrobić:

• Miej relacje między naszym systemem a redmine, aby bilety mogły być powiązane z użytkownikiem lub firmą w naszym systemie. Ponadto, abyśmy mogli wygenerować nową firmę z kwitu sprzedaży w odpowiednim punkcie. To tylko wymaga ode mnie trochę pracy.
• Miej związek między naszym oprogramowaniem do śledzenia błędów (wartownikiem) a redmine, aby błędy serwera generowały bilet redmine. Ponownie, możliwe do rozwiązania przy użyciu obecnej technologii.
• Poproś klienta stacjonarnego do redmine. Serwer znajduje się w naszej sieci LAN, ale możliwość uzyskania bardziej elastycznego sposobu dostępu do danych innych niż strona internetowa byłaby świetna. Nie chodzi o to, że jest coś, czego tak naprawdę nie mogę zrobić w interfejsie internetowym Redmine, ale coś takiego jak Things.app jest o wiele przyjemniejsze w pracy.
• Przygotuj całą naszą dokumentację pomocy technicznej w Redmine, a następnie wygeneruj ją na serwerze publicznym. W ten sposób nasz personel pomocy technicznej może utrzymywać dokumentację, edytować w przyjemny sposób i wdrażać zmiany na serwerze dokumentów.

Jak dotąd Redmine jest dla nas fantastyczny. Używamy go jako kolejki do sprzedaży biletów / agile dla wielu dzierżawców i powiązaliśmy ją również z SVN. W szczególności:

• Instalowanie / utrzymywanie przez SVN było proste (przeprowadziłem migrację z 1.1 do 1.2 do 1.3 do 1.4 za pomocą svn switch https//.../branches/1.3-stable .poleceń, a następnie poleceń, a rake migratepomiędzy nimi potrzebne były tylko sporadyczne instalacje klejnotów).
• Kopie zapasowe bazy danych i przechowywanych plików to jednowierszowe wykonanie skryptu
• Uwielbiamy wtyczki Time Tracker i Spent Time . Zabiłbym dla grubego klienta śledzenia czasu Mac OS X dla niektórych naszych użytkowników biurowych, ale to nie ma znaczenia :)
• Nie korzystamy zbyt często z forów, ale intensywnie korzystamy z działań i planu działania. Powiązanie problemów z konkretnymi wersjami to dar niebios.
• Mamy również rozróżnienie między klientem a serwerem, ale używamy wersji docelowej, aby powiązać bilety, aby określić, które trafią (i mają otwarte zakończenie NEXT CLIENT RELEASE / NEXT SERVER RELEASE), aby rozróżnić podczas pracy.
• Mieszamy metafory dla statusów - używamy naszych list najpierw pogrupowanych według tych („Natychmiastowe”, „Odrzucone”, „Zablokowane”, „Działające”, „Na pokładzie” „Lista”, „Oczekiwanie na kompilację”, „Wydane do przetestowania „,„ Zweryfikowano ”,„ Wydano do produkcji ”,„ Zamknięte ”,„ Anulowano).
• Następnie w każdej grupie powyżej mamy posortowaną listę priorytetów: („Natychmiastowe”, „Określ priorytety”, „Zaprojektuj i zmień rozmiar”, „P1”… „P5”, „P-Lista obserwacyjna”). To plus powyższe pozwalają na łatwy przepływ pracy z obszaru problemów.
• W przypadku listy podstawowych problemów sortujemy według „Priorytetu”, „Zadania nadrzędnego”, a następnie „Data aktualizacji” - potrzebujemy tego środkowego, aby Redmine ładnie wciskał, jeśli w tej samej grupie znajduje się zadanie podrzędne.
• Używamy zatwierdzeń checkin do powiązania zatwierdzeń z problemami (tj. svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns.") - i przenosimy ten problem do „Oczekiwanie na kompilację” (to było kiedyś „Rozwiązane”, ale miałem dość wyjaśniania, że ​​„Rozwiązane” nie oznacza, że ​​ktoś może spodziewaj się, że zostanie jeszcze wydany).

Myślę jednak, że będę musiał zbadać wtyczkę Redmine-rzeczy do zrobienia. +1 pytanie.

Moja firma współpracuje z producentami oprogramowania i sprzętu o międzynarodowym pochodzeniu. Zanim dołączyłem do firmy, e-mail był używany z dokumentami MS Word do przekazywania naszych problemów i błędów oprogramowania lub sprzętu w celu zażądania naprawy. Tego procesu nie można było śledzić i utrzymywać jakiegokolwiek procesu. Wdrożyłem RedMine jako środek do śledzenia błędów oprogramowania i sprzętu i od tamtej pory działa bardzo dobrze. Moja sytuacja wiąże się z poważną barierą językową. Na szczęście RedMine może wyświetlać się w języku chińskim Sipmlified, a opinie pokazały, że jak dotąd jest to w porządku od moich programistów.

Stan - kiedy znajdę problem z oprogramowaniem lub sprzętem, stan to „Nowy” - gdy moi programiści sprzętu / oprogramowania zobaczą ten problem i pracują nad nim, zmieniają stan na „W toku”. Mogą użyć% wykonanych, jeśli chcą, od 0 do 50. Ustawiłem% Gotowe na 50, gdy uznają, że rozwiązali problem. - Określam, czy problem został rozwiązany, i zmieniam Stan na „Rozwiązane” i% wykonano na 100%. To pozwala mi odfiltrować problemy <lub równe 50%, aby znaleźć problemy, które są nadal otwarte.

Priorytet - Niski, Normalny, Wysoki, Pilny, Natychmiastowy - wszystko dobrze przekłada się na chiński.

Termin - używam tego, aby poinformować mnie, kiedy poprawka została pierwotnie załadowana przez moich programistów. Przetestowanie czegoś i zamknięcie problemu może zająć 4-6 dni. Podoba mi się, że mój wykres Gannt odzwierciedla szybkość reakcji mojego zespołu programistów, a nie to, ile czasu zajęło mi zatwierdzenie poprawki.

Kategoria - zawsze odzwierciedla wersję oprogramowania lub sprzętu, w którym znalazłem problem. Używam tego, aby zobaczyć, która wersja oprogramowania miała najwięcej błędów i upewnić się, że nowsze wersje oprogramowania nie cierpią z powodu regresji.

Mam wszystkich na liście obserwatorów RedMine dla wszystkich błędów. Wiadomość e-mail jest wyświetlana jako (Nowa), (Rozwiązana) lub (W toku), więc moi przełożeni oraz przełożeni i główni inżynierowie zaangażowanych zespołów mogą zobaczyć wiadomość e-mail i szybko przeczytać, jakie postępy są obecnie dokonywane. Większość innych zaangażowanych osób nigdy nie loguje się do RedMine, zazwyczaj jestem jedyny. E-maile doskonale służą do dostarczania natychmiastowych aktualizacji wszystkim, których jedynym zmartwieniem jest to, czy postęp jest czy nie.

Jak wspomniałeś o przesyłaniu dokumentów Worda tam iz powrotem wraz z kontrolą jakości - znam to uczucie, byłem tam, robiłem to. Głównym problemem dla mnie było to, że ludzie z QA nie lubią dodawać problemów do żadnego narzędzia do śledzenia błędów, zapisują je w edytorze obok nich podczas testowania.

Używamy teraz Redmine z fajnym dodatkiem - Usersnap (Uwaga: stworzyliśmy narzędzie, aby rozwiązać ten problem samodzielnie.

Usersnap jest świetny dla twórców stron internetowych - dodaj go do swojego projektu internetowego, a otrzymasz zrzuty ekranu bezpośrednio dołączone do biletów Redmine - w tym meta informacje o używanej przeglądarce, systemie operacyjnym i tak dalej.

Nasi QA / klienci mogą teraz wprowadzać błędy bezpośrednio w aplikacji internetowej, a programiści mogą łatwiej odtwarzać raporty o błędach w Redmine.

Używamy sekcji Mapa drogowa jako przejrzystego sposobu wyświetlania:

• robaki
• funkcje (byłyby to odniesienia do twojego dokumentu Word lub link do stron wymagań HTML)
• uzgodnienia (różnice między wartościami produkcji a wartościami testowymi)
• i tak dalej...

To jest dla nas główny punkt konsolidacji. Reszta jest używana w związku z tym (na przykład sekcja `` zapowiedź '' służy do określenia głównych etapów / dat wydania używanych w mapie drogowej)

Oprócz innych komentarzy, polecam korzystanie z wtyczki "Rzeczy do zrobienia" (napisanej przez Erica Davisa, myślę, że :) Używanie tej wtyczki pozwala na sortowanie problemów w wielu projektach metodą „przeciągnij i upuść”.

https://projects.littlestreamsoftware.com/projects/show/redmine-stuff-to-do

Używamy wersji jako sposobu definiowania sprintów, więc każda wersja jest sprintem z widokiem mapy drogowej dającym wyraźną ilustrację postępu. Problemy w sprintach są oznaczane jako „gotowe do przeglądu” po ich zakończeniu, a następnie zamykane po weryfikacji kontroli jakości.

Używamy wersji jako zaległości w przypadku wszelkich problemów, które wykraczają poza zakres lub tracą priorytet itp.

Używamy Redmine od około roku i ewoluował on sam na wiele sposobów. Używamy wersji do grupowania problemów w celu wydania oraz kategorii do grupowania problemów według dyscypliny.

Każdy problem przechodzi przez przepływ pracy: nowy> w toku> rozwiązany. Następnie tester zamknie problem, gdy będzie zadowolony.

Chcielibyśmy zaktualizować sposób, w jaki używamy Redmine, wydaje się, że jest tak wiele świetnych wtyczek, ale okazało się, że tak wiele z nich jest uszkodzonych lub nie można ich zainstalować.

Używamy wiki kompleksowo do dokumentacji programistów.