Best Practices von Redmine

Ich entwickle und pflege interne Anwendungen für eine Familie von produzierenden Unternehmen. Zum Zeitpunkt dieses Kommentars bin ich der einzige Entwickler/Analyst im IT-Team. Im schlimmsten Moment der Rezession explodierten meine Projektanforderungen. Daher ist mein Projekt- UND Issue-Rückstand ziemlich unhandlich. Wir sind derzeit in der Umstrukturierung, um das Team zu erweitern.

So nutze ich Redmine, um meinen Kopf gerade zu halten (soweit dies möglich ist), meine Benutzer in Schach zu halten und hoffentlich zu verhindern, dass in Zukunft zu viele neue Mitarbeiter von Hand gehalten werden.

• Ich benutze Subversion für die Quellcodeverwaltung, mit TortoiseSVN und dem passend benannten Tortoise-Redmine-Plugin . Wenn Sie das Repository im Redmine-Projekt aktualisieren, nachdem ein Commit durchgeführt wurde, wird das Problem mit der Revision des Problems verknüpft und meine Stakeholder per E-Mail-Benachrichtigung aktualisiert.
• Ich verstehe die Projektbeschreibung als ein Mittel, um den Zweck, den Umfang und den Lebenszyklus des Projekts denjenigen mitzuteilen, die nicht beteiligt sind. Auf diese Weise wissen meine Benutzer, was ich auf meinem Teller habe und was noch auf dem Buffet steht, das ich aus der Ferne ansehe.
• Ich verwende für meine Berechtigungssätze bestimmte Rollennamen, die mehr als einen Satz von Berechtigungen angeben - ebenfalls als Dokumentationsmittel. Meine Rollen umfassen Folgendes: Projektmanager, Mitglied des Projektteams, Eigentümer, Primärnutzer, Sekundärnutzer, 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 Probleme in Sprints zu gruppieren.
• Ich verwende das fabelhafte Stuff-To-Do-Plugin von Eric Davis, um die oben genannten Sprints zu organisieren/neu zu organisieren, bevor ich die Zielversionen für meine Probleme massenweise bearbeite. Dadurch 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 in 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, irgendwann meine Visual Studio-Erweiterung für die Redmine-Integration fertig zu stellen.
• Erstellen Sie eine Codebibliothek, um meine Anwendung locker mit dem Redmine-Projekt zu koppeln: Automatisieren Sie die Fehlerübermittlung, alarmieren Sie Abonnenten in der Taskleiste, verwenden Sie das interaktive Hilfemenü, das von der REST API usw.) von Redmine gesteuert wird. (Möglicherweise Teile automatisieren 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 so eingerichtet, dass es sehr leicht und kundenorientiert ist. Mein Redmine erfüllt auch doppelte Aufgaben für Hosting meiner Open Source Projekte.

Ich erlaube das Versenden neuer Probleme und Updates per E-Mail und es funktioniert hervorragend für per E-Mail verbundene Benutzer (oder für Benutzer, die immer auf ihrem iPhone sind).

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

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

Wir haben die folgenden Praktiken für nützlich befunden:

1) Verstecke den "Issue" und "Support" Tracker und füge alles als Bug ein :

• zeitersparnis für Entwickler, Tester, Management;
• sollen einige Aktivitäten als "Extra" oder "Neuheit" oder etwas anderes in Rechnung gestellt werden, werden schnelle Besprechungen zur Bewertung der Aktivitäten organisiert.

2) Meilensteine ​​und Versionen Ich finde das großartig. Sie können den Status jeder Veröffentlichung leicht nachverfolgen und jederzeit ein älteres Paket herunterladen, d. H. Um einen vom Client gemeldeten Fehler zu testen.

3) "Speichern" -Funktion 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) Die Integration der Versionierung, d. H. Die Verwendung von "# 123" in Kommentaren, stellt einen Link zu einem entsprechenden Problem her: Einfach clever!

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

Innerhalb unseres Systems haben wir Projekte für Server- und Client-Software. Das Serverprojekt ist in Submodule unterteilt, basierend auf der Struktur des Systems und der Sub-Repositorys, da Redmine ein separates Repository pro Projekt bevorzugt.

Wir verwenden, wie andere bemerken, #nnn-Codes in Commit-Nachrichten, um Tickets zu referenzieren. Was cool ist, ist, dass es nicht unbedingt ein Ticket für dasselbe Projekt sein muss. So kann ein Verkaufsticket durch ein Fehlerproblem oder eine Supportanfrage blockiert werden.

Wir haben gerade damit begonnen, Dokumente für Tagesordnungen/Sitzungsprotokolle zu verwenden. Wir verwenden Versionen, um Releases sowohl auf dem Client als auch auf dem Server zu gruppieren.

Um zu versuchen, das Redmine Time Tracker-Plugin zu verwenden, um die Zeit zu verfolgen, vergesse ich immer, auf Start oder Ende zu klicken. Wir erhalten täglich E-Mails über Probleme, die seit einiger Zeit nicht mehr behoben 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 stabiler war (manchmal werden neue Tickets nicht ordnungsgemäß erstellt, wenn die Zeile Project: in der E-Mail enthalten ist), werden bei Website-Anfragen automatisch Sales-Tickets 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 würde:

• Stellen Sie eine Beziehung zwischen unserem System und Redmine her, damit Tickets einem Benutzer oder einer Firma in unserem System zugeordnet werden können. Auch damit wir an der entsprechenden Stelle aus einem Verkaufsticket eine neue Firma generieren können. Dafür muss ich nur ein bisschen arbeiten.
• Stellen Sie eine Beziehung zwischen unserer Fehlerverfolgungssoftware (Sentry) und Redmine her, sodass bei Serverfehlern ein Redmine-Ticket generiert wird. Wieder lösbar mit aktueller Technologie.
• Habe einen Desktop-Client zum Redmine. 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 nicht wirklich in der Redmine-Weboberfläche tun kann, aber so etwas wie Things.app ist so viel schöner zu arbeiten.
• Stellen Sie unsere Support-Dokumentation in redmine bereit und generieren Sie sie auf einem öffentlich zugänglichen Server. Auf diese Weise können unsere Support-Mitarbeiter die Dokumentation pflegen, auf nette Weise bearbeiten und Änderungen auf dem doc-server bereitstellen.

Redmine war bisher fantastisch für uns. Wir verwenden es als mandantenfähige Ticketing-/Agile-Priorisierungswarteschlange und haben es auch an SVN gebunden. Im Speziellen:

• Das Installieren/Warten über SVN war ein Kinderspiel (ich habe uns mit den Befehlen svn switch https//.../branches/1.3-stable . Von 1.1 auf 1.2 auf 1.3 auf 1.4 migriert, gefolgt von den Befehlen rake migrate, Wobei nur gelegentliche Gem-Installationen erforderlich waren zwischen).
• Das Sichern der Datenbank und der gespeicherten Dateien ist eine einzeilige Skriptausführung
• Wir lieben die Plugins Time Tracker und Spent Time . Ich würde für einige unserer Büroanwender einen Mac OS X Time Tracking Fat Client töten, aber das ist nebensächlich :)
• Wir nutzen die Foren nicht sehr häufig, verwenden jedoch sehr häufig Aktivitäten und Roadmaps. Das Binden von Problemen an bestimmte Versionen ist ein Glücksfall.
• Wir haben auch Client/Server-Unterscheidungen, aber verwenden Sie die Zielversion, um die Tickets zu verknüpfen, um anzugeben, wohin sie gehen (und haben NEXT CLIENT RELEASE/NEXT SERVER RELEASE mit offenem Ende), um während der Bearbeitung 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", "Freigegeben zum Testen") "," Geprüft "," In Produktion freigegeben "," Geschlossen "," Abgebrochen ").
• Dann haben wir in jeder Gruppe oben diese sortierte Liste von Prioritäten: ("Sofort", "Priorisieren Sie mich", "Gestalten Sie mich und sortieren Sie mich", "P1" ... "P5", "P-Watch-Liste"). Dies und das oben Genannte ermöglichen einen einfachen Workflow für alle Bereiche, in denen Probleme auftreten.
• Für die Liste der grundlegenden Probleme sortieren wir nach "Priorität", "Übergeordnete Aufgabe" und dann nach "Aktualisierungsdatum". Benötigen Sie diese mittlere Aufgabe, damit Redmine ordnungsgemäß eingerückt wird, falls sich eine untergeordnete Aufgabe in derselben Gruppierung befindet.
• Wir verwenden Check-in-Commits, um Commits an Probleme zu binden (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 "Warten auf Build" verschieben (das war früher "Gelöst", aber ich hatte es satt, dieses "Gelöst" zu erklären "meinte nicht, dass jemand damit rechnen kann, dass es noch veröffentlicht wird).

Ich denke, ich muss das Redmine-Plugin noch untersuchen. +1 Frage.

Meine Firma 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 Korrektur anzufordern. Dieser Prozess war unmöglich zu verfolgen und jede Art von Prozess aufrechtzuerhalten. Ich habe RedMine implementiert, um die Software- und Hardwarefehler zu verfolgen, und es funktioniert seitdem 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 von meinen Entwicklern bisher in Ordnung ist.

Status - Wenn ich ein Software- oder Hardwareproblem finde, lautet der Status "Neu". - Wenn meine Software-/Hardwareentwickler dieses Problem erkannt haben und daran arbeiten, ändern sie den Status in "In Bearbeitung". Sie können die% 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 behoben 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 alles gut ins Chinesische.

Fälligkeitsdatum - Hiermit teile ich mir mit, wann der Fix ursprünglich von meinen Software-Entwicklern 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 Softwareteams widerspiegelt und nicht, wie lange ich gebraucht habe, um den Fix zu genehmigen.

Kategorie - Dies gibt immer die Version der Software oder Hardware wieder, bei der ich das Problem gefunden habe. Ich benutze diese Option, um festzustellen, welche Softwareversion die meisten Fehler aufwies und um sicherzustellen, dass neuere Softwareversionen nicht unter einer Regression leiden.

Ich habe alle auf der RedMine-Beobachtungsliste für alle Bugs. 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 nachlesen können, welche Fortschritte derzeit erzielt werden. Die meisten anderen Beteiligten melden sich nie bei RedMine an, normalerweise bin ich der einzige. Die E-Mails dienen perfekt dazu, jedem, der sich nur darum kümmert, ob Fortschritte erzielt werden oder nicht, sofortige Aktualisierungen zu ermöglichen.

Wie Sie bereits erwähnt haben, senden Sie Word-Dokumente mit Ihrer Qualitätssicherung hin und her. Ich kenne dieses Gefühl. Das Hauptproblem für mich war: QA-Leute mögen es nicht, Probleme in einem Bug-Tracker hinzuzufügen, sie notieren sie während des Testens in einem Editor neben sich.

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

Usersnap ist ideal für Webentwickler - fügen Sie es Ihrem Webprojekt hinzu und Sie erhalten Screenshots, die direkt an Redmine-Tickets angehängt sind - einschließlich Metainformationen über den verwendeten Browser, das Betriebssystem usw.

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

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 über mehrere Projekte ziehen und ablegen.

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

Wir verwenden den Abschnitt "Roadmap", um Folgendes übersichtlich darzustellen:

• bugs
• funktionen (dies sind Verweise auf Ihr Word-Dokument oder Links zu HTML-Anforderungsseiten)
• überleitungen (Unterschiede zwischen Produktionswerten und Testwerten)
• und so weiter...

Das ist für uns der Hauptkonsolidierungspunkt. Der Rest wird in Verbindung damit verwendet (zum Beispiel wird der Abschnitt "Ankündigung" verwendet, um die wichtigsten Meilensteine ​​/ Veröffentlichungstermine zu definieren, die in der Roadmap verwendet werden).

Wir verwenden Versionen, um Sprints zu definieren. Daher ist jede Version ein Sprint mit der Roadmap-Ansicht, die eine klare Darstellung des Fortschritts bietet. 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 mehr in den Geltungsbereich fallen oder deren 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 wird durch einen Workflow von neu> in Bearbeitung> gelöst. Dann schließt der Tester das Problem, wenn er zufrieden ist.

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

Wir nutzen das Wiki umfassend zur Entwicklerdokumentation.