Best Practices für Redmine [geschlossen]

Welche Tipps und "Standards" verwenden Sie in Ihrem Redmine-Projektmanagementprozess?

Haben Sie eine Standard-Wiki-Einfügungsvorlage, die Sie freigeben können, oder eine Standardmethode zum Bearbeiten eines Projekts mithilfe von Aufgaben und Supportproblemen mit Fehlerfunktionen?

Lassen Sie Probleme und Updates per E-Mail an Redmine senden? Benutzt du die Foren? Verwenden Sie das SVN-Repository? Verwenden Sie Mylyn in Eclipse, um die Aufgabenlisten zu bearbeiten?

Ich versuche unsere Abteilung zu ziehen. in einige webbasierte PM anstelle von per E-Mail gesendeten Word-Dokumenten mit vagen Anforderungen, gefolgt von Word-Dokumenten, in denen erklärt wird, wie QA und Deploy durchgeführt werden, die alle in einem Stapel konkurrierender Updates und Projekte verloren gehen, sodass niemand etwas finden kann, wenn ich etwas reparieren muss jede Dokumentation darüber, wie es funktioniert.

Ich entwickle und pflege interne Anwendungen für eine Familie von Fertigungsunternehmen. Zum Zeitpunkt dieses Kommentars bin ich der einzige Entwickler / Analyst im IT-Team. Während der schlimmsten Rezession explodierten meine Projektanforderungen. Als solches ist mein Projekt- und Issue-Rückstand ziemlich unhandlich. Wir sind derzeit im Umstrukturierungsprozess, um das Team zu erweitern.

So verwende ich Redmine, um meinen Kopf gerade zu halten (soweit dies möglich ist), meine Benutzer in Schach zu halten und hoffentlich in Zukunft zu viel Händchenhalten neuer Mitarbeiter zu verhindern.

• Ich benutze Subversion für die Quellcodeverwaltung mit TortoiseSVN und dem treffend benannten Tortoise-Redmine-Plugin . Durch das Aktualisieren des Repositorys im Redmine-Projekt nach einem Commit wird das Problem verknüpft, das die Überarbeitung des Problems anzeigt, und meine Stakeholder werden per E-Mail benachrichtigt.
• Ich betrachte die Projektbeschreibung als Mittel, um denjenigen, die nicht beteiligt sind, den Zweck, den Umfang und die Lebenszyklusphase des Projekts mitzuteilen. Auf diese Weise wissen meine Benutzer, was ich auf meinem Teller habe und was noch auf dem Buffet steht, das ich aus der Ferne betrachte.
• Ich verwende für meine Berechtigungssätze bestimmte Rollennamen, die mehr als eine Reihe von Berechtigungen angeben - wiederum als Dokumentationsmittel. Meine Rollen umfassen Folgendes: Projektmanager, Projektteammitglied, Eigentümer, Hauptbenutzer, Sekundärbenutzer, Beobachter, Oberherr (für meine Chefs ... sowohl unterhaltsam als auch unbestreitbar korrekt).
• Ich benutze das Wiki und die Dokumente zur Dokumentation, je nachdem, was ich für angemessen halte.
• Versionen sind für mich so gut wie nutzlos. Anstatt sie für geplante Releases zu verwenden, verwende ich sie, um verwandte Themen in Sprints zu gruppieren.
• Ich verwende Eric Davis 'fabelhaftes Stuff-To-Do-Plugin, um die oben genannten Sprints zu organisieren / neu zu organisieren, bevor ich die Zielversionen zu meinen Problemen in Massen bearbeite. Auf diese Weise erfahren meine Stakeholder auch, woran ich arbeite und wie ich ihre Interessen priorisiert habe (zum Guten oder Schlechten).
• Um die Benutzerinteraktion zu fördern, habe ich den Hilfemenüs meiner Anwendungen Links zum Redmine-Projekt hinzugefügt. Das Feld "Info" enthält auch einen Link zum Redmine-Projekt.

Zukunftspläne

• Ich hoffe, dass ich irgendwann meine Visual Studio-Erweiterung für die Redmine-Integration fertigstellen kann.
• Erstellen Sie eine Codebibliothek, um meine Anwendung lose mit dem Redmine-Projekt zu koppeln: Automatisieren Sie die Fehlerübermittlung, alarmieren Sie abonnierende Stakeholder aus der Taskleiste, wiederverwendbares interaktives Hilfemenü, das von Redmines REST-API gesteuert wird usw. (Automatisieren Sie möglicherweise Teile der Dokumentation mit dem Wiki?)

Ich bin ein freiberuflicher Ruby- und Redmine-Webentwickler, der ein Entwicklungsgeschäft von einem (mir) betreibt. Mein Redmine ist also ziemlich leicht und kundenorientiert. Meine Redmine dient auch der doppelten Aufgabe, meine Open Source-Projekte zu hosten.

Ich erlaube das Versenden neuer Probleme und Updates per E-Mail und es funktioniert hervorragend für Benutzer, die mit E-Mails verbunden sind (oder für Benutzer, die immer auf ihren iPhones sind).

Ich habe die Repository-Ansicht mit Git-Repositorys verwendet und sie funktioniert hervorragend. Bei jedem Einchecken verweise ich auf das Problem mit #nnn, sodass auf der eigentlichen Problemseite alle Commits zur Implementierung der Funktion angezeigt werden.

Ich habe festgestellt, dass die Foren nicht ausreichend genutzt werden. Ich denke, wenn es eine E-Mail-Integration gäbe, wären sie nützlicher.

Wir haben die folgenden Praktiken als nützlich erachtet:

1) Verstecken Sie den Tracker "Issue" und "Support" und legen Sie alles als Fehler ab :

• Zeitersparnis für Entwickler, Tester, Management;
• Wenn einige Aktivitäten als "zusätzliche" oder "neue Funktion" oder etwas anderes in Rechnung gestellt werden sollen, werden schnelle Besprechungen vereinbart, um sie zu bewerten.

2) Meilensteine ​​und Versionen Ich liebe das. Sie können den Status jeder Version leicht nachverfolgen und jederzeit ein älteres Paket herunterladen, dh einen vom Client eingereichten Fehler testen.

3) Funktion "Speichern" auf der Registerkarte "Probleme": Eine weitere große Zeitersparnis: Ich habe verschiedene Abfragen für viele tägliche Berichtsaufgaben gespeichert und das ist alles, was ich brauche.

4) Durch die Integration der Versionierung, dh die Verwendung von "# 123" in Kommentaren, wird ein Link zum entsprechenden Problem erstellt: einfach clever!

Wir verwenden Redmine ausgiebig auf unserem System. Wir haben sogar ein "Vertrieb" -Projekt eingerichtet, das unser Verkaufsteam als CRM verwenden kann. Wir haben einen Haufen benutzerdefinierter Felder in diesem Projekt und es ersetzt SugarCRM, das wir zuvor verwendet haben.

In unserem System haben wir Projekte für Server- und Client-Software. Das Serverprojekt ist in Submodule unterteilt, basierend darauf, wie ich das System und die Sub-Repositorys strukturiert habe, da Redmine ein separates Repo pro Projekt mag.

Wie andere bemerken, verwenden wir #nnn-Codes in Commit-Nachrichten, um Tickets zu referenzieren. Was cool ist, ist, dass es kein Ticket im selben Projekt sein muss. Somit kann ein Verkaufsticket durch ein Fehlerproblem oder eine Supportanfrage blockiert werden.

Wir haben gerade damit begonnen, Dokumente für die Tagesordnung / das Sitzungsprotokoll zu verwenden. Wir verwenden Versionen, um sowohl auf dem Client als auch auf dem Server in Releases zu gruppieren.

Um zu versuchen, das Redmine Time Tracker-Plugin zu verwenden, um die Zeit zu verfolgen, vergesse ich jedoch immer, auf Start oder Ende zu klicken. Wir erhalten täglich E-Mails zu Problemen, die seit einiger Zeit nicht mehr angesprochen wurden (Redmine Whining, glaube ich) und deren Fälligkeit in der Vergangenheit oder in naher Zukunft liegt (Advanced Reminder).

Support-E-Mails gehen direkt in unser Support-Projekt. Wenn der E-Mail-Import etwas robuster war (manchmal werden neue Tickets nicht ordnungsgemäß erstellt, wenn die Zeile Project: in der E-Mail enthalten ist), werden bei Website-Anfragen automatisch Verkaufstickets generiert . So wie es ist, müssen wir nur die Support-Tickets überwachen und sie gegebenenfalls in den Vertrieb verschieben.

Dinge, die ich gerne tun könnte:

• Haben Sie Beziehungen zwischen unserem System und redmine, so dass Tickets einem Benutzer oder einer Firma in unserem System zugeordnet werden können. Auch damit wir an der entsprechenden Stelle aus einem Verkaufsticket ein neues Unternehmen generieren können. Dafür muss ich nur etwas arbeiten.
• Stellen Sie eine Beziehung zwischen unserer Fehlerverfolgungssoftware (Sentry) und Redmine her, sodass Serverfehler ein Redmine-Ticket generieren. Wieder mit aktueller Technologie lösbar.
• Haben Sie einen Desktop-Client zum Redminieren. Der Server befindet sich in unserem LAN, aber es wäre großartig, wenn Sie flexibler auf andere Daten als die Webseite zugreifen könnten. Es ist nicht so, dass es irgendetwas gibt, was ich in der Redmine-Weboberfläche nicht wirklich tun kann, aber so etwas wie Things.app ist so viel schöner zu bearbeiten.
• Haben Sie unsere Support-Dokumentation alle in redmine und generieren Sie sie dann auf einem öffentlich zugänglichen Server. Auf diese Weise können unsere Support-Mitarbeiter die Dokumentation verwalten, auf nette Weise bearbeiten und Änderungen auf dem Doc-Server bereitstellen.

Redmine war bisher fantastisch für uns. Wir verwenden es als Ticketing- / Agile-Priorisierungswarteschlange mit mehreren Mandanten und haben es auch an SVN gebunden. Bestimmtes:

• Die Installation / Wartung über SVN war ein Kinderspiel (ich habe uns mithilfe der folgenden svn switch https//.../branches/1.3-stable .Befehle von 1.1 auf 1.2 auf 1.3 auf 1.4 migriertrake migrate Befehlen, bei denen nur gelegentlich Edelsteininstallationen erforderlich sind).
• Backups der Datenbank und gespeicherter Dateien sind eine einzeilige Skriptausführung
• Wir lieben den Time Tracker und die verbrauchte Zeit Plugins . Ich würde für einige unserer Office-Benutzer für einen Mac OS X Time Tracking Fat Client töten, aber das ist nebensächlich :)
• Wir verwenden die Foren nicht viel, verwenden jedoch häufig Aktivität und Roadmap. Das Binden von Problemen an bestimmte Versionen ist ein Glücksfall.
• Wir haben auch Client / Server-Unterscheidungen, verwenden jedoch die Zielversion, um die Tickets zu binden, um anzugeben, welche wohin gehen (und haben die NEXT CLIENT RELEASE / NEXT SERVER RELEASE offen), um während der Arbeit zu unterscheiden.
• Wir mischen Metaphern für Status - wir verwenden unsere Listen, die zuerst nach diesen gruppiert wurden ("Sofort", "Abgelehnt", "Blockiert", "Arbeiten", "An Deck", "Die Liste", "Warten auf Build", "Zum Testen freigegeben" "," Verifiziert "," Für die Produktion freigegeben "," Geschlossen "," Abgebrochen ").
• Dann haben wir innerhalb jeder Gruppe oben diese sortierte Liste von Prioritäten: ("Sofort", "Priorisiere mich", "Design und Größe", "P1" ... "P5", "P-Watch List"). Dies und das oben Genannte ermöglichen einen einfachen Workflow aus dem gesamten Themenbereich.
• Für die Liste der grundlegenden Probleme sortieren wir nach "Priorität", "Übergeordnete Aufgabe" und dann nach "Aktualisierungsdatum". Wir benötigen diese mittlere, damit Redmine gut einrückt, wenn sich eine untergeordnete Aufgabe in derselben Gruppierung befindet.
• Wir verwenden Check-in-Commits, um Commits mit Problemen zu verknüpfen (dh svn ci -m "This fixes #1733 @2.5, holy smoke what a weird foo bug. It is now bacon and unicorns.") - und lassen dieses Problem auf "Waiting For Build" verschieben (das war früher "Resolved", aber ich hatte es satt zu erklären, dass "Resolved" nicht bedeutet, dass jemand es kann erwarte, dass es noch veröffentlicht wird).

Ich denke, ich muss das Redmine-Plug-to-Do-Plugin untersuchen. +1 Frage.

Mein Unternehmen arbeitet mit Software- und Hardwareentwicklern internationaler Herkunft zusammen. Bevor ich zum Unternehmen kam, wurde E-Mail mit MS Word-Dokumenten verwendet, um unsere Probleme und Fehler mit Software oder Hardware weiterzuleiten und eine Lösung anzufordern. Dieser Prozess war unmöglich, irgendeine Art von Prozess zu verfolgen und aufrechtzuerhalten. Ich habe RedMine implementiert, um die Software- und Hardwarefehler zu verfolgen, und seitdem funktioniert es sehr gut. In meiner Situation gibt es eine große Sprachbarriere. Zum Glück kann RedMine in der Sprache Sipmlified Chinese angezeigt werden, und das Feedback hat gezeigt, dass dies bisher von meinen Entwicklern in Ordnung ist.

Status - Wenn ich ein Software- oder Hardwareproblem finde, ist der Status "Neu". Wenn meine Software- / Hardwareentwickler dieses Problem gesehen haben und daran arbeiten, ändern sie den Status in "In Bearbeitung". Sie können% done verwenden, wenn sie dies von 0 bis 50 wünschen. Ich habe sie% Done auf 50 gesetzt, wenn sie das Gefühl haben, das Problem gelöst zu haben. - Ich stelle fest, ob das Problem behoben ist, und ändere den Status auf "Gelöst" und% erledigt auf 100%. Auf diese Weise kann ich Probleme <oder gleich 50% herausfiltern, um noch offene Probleme zu finden.

Priorität - Niedrig, Normal, Hoch, Dringend, Sofort übersetzt sich alles gut ins Chinesische.

Fälligkeitsdatum - Hiermit kann ich feststellen, wann das Update ursprünglich von meinen Softwareentwicklern hochgeladen wurde. Es kann 4-6 Tage dauern, bis ich etwas getestet und das Problem behoben habe. Ich mag es, wenn mein Gannt-Diagramm die Reaktionsfähigkeit meines Software-Teams widerspiegelt und nicht, wie lange ich gebraucht habe, um das Update zu genehmigen.

Kategorie - Dies spiegelt immer die Version der Software oder Hardware wider, bei der ich das Problem gefunden habe. Ich verwende dies, um festzustellen, welche Softwareversion die meisten Fehler aufwies, und um sicherzustellen, dass neuere Softwareversionen nicht unter Regression leiden.

Ich habe alle auf der RedMine-Beobachterliste für alle Fehler. Die E-Mail wird als (Neu), (Gelöst) oder (In Bearbeitung) angezeigt, sodass meine Vorgesetzten sowie die Vorgesetzten und leitenden Ingenieure der beteiligten Teams die E-Mail sehen und schnell lesen können, welche Fortschritte derzeit erzielt werden. Die meisten anderen Beteiligten melden sich nie bei RedMine an, ich bin normalerweise der einzige. Die E-Mails dienen perfekt dazu, alle sofort zu aktualisieren, deren einzige Sorge darin besteht, ob Fortschritte erzielt werden oder nicht.

Wie Sie bereits erwähnt haben, senden Sie Word-Dokumente mit Ihrer Qualitätssicherung vor und zurück - ich kenne dieses Gefühl, dort gewesen zu sein und das getan zu haben. Das Hauptproblem für mich war: QA-Leute möchten keine Probleme in einem Bug-Tracker hinzufügen, sie notieren sie während des Testens in einem Editor neben ihnen.

Wir verwenden Redmine jetzt mit einem netten Addon - Usersnap (Haftungsausschluss: Wir haben das Tool entwickelt, um dieses Problem für uns selbst zu lösen.

Usersnap ist ideal für Webentwickler. Wenn Sie es zu Ihrem Webprojekt hinzufügen, erhalten Sie Screenshots, die direkt an Redmine-Tickets angehängt sind - einschließlich Metainformationen zum verwendeten Browser, Betriebssystem usw.

Unsere QAs / Kunden können Fehler jetzt direkt in der Webanwendung eingeben und die Entwickler können Fehlerberichte einfacher in Redmine reproduzieren.

Wir verwenden den Abschnitt Roadmap, um Folgendes klar anzuzeigen:

• Fehler
• Funktionen (dies wären Verweise auf Ihr Word-Dokument oder ein Link zu HTML-Anforderungsseiten)
• Abstimmungen (Unterschiede zwischen Produktionswerten und Testwerten)
• und so weiter...

Das ist für uns der Hauptkonsolidierungspunkt. Der Rest wird in Bezug darauf verwendet (zum Beispiel wird der Abschnitt "Ankündigen" verwendet, um die wichtigsten Meilenstein- / Veröffentlichungsdaten zu definieren, die in der Roadmap verwendet werden).

Zusätzlich zu den anderen Kommentaren empfehle ich die Verwendung des "Stuff To Do" -Plugins (geschrieben von Eric Davis, glaube ich :) Mit diesem Plugin können Sie die Reihenfolge der Probleme per Drag & Drop über mehrere Projekte hinweg sortieren.

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

Wir verwenden Versionen, um Sprints zu definieren. Daher ist jede Version ein Sprint mit der Roadmap-Ansicht, die den Fortschritt klar veranschaulicht. Probleme in Sprints werden nach Abschluss als "zur Überprüfung bereit" markiert und nach Überprüfung der Qualitätssicherung geschlossen.

Wir verwenden eine Version als Rückstand für alle Probleme, die nicht in den Geltungsbereich fallen oder ihre Priorität verlieren usw.

Wir verwenden Redmine seit ungefähr einem Jahr und es hat sich in vielerlei Hinsicht von selbst entwickelt. Wir verwenden Versionen, um Probleme für eine Veröffentlichung zu gruppieren, und Kategorien, um Probleme nach Disziplin zu gruppieren.

Jedes Problem durchläuft einen Workflow von neu> in Bearbeitung> behoben. Dann schließt der Tester das Problem, wenn er zufrieden ist.

Wir würden gerne die Art und Weise aktualisieren, wie wir Redmine verwenden. Es scheint so viele großartige Plugins zu geben, aber wir stellen fest, dass so viele defekt sind oder nicht installiert werden.

Wir nutzen das Wiki umfassend für die Entwicklerdokumentation.