tamm: terminology: add new terminology section
authorDarren Etheridge <detheridge@ti.com>
Tue, 14 May 2013 15:01:21 +0000 (10:01 -0500)
committerFelipe Balbi <balbi@ti.com>
Wed, 15 May 2013 18:33:22 +0000 (21:33 +0300)
This covers most of the basic keyworks for Scrum along with some more
LCPD specific items such as mainline / upstream, etc.

Signed-off-by: Darren Etheridge <detheridge@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
terminology.tex [new file with mode: 0644]
ti-agile-methodology-manual.tex

diff --git a/terminology.tex b/terminology.tex
new file mode 100644 (file)
index 0000000..87f1242
--- /dev/null
@@ -0,0 +1,292 @@
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%                                                                       %%
+%% Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com %%
+%%                                                                       %%
+%% Author: Darren Etheridge detheridge@ti.com                            %%
+%% Portions adapted from http://en.wikipedia.org/wiki/Scrum_(development)%%
+%%                                                                       %%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\chapter{Scrum Terminology}
+\label{chap:scrumterminology}
+
+Portions Taken directly from Wikipedia
+\url{http://en.wikipedia.org/wiki/Scrum\_(development)}
+
+\section{Product Owner}
+\label{sec:productowner}
+
+\paragraph{}
+The person responsible for maintaining the Product Backlog by
+representing the interests of the stakeholders, and ensuring the value
+of the work the Development Team does.
+
+\section{ScrumMaster}
+\label{sec:scrummaster}
+
+\paragraph{}
+The person responsible for the Scrum process, making sure it is used
+correctly and maximizing its benefits.
+
+
+\section{Timebox}
+\label{sec:timebox}
+
+\paragraph{}
+Fancy Scrum term for a period of time that cannot be exceeded.  E.g. a
+sprint has a two week timebox.
+
+
+\section{Development Team}
+\label{sec:developmentteam}
+
+\paragraph{}
+A cross-functional group of people responsible for delivering
+potentially shippable increments of Product at the end of every
+Sprint.
+
+\section{Sprint Burndown Chart}
+\label{sec:sprintburndownchart}
+
+\paragraph{}
+Daily progress for a Sprint over the sprint's length.
+
+\section{Release Burndown Chart}
+\label{sec:releaseburndownchart}
+
+\paragraph{}
+Sprint level progress of completed stories in the Product Backlog.
+
+\section{Product Backlog}
+\label{sec:productbacklog}
+
+\paragraph{}
+A prioritized list of high-level requirements.
+
+\section{Sprint Backlog}
+\label{sec:sprintbacklog}
+
+\paragraph{}
+A prioritized list of tasks to be completed during the sprint.
+
+\section{Sprint}
+\label{sec:sprint}
+
+\paragraph{}
+A time period (typically 1???4 weeks) in which development occurs on a
+set of backlog items that the team has committed to. Also commonly
+referred to as a Time-box or iteration.
+
+\section{(User) Story}
+\label{sec:story}
+
+\paragraph{}
+A feature that is added to the backlog is commonly referred to as a
+story and has a specific suggested structure. The structure of a story
+is: ``As a \texttt{\char`\<}user type\texttt{\char`\>} I want to
+\texttt{\char`\<}do some action\texttt{\char`\>} so that
+\texttt{\char`\<}desired result\texttt{\char`\>}'' This is done so
+that the development team can identify the user, action and required
+result in a request and is a simple way of writing requests that
+anyone can understand. Example: As a wiki user I want a tools menu on
+the edit screen so that I can easily apply font formatting. A story is
+an independent, negotiable, valuable, estimable, small, testable
+requirement (``INVEST''). Despite being independent, i.e., they have
+no direct dependencies with other requirements, stories may be
+clustered into epics when represented on a product roadmap or further
+down in the backlog.
+
+\section{Epic}
+\label{sec:epic}
+
+\paragraph{}
+An epic is a group of related stories, mainly used in product roadmaps
+and the backlog for features that have not yet been analyzed enough to
+break down into component stories, which should be done before
+bringing it into a sprint so to reduce uncertainty. Epics can also be
+used at a both program and project level.
+
+\section{Spike}
+\label{sec:spike}
+
+\paragraph{}
+A time boxed period used to research a concept and/or create a simple
+prototype. Spikes can either be planned to take place in between
+sprints or, for larger teams, a spike might be accepted as one of many
+sprint delivery objectives. Spikes are often introduced before the
+delivery of large epics or user stories in order to secure budget,
+expand knowledge, and/or produce a proof of concept. The duration and
+objective(s) of a spike will be agreed between the Product Owner and
+Delivery Team before the start. Unlike sprint commitments, spikes may
+or may not deliver tangible, shippable, valuable functionality. For
+example, the objective of a spike might be to successfully reach a
+decision on a course of action. The spike is over when the time is up,
+not necessarily when the objective has been delivered.
+
+\section{Tracer Bullet}
+\label{sec:tracebullet}
+
+\paragraph{}
+The tracer bullet is a spike with the current architecture, current
+technology set, current set of best practices which results in
+production quality code. It might just be a very narrow implementation
+of the functionality but is not throw away code. It is of production
+quality and the rest of the iterations can build on this code. The
+name has military origins as ammunition that makes the path of the
+weapon visible, allowing for corrections. Often these implementations
+are a 'quick shot' through all layers of an application, such as
+connecting a single form's input field to the back-end, to prove the
+layers will connect as expected.
+
+
+\section{Story Points}
+\label{sec:storypoints}
+
+\paragraph{}
+Relates to an abstract point system, used to discuss the difficulty of
+the story, without assigning actual hours. The most common scale used
+is a rounded Fibonacci sequence (1,2,3,5,8,13,20,40,100), although
+some teams use linear scale (1,2,3,4...), powers of two (1,2,4,8...),
+and clothes size (XS, S, M, L, XL).
+
+\section{Tasks}
+\label{sec:tasks}
+
+\paragraph{}
+Added to the story at the beginning of a sprint and broken down into
+hours. Each task should not exceed 12 hours, but it's common for teams
+to insist that a task take no more than a day to finish.  Definition
+of Done (DoD) The exit-criteria to determine whether a product backlog
+item is complete. In many cases the DoD requires that all regression
+tests should be successful.
+
+\section{Velocity}
+\label{sec:velocity}
+
+\paragraph{}
+The total effort a team is capable of in a sprint. The number is
+derived by adding all the story points from the last sprint's
+stories/features. This is a guideline for the team and assists them in
+understanding how many stories they can do in a sprint.  Impediment
+Anything that prevents a team member from performing work as
+efficiently as possible.
+
+\section{Sashimi}
+\label{sec:sashimi}
+
+\paragraph{}
+A report that something is "done". The definition of "done" may vary
+from one Scrum team to another, but must be consistent within one
+team.
+
+\section{Abnormal Termination}
+\label{sec:abnormaltermination}
+
+\paragraph{}
+The Product Owner can cancel a Sprint if necessary. The Product
+Owner may do so with input from the team, ScrumMaster or
+management. For instance, management may wish to cancel a sprint if
+external circumstances negate the value of the sprint goal. If a
+sprint is abnormally terminated, the next step is to conduct a new
+Sprint planning meeting, where the reason for the termination is
+reviewed.
+
+\section{Planning Poker}
+\label{sec:planningpoker}
+
+\paragraph{}
+In the Sprint Planning Meeting, the team sits down to estimate its
+effort for the stories in the backlog. The Product Owner needs these
+estimates, so that he or she is empowered to effectively prioritize
+items in the backlog and, as a result, forecast releases based on the
+team's velocity.
+
+
+\section{ScrumBut}
+\label{sec:scrumbut}
+
+\paragraph{}
+A ScrumBut (or Scrum But) is an exception to the "pure" Scrum
+methodology, where a team has changed the methodology to adapt it to
+their own needs.
+
+
+\section{Product Backlog Item (PBI)}
+\label{sec:pbi}
+
+\paragraph{}
+A product backlog item is any item that the product owner places onto
+the product backlog.  They are not a one-to-one mapping with user
+stories because a PBI could be a bug report or some other item this is
+used to build the product vision (i.e. buy a smoking hot build server
+for team).
+
+
+\section{LCPD}
+\label{sec:lcpd}
+
+\paragraph{}
+Linux Core Product Development - team within the Software Development
+Organization of Texas Instruments that is charged with developing the
+Linux Kernel for a range of embedded processor devices.  The team
+follows a model where ``upstreaming'' of all code is expected so that
+a user pulling a ``mainline'' kernel will be able to build and run it
+on a supported TI platform without obtaining several hundred patches
+from TI.
+
+\section{Mainline (Kernel)}
+\label{sec:mainline}
+
+\paragraph{}
+The ``vanilla'' Linux kernel as released by Linus Torvalds and
+available from kernel.org.  It is vanilla in the sense that it doesn't
+not have/need any addition patches to run.
+
+\section{Upstream(ing)}
+\label{sec:upstream}
+
+\paragraph{}
+The act of merging source code into the Linux mainline.  It takes
+effort, dedication and time.  Linus and his army of maintainers can be
+highly critical of submissions, but they do this because they are
+trying to preserve a quality product and maintaining this code in the
+future will take effort on their part (especially if it is poorly
+written).
+
+By upstreaming code you will reap these benefits:
+\begin{itemize}
+       \item \textbf{Maintainability} - code that is in the mainline kernel
+               typically moves with the kernel and if things change the kernel
+               developers will often fix up code that is in the mainline kernel.
+               If you keep patches external to the kernel, each time a new kernel
+               is released the patch owner has to go through this process which
+               is why patches are often locked to a revision of a kernel.
+       \item \textbf{Ubiquity} - your source code is in every Linux distribution, it
+               just runs when somebody buys a TI board with no special or magic
+               software needed.
+       \item \textbf{Quality Control} - The community and maintainers can be brutal
+               in reviewing code, but this also makes for code that works better
+               and is easier maintained.  Potentially a lot of eyes will look at
+               code before it makes it into the Linux mainline kernel so there is
+               more scope to spot design flaws or coding errors than if you keep
+               your patches closed.
+\end{itemize}
+
+
+\section{Technical Debt}
+\label{sec:technicaldebt}
+
+\paragraph{}
+A technical debt is used to describe work items that really need to be
+done before a job can be considered complete.  A technical debt can be
+generated by a variety of factors but an all too common source is
+``business pressure'' where something is released before it is really
+ready so as not to miss a prerceived market window.  All too often
+what really is a prototype is released as a finished product, when it
+is architecturally immature and lacks testing and documentation.  Like
+any kind of debt, there comes a point where you are going to repay,
+and the costs of a technical debt is often much higher than if it was
+avoided in the first place i.e. forced to rearchitect code to add a
+seemingly trivial feature but forced to retain complete backward
+compatability because customers have already invested heavily in the
+original design.
index 5545b0eced3011b4c2532d27634a9385b38aa636..ca08f184e48bb94a56ea3c51cbdbc21f47efe1a4 100644 (file)
@@ -64,6 +64,7 @@
 \mainmatter
 \pagenumbering{arabic}
 \input{introduction.tex}
+\input{terminology.tex}
 \input{scope.tex}
 \input{scrum.tex}
 \input{roles-in-scrum.tex}