DeGetting Started » History » Version 4

M. A., 2016-05-30 12:49

1 1 M. A.
h1. Erste Schritte
2 1 M. A.
3 1 M. A.
Dies ist eine Anleitung zu den Grundlagen  in Redmine , geschrieben aus der Perspektive eines neuen Benutzer . Wir werden den Schnickschnack weg lassen und gleich * _Projekte anlegen_ *, _ * Aufgaben anlegen * _ und _ * grundlegende Arbeitsabläüfe * _ erstellen .
4 2 M. A.
5 1 M. A.
h2. Erster Schritt – Projekte anlegen
6 3 M. A.
7 1 M. A.
Bevor man ein Entwicklerteam verliert, sollte man für sie ein Projekt zum Arbeiten anlegen. 
8 1 M. A.
Dies kann als Administrator geschen (Standardnutzer /-passwort nach der Installation ‚admin‘). 
9 1 M. A.
Klicken sie auf _*Projekte*_ , dann auf *Neues Projekt*_ .  Anschließend die Felder ausfüllen.
10 1 M. A.
Die Beschreibungen zu den Felden können unter [[RedmineProjectSettings|here]] gefunden werden. Das einzige, verwirrend Feld könnte das Feld Kennung sein. Es wird als internen Projekt- Identifikation verwendet und muss eindeutig sein.
11 2 M. A.
12 1 M. A.
h2. Zweiter Schritt – Nutzer zuordnen
13 3 M. A.
14 1 M. A.
Sie müssen die Nutzer einem Projekt zuordnen. Beachten sie, dass sie Nutzer standardmäßig aktivieren müssen. Nachdem er die Registrierungsseite ausgefüllt hat,  müssen sie sich als Administrator anmelden, zu Benutzer navigieren, deb Filter auf „Alle“ stellen und den Nutzer aktivieren.
15 1 M. A.
Einmal aktiviert, kann der Nutzer einem Projekt zugeordnet werden.  Wenn dies getan ist, können dem Nutzer mehrere  _*Rollen*_ zugeordnet werden. Standradmäßig stehen folgende Rollen zur Auswahl:
16 1 M. A.
* Manager
17 1 M. A.
* Entwickler
18 1 M. A.
* Reporter
19 1 M. A.
* Leser
20 3 M. A.
21 1 M. A.
Die Rollen definieren, was ein Benutzer im jeweiligen Projekt tun darf.
22 1 M. A.
Es sollte beachtet werden, dass Berechtigungen in 2 unterschiedlichen Bereichen Auswirkungen hat: 
23 1 M. A.
# Erstens wirkt die Berechtigungen einer Rolle sich über alle Aspekte eines Projekts aus. Zum Beispiel wird die Manager-Rolle einem Benutzer ermöglichen, neue (Teil-) Projekte zu schaffen, die Foren zu verwalten, das Wiki, das Repository und alles andere innerhalb eines Projekts. Im Gegensatz dazu kann die Entwickler-Rolle das Projekt nicht bearbeiten oder Nachrichten aus den Foren löschen.
24 1 M. A.
# Zweitens beeinflusst eine Rolle die Berechtigungen in einem Workflow. Im Allgemeinen schreitet eine neue Aufgabe durch verschiedene Zustände von * Neu * zu * In Bearbeitung * bis * gelöst * bis * geschlossen *. Einer der wichtigsten Unterschiede zwischen Manager und Entwickler ist, dass Manager Aufgaben ablehnen, aber Entwickler dies nicht dürfen. (Mehr dazu weiter unten bei der Erläuterung der Workflow).
25 4 M. A.
26 4 M. A.
h2. Workflows...You Can't Explain That!
27 4 M. A.
28 4 M. A.
_*Workflows*_ sind die Arbeitsschritte die Aufgaben in Redmine vom Erstellen bis zum Abschluss durchlaufen.  Der Standardarbeitsablauf enthält die folgenden Zustände:
29 4 M. A.
* Neu
30 4 M. A.
* In Bearbeitung
31 4 M. A.
* Gelöst
32 4 M. A.
* Rückfrage
33 4 M. A.
* Abgeschlossen
34 4 M. A.
* Abgelehnt
35 4 M. A.
36 4 M. A.
Standardmäßig kann jeder, der angemeldet ist ein Problem (Bug oder Feature) erstellen,  aber nur  Manager können sie ablehnen oder eine geschlossene Frage wieder öffnen.
37 4 M. A.
38 4 M. A.
h3. Gelöst vs. Abgeschlossen?
39 4 M. A.
40 4 M. A.
Es gibt eine Menge Diskussionen darüber im Internet, aber der allgemeine Konsens ist, dass Resolved bedeutet, ein Entwickler denkt, er habe den Fehler behoben. Geschlossen bedeutet, der ursprüngliche Reporter oder ein Manager hat es unterzeichnet. Viele Blogs sprechen darüber - wie http://journal.sifterapp.com/blog/2011/07/resolved-vs-closed/ .
41 4 M. A.
42 4 M. A.
43 4 M. A.
h2. Dritter Schritt – Aufgabe erstellen
44 4 M. A.
45 4 M. A.
TBD
46 4 M. A.
47 4 M. A.
h2. Vierter Schritt – Aufgabe bearbeiten
48 4 M. A.
49 4 M. A.
TBD
50 4 M. A.
51 4 M. A.
h2. Step Five – Aufgabe abschließen
52 4 M. A.
53 4 M. A.
TBD