life-cycle-of-story: Add creation of upstream stories
[ti-agile-manual/ti-agile-manual.git] / introduction.tex
1 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
2 %%                                                                       %%
3 %% Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com %%
4 %%                                                                       %%
5 %% Author: Felipe Balbi <balbi@ti.com>                                   %%
6 %%                                                                       %%
7 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
9 \chapter{Introduction}
10 \label{chap:introduction}
12 \paragraph{}
13 Welcome to \textit{Linux Core Product Development}'s Agile Methodology Manual.
14 Here you will find enough information to get acquainted with our development
15 process and also learn a bit of history about the team.
17 \paragraph{}
18 We have decided to implement
19 \href{http://en.wikipedia.org/wiki/Scrum\_(development)}{Scrum} for Linux
20 Kernel development as means to improve our deliveries and decrease the amount
21 of rework necessary due to Software errors.
23 \paragraph{}
24 It's uncommon for Linux Kernel engineers to implement any Software Development
25 Methodology at all, however the enterprise development environment needs
26 visibility on feature readiness. The Agile Methodologies seem to impose the
27 least amount of process overhead to engineers, which gives the team maximum
28 amount of engineering hours and decreases the amount of time wasted in phone
29 calls and meetings.  An additional advantage of Scrum is that developers
30 are given focused time within each Sprint to accomplish their tasks without
31 being re-assigned or re-prioritized.  Customer support efforts are prioritized
32 as part of the common backlog and not as interrupts.  The Sprint concept is
33 discussed more in chapter \ref{chap:the-sprint}.
35 \paragraph{}
36 This document aims at setting up a few foundations for the team in order to
37 have a general agreement on the deployment of
38 \href{http://en.wikipedia.org/wiki/Scrum\_(development)}{Scrum} to decrease
39 the amount of rework when developing features for customers and the mainline
40 Linux Kernel tree.
42 \paragraph{}
43 This book is organized as follows. In chapter \ref{chap:scrumterminology} we
44 will go through a few terms that we want everybody to understand the same way
45 we do.
47 \paragraph{}
48 Later in chapter \ref{chap:scope} we will define the scope of this document.
49 Why is it needed and who's going to use it.
51 \paragraph{}
52 An in-depth description of Scrum is available on chapter \ref{chap:scrum}. We
53 will look at traditional Scrum practices, what Scrum is, the daily scrum, etc.
54 Note, however, that Scrum is a management process and it needs a companion
55 engineering process such as Continuous Integration, Test-Driven Development,
56 and many, many others.
58 \paragraph{}
59 Chapter \ref{chap:roles} will discuss about the three roles within a
60 Scrum Team. What they are, what are their responsibilities, how they should
61 communicate with each other.
63 \paragraph{}
64 On chapter \ref{chap:meetings} we will take a look at Scrum meetings. How many
65 are there, how they should be used, how long do they take. All such questions
66 will be answered on that chapter.
68 \paragraph{}
69 A thorough discussion about the Sprint will be carried throughout chapter
70 \ref{chap:the-sprint}. We will look at sprint duration, process, artifacts and
71 more.
73 \paragraph{}
74 A discussion about how to break tasks into small pieces will be
75 exposed in chapter \ref{chap:work-breakdown}.  We will learn tricks
76 which will help us understand how to break work items
77 (eg. \textit{Implement an error management system} into smaller,
78 bite-sized pieces that can be done in the course of one sprint.
80 \paragraph{}
81 After being able to break tasks into small pieces, we need to come up with
82 proper estimates (in hours) in order to have an idea of how long a certain task
83 will take in order to be completed. Such discussion is left for chapter
84 \ref{chap:estimating} and will be as thorough as possible while analyzing a
85 ficticious scenario.
87 \paragraph{}
88 Lastly, chapter \ref{chap:definition-of-done} will put forth our
89 \textit{Definition of Done} which will be used by all scrum teams. A global
90 definition of done helps us increase quality by helping team members becoming
91 more methodical about testing and validation.
93 \paragraph{}
94 We hope our readers have lots of fun while reading this manual and implementing
95 it in their daily job.