summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: ab7def1)
raw | patch | inline | side by side (parent: ab7def1)
author | Felipe Balbi <balbi@ti.com> | |
Wed, 10 Apr 2013 11:48:19 +0000 (14:48 +0300) | ||
committer | Felipe Balbi <balbi@ti.com> | |
Wed, 10 Apr 2013 11:51:18 +0000 (14:51 +0300) |
Finished 2 sections, just missing 'Sprint Burndown
Charts' which I'll get to later.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Charts' which I'll get to later.
Signed-off-by: Felipe Balbi <balbi@ti.com>
the-sprint.tex | patch | blob | history |
diff --git a/the-sprint.tex b/the-sprint.tex
index a1eded33d576c90c292d286429591d7c5774d41b..039e40d1f288bdc4cdfaa87d05c9c32f6c1df850 100644 (file)
--- a/the-sprint.tex
+++ b/the-sprint.tex
\paragraph{}
The \textit{basic unit of development in Scrum}\cite{wikipediascrum} whose
-duration is pre-defined in advance. All sprints have the same duration and,
-usually, is defined to last between one week and one month.
+duration is pre-defined. All sprints have the same duration, usually between
+one week and one month.
\paragraph{}
In section \ref{sec:sprint-duration} we shall discuss about Sprint Duration and
what is Linux Core Product Development's accepted duration. In the following
section \ref{sec:scrum-process} we shall expose Scrum's development process and
-discuss how to handle an iterative development model while development Linux
+discuss how to handle an iterative development model while developing Linux
Kernel code. Lastly, on section \ref{sec:sprint-burndown-charts} we will expose
the idea of Sprint Burndown Charts; what they are and how to use them.
\paragraph{}
Linux Core Product Development team will use sprint of 2 weeks with no
-exceptions.
+exceptions. This is the most usual choice for beginners in Agile practices and,
+in particular, Scrum.
+
+\paragraph{}
+A 2-week sprint brings two clear benefits:
+
+\begin{enumerate}
+ \item it's a short amount of time.\label{item:short-amount-of-time}
+ \item it's not as short as to cause too few story points to be taken
+ in a given sprint.\label{item:not-too-short}
+\end{enumerate}
+
+\paragraph{}
+Due to item \ref{item:short-amount-of-time}, risk management becomes easy. If
+it turns out a particular sprint isn't successful, we're not loosing a
+considerable amount of work -- only 2 weeks -- and we can easily fix that on
+the next sprint.
+
+\paragraph{}
+\ref{item:not-too-short}, on the other hand, makes it easier to see progress.
+Even though we are focussing on time-boxing our sprints and making them small
+enough as to decrease risks, we can still have a considerable amount of new
+features finished by the end of the sprint which, in turn, gives us the
+oportunity of coming up with good demos.
\section{Scrum Process}
\label{sec:scrum-process}
\label{fig:scrum-process}
\end{figure}
+\paragraph{}
+There a few things to note here. First, when product backlog feeds sprint
+backlogs, they become small, self-contained, estimated tasks which, can be
+finished in the course of one day. This means that on each and every daily
+scrum meeting, \textbf{ideally}, everybody should have an update. Clearly this
+won't always be the case as problems arise.
+
+\paragraph{}
+Second, there are two loops that are carried over during a Scrum development
+effort. The bigger loop is the sprint loop which, in our case, as we shall see,
+will take 2 weeks. The smaller, and perhaps more important, loop is the daily
+scrum.
+
+\paragraph{}
+The daily scrum -- that is, the daily 15 minutes meetings --, is of utmost
+importance for the success of any Scrum development team. It gives developers
+and managers visibility which hasn't been possible before. Such visibility
+leads to roadblocks being solved much quicker which, in turn, leads to
+development flowing smoothly towards the end product.
+
+\paragraph{}
+Third, after each Sprint there should be a \textbf{working} increment of the
+software. The bold face in \textit{working} was purposeful. We can only deliver
+working software inside of Scrum; or at least that will always be the target.
+
+\paragraph{}
+But how can anyone be sure that software is working before customer has access
+to it ? The answer to that question lies in methodical and (hopefully)
+automatic testing. Each task in Scrum should be tied to a companion testcase
+proving that software fails before implementing that task and passes after the
+fact.
+
\section{Sprint Burndown Charts}
\label{sec:sprint-burndown-charts}