Added Vorlesung(30.11)

lerntagebuch.md

@@ -269,3 +269,50 @@ privater *fork*:
 ### Kritik
 
 *forking* is a good practice for a large scale project, where a lot of people working on the same repository at the same time.
+
+## Vorlseung (30.11)
+
+### Lernziele  
+
+In dieser Woche lerne ich etwas über Projektmanagement. Projektmanagement ist ein Regelprozess. Es gibt kein Endtermin. Rollen
+in Projektmanagement sind _Product Owner_, _Scrum Master_, _Stakeholder_, und Projektmitarbeiter. Der _Product Owner_ ist
+verantwortlich für Projektinhalt, Zeitplan, Budget und Prioritäten. _Scrum Master_ ist verantwortlich für Ressourceneinsatz, 
+Mitarbeiter:Innen zu koordinieren und ist Erfüllungsgehilfe, nicht Boss. _Stakeholder_ bestimmen so wohl
+ technische Einschränkungen als auch rechtliche Rahmenbedingungen. _Projektmitarbeiter_ setzt Teilaufgaben um.
+
+Paar Zugänge zum Projektmanagement sind __Wasserfall Modell, V-Modell, Agile Modelle, Kanban, Burn-Down-Chart und Scrum__. 
+
+__Wasserfall Modell__ ist linear und alle Prozessschritte werden ein mal durchlaufen.
+__V-Modell__ ist eine Erwiterung des Wasserfallmodells für Software Entwicklung. Entwicklungsschritten werden Testebenen 
+gegenüber gestellt. 
+__Agile Modelle__ fixiert Aufwand und Zeit, statt Umfang. Es konzentrieren sich auf Endprodukt und Kunden statt Dokumentation und
+Werkzeuge.
+__Kanban__ konzentrieren sich auf Definierung der Teilaufgaben, _backlogging_ und Workflow-Darstellung. 
+__Burn-Down-Chart__ setzt fixe Arbeitspakete mit bekanntem (geschätzten) Aufwand voraus. Der Chart ist Projektfortschritt über 
+die Zeit. 
+__Scrum__ hat fixe Intervalle mit regelmäßige Meetings. Tracking der _story points_ ist wichtig. In Scrum gibt es kein Wettbewerb
+zwischen den Teams.
+
+__Anforderungen des Schätzverfahrens__ sind früh anwendbar, Reaktion auf Anforderungsänderungen, Nachvollziehbarkeit, leifert auch
+Zeitaufwandsschätzung und natürlich geringe Kosten.
+
+__Prinzipien des Schätzverfahrens__: 
+
+1. Schätzung nach _story points_ , nicht nach Zeit.
+2. keine planbaren Störfaktoren.
+3. (automatisiertes) Testen und _Refactoring_ __immer__ einrechnen.
+4. Aufgaben im möglichst kleine Teilaufgaben zerlegen.
+5. Möglichst spät schätzen.
+6. Sag __nein__ ,wennn nicht genug Informationen verfügbar sind.
+
+__Dokumentation__
+
+|klassisch|agil|
+|--|--|
+|Lastenheft|User Stories|
+|Pflichtenheft|Ticketsysteme|
+|Systembeschreibung(Arc42)|
+
+### Kritik
+
+keine