diff options
author | Darren Etheridge | 2013-05-14 10:01:21 -0500 |
---|---|---|
committer | Felipe Balbi | 2013-05-15 13:33:22 -0500 |
commit | 9620563efd62f58bc6d36bf15b1e83392b5740c6 (patch) | |
tree | 2e55818a942452a3d0e3e03feddde55ebfacc609 | |
parent | 3290754c07253ee55498635736fef85f47b9db17 (diff) | |
download | ti-agile-manual-9620563efd62f58bc6d36bf15b1e83392b5740c6.tar.gz ti-agile-manual-9620563efd62f58bc6d36bf15b1e83392b5740c6.tar.xz ti-agile-manual-9620563efd62f58bc6d36bf15b1e83392b5740c6.zip |
tamm: terminology: add new terminology section
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>
-rw-r--r-- | terminology.tex | 292 | ||||
-rw-r--r-- | ti-agile-methodology-manual.tex | 1 |
2 files changed, 293 insertions, 0 deletions
diff --git a/terminology.tex b/terminology.tex new file mode 100644 index 0000000..87f1242 --- /dev/null +++ b/terminology.tex | |||
@@ -0,0 +1,292 @@ | |||
1 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% | ||
2 | %% %% | ||
3 | %% Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com %% | ||
4 | %% %% | ||
5 | %% Author: Darren Etheridge detheridge@ti.com %% | ||
6 | %% Portions adapted from http://en.wikipedia.org/wiki/Scrum_(development)%% | ||
7 | %% %% | ||
8 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% | ||
9 | |||
10 | \chapter{Scrum Terminology} | ||
11 | \label{chap:scrumterminology} | ||
12 | |||
13 | Portions Taken directly from Wikipedia | ||
14 | \url{http://en.wikipedia.org/wiki/Scrum\_(development)} | ||
15 | |||
16 | \section{Product Owner} | ||
17 | \label{sec:productowner} | ||
18 | |||
19 | \paragraph{} | ||
20 | The person responsible for maintaining the Product Backlog by | ||
21 | representing the interests of the stakeholders, and ensuring the value | ||
22 | of the work the Development Team does. | ||
23 | |||
24 | \section{ScrumMaster} | ||
25 | \label{sec:scrummaster} | ||
26 | |||
27 | \paragraph{} | ||
28 | The person responsible for the Scrum process, making sure it is used | ||
29 | correctly and maximizing its benefits. | ||
30 | |||
31 | |||
32 | \section{Timebox} | ||
33 | \label{sec:timebox} | ||
34 | |||
35 | \paragraph{} | ||
36 | Fancy Scrum term for a period of time that cannot be exceeded. E.g. a | ||
37 | sprint has a two week timebox. | ||
38 | |||
39 | |||
40 | \section{Development Team} | ||
41 | \label{sec:developmentteam} | ||
42 | |||
43 | \paragraph{} | ||
44 | A cross-functional group of people responsible for delivering | ||
45 | potentially shippable increments of Product at the end of every | ||
46 | Sprint. | ||
47 | |||
48 | \section{Sprint Burndown Chart} | ||
49 | \label{sec:sprintburndownchart} | ||
50 | |||
51 | \paragraph{} | ||
52 | Daily progress for a Sprint over the sprint's length. | ||
53 | |||
54 | \section{Release Burndown Chart} | ||
55 | \label{sec:releaseburndownchart} | ||
56 | |||
57 | \paragraph{} | ||
58 | Sprint level progress of completed stories in the Product Backlog. | ||
59 | |||
60 | \section{Product Backlog} | ||
61 | \label{sec:productbacklog} | ||
62 | |||
63 | \paragraph{} | ||
64 | A prioritized list of high-level requirements. | ||
65 | |||
66 | \section{Sprint Backlog} | ||
67 | \label{sec:sprintbacklog} | ||
68 | |||
69 | \paragraph{} | ||
70 | A prioritized list of tasks to be completed during the sprint. | ||
71 | |||
72 | \section{Sprint} | ||
73 | \label{sec:sprint} | ||
74 | |||
75 | \paragraph{} | ||
76 | A time period (typically 1???4 weeks) in which development occurs on a | ||
77 | set of backlog items that the team has committed to. Also commonly | ||
78 | referred to as a Time-box or iteration. | ||
79 | |||
80 | \section{(User) Story} | ||
81 | \label{sec:story} | ||
82 | |||
83 | \paragraph{} | ||
84 | A feature that is added to the backlog is commonly referred to as a | ||
85 | story and has a specific suggested structure. The structure of a story | ||
86 | is: ``As a \texttt{\char`\<}user type\texttt{\char`\>} I want to | ||
87 | \texttt{\char`\<}do some action\texttt{\char`\>} so that | ||
88 | \texttt{\char`\<}desired result\texttt{\char`\>}'' This is done so | ||
89 | that the development team can identify the user, action and required | ||
90 | result in a request and is a simple way of writing requests that | ||
91 | anyone can understand. Example: As a wiki user I want a tools menu on | ||
92 | the edit screen so that I can easily apply font formatting. A story is | ||
93 | an independent, negotiable, valuable, estimable, small, testable | ||
94 | requirement (``INVEST''). Despite being independent, i.e., they have | ||
95 | no direct dependencies with other requirements, stories may be | ||
96 | clustered into epics when represented on a product roadmap or further | ||
97 | down in the backlog. | ||
98 | |||
99 | \section{Epic} | ||
100 | \label{sec:epic} | ||
101 | |||
102 | \paragraph{} | ||
103 | An epic is a group of related stories, mainly used in product roadmaps | ||
104 | and the backlog for features that have not yet been analyzed enough to | ||
105 | break down into component stories, which should be done before | ||
106 | bringing it into a sprint so to reduce uncertainty. Epics can also be | ||
107 | used at a both program and project level. | ||
108 | |||
109 | \section{Spike} | ||
110 | \label{sec:spike} | ||
111 | |||
112 | \paragraph{} | ||
113 | A time boxed period used to research a concept and/or create a simple | ||
114 | prototype. Spikes can either be planned to take place in between | ||
115 | sprints or, for larger teams, a spike might be accepted as one of many | ||
116 | sprint delivery objectives. Spikes are often introduced before the | ||
117 | delivery of large epics or user stories in order to secure budget, | ||
118 | expand knowledge, and/or produce a proof of concept. The duration and | ||
119 | objective(s) of a spike will be agreed between the Product Owner and | ||
120 | Delivery Team before the start. Unlike sprint commitments, spikes may | ||
121 | or may not deliver tangible, shippable, valuable functionality. For | ||
122 | example, the objective of a spike might be to successfully reach a | ||
123 | decision on a course of action. The spike is over when the time is up, | ||
124 | not necessarily when the objective has been delivered. | ||
125 | |||
126 | \section{Tracer Bullet} | ||
127 | \label{sec:tracebullet} | ||
128 | |||
129 | \paragraph{} | ||
130 | The tracer bullet is a spike with the current architecture, current | ||
131 | technology set, current set of best practices which results in | ||
132 | production quality code. It might just be a very narrow implementation | ||
133 | of the functionality but is not throw away code. It is of production | ||
134 | quality and the rest of the iterations can build on this code. The | ||
135 | name has military origins as ammunition that makes the path of the | ||
136 | weapon visible, allowing for corrections. Often these implementations | ||
137 | are a 'quick shot' through all layers of an application, such as | ||
138 | connecting a single form's input field to the back-end, to prove the | ||
139 | layers will connect as expected. | ||
140 | |||
141 | |||
142 | \section{Story Points} | ||
143 | \label{sec:storypoints} | ||
144 | |||
145 | \paragraph{} | ||
146 | Relates to an abstract point system, used to discuss the difficulty of | ||
147 | the story, without assigning actual hours. The most common scale used | ||
148 | is a rounded Fibonacci sequence (1,2,3,5,8,13,20,40,100), although | ||
149 | some teams use linear scale (1,2,3,4...), powers of two (1,2,4,8...), | ||
150 | and clothes size (XS, S, M, L, XL). | ||
151 | |||
152 | \section{Tasks} | ||
153 | \label{sec:tasks} | ||
154 | |||
155 | \paragraph{} | ||
156 | Added to the story at the beginning of a sprint and broken down into | ||
157 | hours. Each task should not exceed 12 hours, but it's common for teams | ||
158 | to insist that a task take no more than a day to finish. Definition | ||
159 | of Done (DoD) The exit-criteria to determine whether a product backlog | ||
160 | item is complete. In many cases the DoD requires that all regression | ||
161 | tests should be successful. | ||
162 | |||
163 | \section{Velocity} | ||
164 | \label{sec:velocity} | ||
165 | |||
166 | \paragraph{} | ||
167 | The total effort a team is capable of in a sprint. The number is | ||
168 | derived by adding all the story points from the last sprint's | ||
169 | stories/features. This is a guideline for the team and assists them in | ||
170 | understanding how many stories they can do in a sprint. Impediment | ||
171 | Anything that prevents a team member from performing work as | ||
172 | efficiently as possible. | ||
173 | |||
174 | \section{Sashimi} | ||
175 | \label{sec:sashimi} | ||
176 | |||
177 | \paragraph{} | ||
178 | A report that something is "done". The definition of "done" may vary | ||
179 | from one Scrum team to another, but must be consistent within one | ||
180 | team. | ||
181 | |||
182 | \section{Abnormal Termination} | ||
183 | \label{sec:abnormaltermination} | ||
184 | |||
185 | \paragraph{} | ||
186 | The Product Owner can cancel a Sprint if necessary. The Product | ||
187 | Owner may do so with input from the team, ScrumMaster or | ||
188 | management. For instance, management may wish to cancel a sprint if | ||
189 | external circumstances negate the value of the sprint goal. If a | ||
190 | sprint is abnormally terminated, the next step is to conduct a new | ||
191 | Sprint planning meeting, where the reason for the termination is | ||
192 | reviewed. | ||
193 | |||
194 | \section{Planning Poker} | ||
195 | \label{sec:planningpoker} | ||
196 | |||
197 | \paragraph{} | ||
198 | In the Sprint Planning Meeting, the team sits down to estimate its | ||
199 | effort for the stories in the backlog. The Product Owner needs these | ||
200 | estimates, so that he or she is empowered to effectively prioritize | ||
201 | items in the backlog and, as a result, forecast releases based on the | ||
202 | team's velocity. | ||
203 | |||
204 | |||
205 | \section{ScrumBut} | ||
206 | \label{sec:scrumbut} | ||
207 | |||
208 | \paragraph{} | ||
209 | A ScrumBut (or Scrum But) is an exception to the "pure" Scrum | ||
210 | methodology, where a team has changed the methodology to adapt it to | ||
211 | their own needs. | ||
212 | |||
213 | |||
214 | \section{Product Backlog Item (PBI)} | ||
215 | \label{sec:pbi} | ||
216 | |||
217 | \paragraph{} | ||
218 | A product backlog item is any item that the product owner places onto | ||
219 | the product backlog. They are not a one-to-one mapping with user | ||
220 | stories because a PBI could be a bug report or some other item this is | ||
221 | used to build the product vision (i.e. buy a smoking hot build server | ||
222 | for team). | ||
223 | |||
224 | |||
225 | \section{LCPD} | ||
226 | \label{sec:lcpd} | ||
227 | |||
228 | \paragraph{} | ||
229 | Linux Core Product Development - team within the Software Development | ||
230 | Organization of Texas Instruments that is charged with developing the | ||
231 | Linux Kernel for a range of embedded processor devices. The team | ||
232 | follows a model where ``upstreaming'' of all code is expected so that | ||
233 | a user pulling a ``mainline'' kernel will be able to build and run it | ||
234 | on a supported TI platform without obtaining several hundred patches | ||
235 | from TI. | ||
236 | |||
237 | \section{Mainline (Kernel)} | ||
238 | \label{sec:mainline} | ||
239 | |||
240 | \paragraph{} | ||
241 | The ``vanilla'' Linux kernel as released by Linus Torvalds and | ||
242 | available from kernel.org. It is vanilla in the sense that it doesn't | ||
243 | not have/need any addition patches to run. | ||
244 | |||
245 | \section{Upstream(ing)} | ||
246 | \label{sec:upstream} | ||
247 | |||
248 | \paragraph{} | ||
249 | The act of merging source code into the Linux mainline. It takes | ||
250 | effort, dedication and time. Linus and his army of maintainers can be | ||
251 | highly critical of submissions, but they do this because they are | ||
252 | trying to preserve a quality product and maintaining this code in the | ||
253 | future will take effort on their part (especially if it is poorly | ||
254 | written). | ||
255 | |||
256 | By upstreaming code you will reap these benefits: | ||
257 | \begin{itemize} | ||
258 | \item \textbf{Maintainability} - code that is in the mainline kernel | ||
259 | typically moves with the kernel and if things change the kernel | ||
260 | developers will often fix up code that is in the mainline kernel. | ||
261 | If you keep patches external to the kernel, each time a new kernel | ||
262 | is released the patch owner has to go through this process which | ||
263 | is why patches are often locked to a revision of a kernel. | ||
264 | \item \textbf{Ubiquity} - your source code is in every Linux distribution, it | ||
265 | just runs when somebody buys a TI board with no special or magic | ||
266 | software needed. | ||
267 | \item \textbf{Quality Control} - The community and maintainers can be brutal | ||
268 | in reviewing code, but this also makes for code that works better | ||
269 | and is easier maintained. Potentially a lot of eyes will look at | ||
270 | code before it makes it into the Linux mainline kernel so there is | ||
271 | more scope to spot design flaws or coding errors than if you keep | ||
272 | your patches closed. | ||
273 | \end{itemize} | ||
274 | |||
275 | |||
276 | \section{Technical Debt} | ||
277 | \label{sec:technicaldebt} | ||
278 | |||
279 | \paragraph{} | ||
280 | A technical debt is used to describe work items that really need to be | ||
281 | done before a job can be considered complete. A technical debt can be | ||
282 | generated by a variety of factors but an all too common source is | ||
283 | ``business pressure'' where something is released before it is really | ||
284 | ready so as not to miss a prerceived market window. All too often | ||
285 | what really is a prototype is released as a finished product, when it | ||
286 | is architecturally immature and lacks testing and documentation. Like | ||
287 | any kind of debt, there comes a point where you are going to repay, | ||
288 | and the costs of a technical debt is often much higher than if it was | ||
289 | avoided in the first place i.e. forced to rearchitect code to add a | ||
290 | seemingly trivial feature but forced to retain complete backward | ||
291 | compatability because customers have already invested heavily in the | ||
292 | original design. | ||
diff --git a/ti-agile-methodology-manual.tex b/ti-agile-methodology-manual.tex index 5545b0e..ca08f18 100644 --- a/ti-agile-methodology-manual.tex +++ b/ti-agile-methodology-manual.tex | |||
@@ -64,6 +64,7 @@ | |||
64 | \mainmatter | 64 | \mainmatter |
65 | \pagenumbering{arabic} | 65 | \pagenumbering{arabic} |
66 | \input{introduction.tex} | 66 | \input{introduction.tex} |
67 | \input{terminology.tex} | ||
67 | \input{scope.tex} | 68 | \input{scope.tex} |
68 | \input{scrum.tex} | 69 | \input{scrum.tex} |
69 | \input{roles-in-scrum.tex} | 70 | \input{roles-in-scrum.tex} |