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 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   8
   9 \chapter{Introduction}
  10 \label{chap:introduction}
  11
  12 \section{Welcome}
  13 \label{sec:welcome}
  14
  15 \paragraph{}
  16 Welcome to \textit{Linux Core Product Development}'s Agile Methodology Manual.
  17 Here you will find enough information to get acquainted with our development
  18 process and also learn a bit of history about the team.
  19
  20 \paragraph{}
  21 We have decided to implement
  22 \href{http://en.wikipedia.org/wiki/Scrum\_(development)}{Scrum} for Linux
  23 Kernel development as means to improve our deliveries and decrease the amount
  24 of rework necessary due to Software errors.
  25
  26 \paragraph{}
  27 It's uncommon for Linux Kernel engineers to implement any Software Development
  28 Methodology at all, however the enterprise development environment needs
  29 visibility on feature readiness. The Agile Methodologies seem to impose the
  30 least amount of process overhead to engineers, which gives the team maximum
  31 amount of engineering hours and decreases the amount of time wasted in phone
  32 calls and meetings.
  33
  34 \paragraph{}
  35 This document aims at setting up a few foundations for the team in order to
  36 have a general agreement on the deployment of
  37 \href{http://en.wikipedia.org/wiki/Scrum\_(development)}{Scrum} to decrease
  38 the amount of rework when developing features for customers and the mainline
  39 Linux Kernel tree.
  40
  41 \section{Document Organization}
  42 \label{sec:document-organization}
  43
  44 \paragraph{}
  45 In chapter \ref{chap:scope} we will define the scope of this document. Why is
  46 it needed and who's going to use it.
  47
  48 \paragraph{}
  49 Chapter \ref{chap:roles-in-scrum} will discuss about the three roles within a
  50 Scrum Team. What they are, what are their responsibilities, how they should
  51 communicate with each other.
  52
  53 \paragraph{}
  54 A thorough discussion about the Sprint will be carried out throughout chapter
  55 \ref{chap:the-sprint}. We will look at sprint duration, process, artifacts and
  56 more.
  57
  58 \paragraph{}
  59 A discussion about how to break tasks into small pieces will be exposed in
  60 chapter \ref{chap:breaking-tasks-up}. We will learn tricks which will help us
  61 understand how to break e.g. \textit{Development of QSPI driver} into smaller,
  62 bite-sized pieces which can done in the course of one sprint.
  63
  64 \paragraph{}
  65 After being able to break tasks into small pieces, we need to come up with
  66 proper estimates (in hours) in order to have an idea of how long a certain task
  67 will take in order to be completed. Such discussion is left for chapter
  68 \ref{chap:estimating} and will be as thorough as possible while analyzing a
  69 ficticious scenario.
  70
  71 \paragraph{}
  72 Lastly, chapter \ref{chap:definition-of-done} will put forth our
  73 \textit{Definition of Done} which will be used by all scrum teams. A global
  74 definition of done helps us increase quality by helping team members becoming
  75 more methodical about testing and validation.
  76
  77 \paragraph{}
  78 We hope our readers have lots of fun while reading this manual and implementing
  79 it on daily job.