aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--doc/softwareprozess.tex200
1 files changed, 200 insertions, 0 deletions
diff --git a/doc/softwareprozess.tex b/doc/softwareprozess.tex
new file mode 100644
index 0000000..038000d
--- /dev/null
+++ b/doc/softwareprozess.tex
@@ -0,0 +1,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}