Project

General

Profile

DeGetting Started » History » Version 5

C S, 2021-02-08 12:31
Aktualisierung auf originale Rev. 9

1 5 C S
Übersetzung der "Rev. 9":http://www.redmine.org/projects/redmine/wiki/Getting_Started/9
2
3 1 M. A.
h1. Erste Schritte
4
5 5 C S
{{>toc}}
6 1 M. A.
7 5 C S
Dies ist eine Anleitung zu den Grundlagen  in Redmine, geschrieben aus der Perspektive eines neuen Benutzers. Wir werden den Schnickschnack weg lassen und gleich *_Projekte anlegen_*, _*Aufgaben anlegen*_ und _*grundlegende Arbeitsabläüfe*_ erstellen .
8
9 1 M. A.
h2. Erster Schritt – Projekte anlegen
10
11
Bevor man ein Entwicklerteam verliert, sollte man für sie ein Projekt zum Arbeiten anlegen. 
12 5 C S
Dies kann als Administrator eingerichtet werden (Standardnutzer /-passwort nach der Installation ist "admin"). 
13
Klicken sie auf _*Projekte*_ (oben links) und dann auf _*Neues Projekt*_ (oben rechts). Anschließend die Felder ausfüllen. Die Beschreibungen zu den Felden können unter [[DeRedmineProjectSettings|hier]] gefunden werden. Das einzige, verwirrend Feld könnte das Feld _Kennung_ sein. Es wird zur internen Projektidentifikation (z.B. Pfadangaben) verwendet und muss daher eindeutig sein.
14 2 M. A.
15 1 M. A.
h2. Zweiter Schritt – Nutzer zuordnen
16
17 5 C S
Sie müssen die Nutzer einem Projekt zuordnen. Beachten sie, dass sie Nutzer standardmäßig manuell aktivieren müssen. Nachdem ein Nutzer die Registrierungsseite ausgefüllt hat, müssen Sie sich als Administrator anmelden, zu Administration:Benutzer navigieren, den Filter auf „Alle“ stellen und den Nutzer aktivieren.
18
Einmal aktiviert, kann der Nutzer einem Projekt zugeordnet werden.  Wenn dies getan ist, können dem Nutzer mehrere  _*Rollen*_ zugeordnet werden. Standardmäßig stehen folgende Rollen zur Auswahl:
19 1 M. A.
* Manager
20
* Entwickler
21
* Reporter
22 3 M. A.
* Leser
23 1 M. A.
24 5 C S
Die Rollen definieren, was ein Benutzer im jeweiligen Projekt tun darf.Es sollte beachtet werden, dass Berechtigungen in 2 unterschiedlichen Bereichen Auswirkungen hat: 
25 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.
26 5 C S
# Zweitens beeinflusst eine Rolle die Berechtigungen in einem Workflow. Im Allgemeinen schreitet eine neue Aufgabe durch verschiedene Zustände von *Neu* zu *In Bearbeitung* über *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 des Workflows).
27 4 M. A.
28 5 C S
h2. Workflows...Das kann man nicht erklären!
29 4 M. A.
30 5 C S
_*Workflows*_ sind die Arbeitsschritte, die Aufgaben in Redmine vom Erstellen bis zum Abschluss durchlaufen. Der Standardarbeitsablauf enthält die folgenden Zustände:
31 4 M. A.
* Neu
32
* In Bearbeitung
33
* Gelöst
34
* Rückfrage
35
* Abgeschlossen
36
* Abgelehnt
37
38 5 C S
Standardmäßig kann jeder, der angemeldet ist ein Problem (Bug oder Feature) erstellen,  aber nur  Manager können sie ablehnen oder eine geschlossene Aufgabe wieder öffnen.
39 4 M. A.
40
h3. Gelöst vs. Abgeschlossen?
41
42 5 C S
Es gibt eine Menge Diskussionen darüber im Internet, aber der allgemeine Konsens ist, dass Resolved bzw. Gelöst 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/ .
43 4 M. A.
44
h2. Dritter Schritt – Aufgabe erstellen
45
46
TBD
47
48
h2. Vierter Schritt – Aufgabe bearbeiten
49
50
TBD
51
52
h2. Step Five – Aufgabe abschließen
53
54
TBD