blob: 038000dee58e54e2797db6240d8717199af75913 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
|
\documentclass{beamer}
%packages
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{hyperref}
\hypersetup{urlcolor=red,colorlinks}
\definecolor{bg}{rgb}{0.95,0.95,0.95}
\usetheme{Rochester}
\title[]{A sketch of an agile software process}
\author{Yves Müller}
\institute{Institute for Computer Science, Freie University Berlin}
\date{15.4.2011}
\begin{document}
\begin{frame}
\titlepage
\end{frame}
\begin{frame}[fragile]
\frametitle{Kurz und Knapp}
\begin{definition}[Agile software development]
Produce high value at low cost.
\end{definition}
\vspace{0.2in}
Bedeutung für unser Projekt
\begin{itemize}
\item Kosten: Zeit die wir aufbringen
\item Wert: Nutzen für OpenStreetMap
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Agile Softwareentwicklung: Wie geht das?}
Puh ... Erklärung ist gar nicht so einfach, darum hier nur ein paar Stichworte.
\begin{itemize}
\item Planbasierende Entwicklung: Ängste, Misstrauen und Stress
\item Agiles Manifest
\item Werteverschiebung
\item Prinzipien
\item viele viele Prozessmodelle
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Crystal Clear}
Der minimale Ansatz zu einem Agilen Prozess.
\begin{block}{Prinzipien}
\begin{itemize}
\item Häufige Auslieferung der Software
\item Passiver Wissenstransfer
\item Ständige Optimierung durch Reflektion
\end{itemize}
\end{block}
Es gibt nur zwei konkrete Methode:
\begin{itemize}
\item Retrosperktive Treffen
\item Iterationen (bei uns 3 Stück)
\end{itemize}
Andere werden bei Bedarf hinzugezogen.
\end{frame}
\begin{frame}
\frametitle{Agile Werkzeuge und Methoden in unserem Projekt}
nur eine kleine Gruppen, die ich sinnvoll fand
\begin{itemize}
\item Testgetrieben Entwicklung
\item StandUp Meeting
\item Plannungsspiel (die Zettelwirtschaft)
\item Gemeinsamer Code (Collective Ownership)
\item Continious Integration
\end{itemize}
diskutierbar, und veränderbar durch Retrosperktive
\end{frame}
\begin{frame}
\frametitle{Testgetriebene Entwicklung}
Tests werden zu erst entwickelt
\begin{block}{Wie geht das?}
Der Code wird in folgendem Zyklus entwickelt.
\begin{itemize}
\item Test schreiben
\item Test erfüllen (genau den Test implmentieren)
\item Verbessern des Codes (Refactoring)
\end{itemize}
\end{block}
Jede funktionale Eigenschaft und jeder Bug hat einen Test
\end{frame}
\begin{frame}
\frametitle{Testgetribene Entwicklung}
\begin{block}{Warum?}
\begin{itemize}
\item Entwicklung von definierten Schnittstellen
\item Feinentwurf auf Modulebene
\item Vermeidung von totem Code
\item Vertrauen in Korrektheit des Codes höher
\item ein ganz kleines bisschen Compilerersatz
\end{itemize}
\end{block}
Erfordert hohe Disziplin, bringt aber unglaubliche Vorteile.
\end{frame}
\begin{frame}
\frametitle{Testgetribene Entwicklung}
Beim Schreiben von Tests sollte beachtet werden:
\begin{itemize}
\item nicht zu große Blöcke testen
\item auch auf Typen testen
\item wenig gegen exteren Systeme testen (nutzt Stellvertreter)
\item die Qualität des Programms ist nur so gut wie die Qualität der Tests
\item Geschwindigkeit ist auch in Test kritisch
\end{itemize}
\end{frame}
\begin{frame}
\frametitle{Standup meeting}
\begin{block}{Was ist das?}
\begin{itemize}
\item Treffen am Anfang jeder Sitzung
\item max. 10 Min
\item alle stehen
\end{itemize}
\end{block}
\begin{block}{Warum?}
\begin{itemize}
\item ihr könnt eure Probleme mitteilen
\item ihr könnt über Erfolge berichten
\item Fortschritt ermitteln
\end{itemize}
\end{block}
\end{frame}
\begin{frame}
\frametitle{Das Plannungspiel}
\begin{block}{Was ist das?}
\begin{itemize}
\item Treffen am Anfang einer Iteration
\item Diskussion über die Anforderungen
\item Festlegung der Ziele für die Iteration
\end{itemize}
\end{block}
\begin{block}{Warum?}
\begin{itemize}
\item nur die Entwickler können ihre Leistungsfähigkeit einschätzen
\item korrekte Anforderungen sind schwer zu formalsieren
\end{itemize}
\end{block}
\end{frame}
\begin{frame}
\frametitle{Collective code ownership / Continious Integration}
\begin{block}{Was ist das?}
\begin{itemize}
\item es gibt keine Modulzuständigkeiten!
\item jeder ist verantwortlich
\item der Code soll immer lauffähig sein
\end{itemize}
\end{block}
\begin{block}{Warum?}
\begin{itemize}
\item Minimierung des Expertentums
\end{itemize}
\end{block}
Das CI kontrolliert ob der Code gut ist (= läuft) und erinnert notfalls alle an ihre Pflichten!
\end{frame}
\end{document}
|
