summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: ab4602a)
raw | patch | inline | side by side (parent: ab4602a)
author | Chase Maupin <chase.maupin@ti.com> | |
Fri, 12 Apr 2013 15:02:01 +0000 (10:02 -0500) | ||
committer | Felipe Balbi <balbi@ti.com> | |
Fri, 12 Apr 2013 15:13:31 +0000 (18:13 +0300) |
* Some changes look larger because of enforcing 80 character
limits.
Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
limits.
Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
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 a8cb2a23b5323dc1142fa0cba9694cd3a6c0777a..4654cb1d3717570f6a19e302124f6e5062d9ea31 100644 (file)
--- a/the-sprint.tex
+++ b/the-sprint.tex
\label{sec:sprint-duration}
\paragraph{}
\label{sec:sprint-duration}
\paragraph{}
-Linux Core Product Development team will use sprint of 2 weeks with no
-exceptions. This is the most usual choice for beginners in Agile practices and,
-in particular, Scrum.
+Linux Core Product Development team will use a sprint duration of 2 weeks with
+no exceptions. This is the most common choice for beginners in Agile practices
+and, in particular, Scrum.
\paragraph{}
A 2-week sprint brings two clear benefits:
\begin{enumerate}
\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
+ \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}
in a given sprint.\label{item:not-too-short}
\end{enumerate}
the next sprint.
\paragraph{}
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.
+Item \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
+opportunity of coming up with good demos.
\section{Scrum Process}
\label{sec:scrum-process}
\paragraph{}
Figure \ref{fig:scrum-process} shows Scrum's process. Note that development is
\section{Scrum Process}
\label{sec:scrum-process}
\paragraph{}
Figure \ref{fig:scrum-process} shows Scrum's process. Note that development is
-carried away as a loop.
+performed in a set of continuous feedback loops.
\begin{figure}[ht]
\centering
\begin{figure}[ht]
\centering
\paragraph{}
But how can anyone be sure that software is working before customer has access
\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
+to it? The answer to that question lies in methodical and (hopefully)
+automated 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.
proving that software fails before implementing that task and passes after the
fact.