Co-PilotusingagilemethodstolandITprojectssmoothly

Allrightsreserved.Citationofthecontentsonlywithapprovaloftheeditor.CC-BY-NC-ND(Work),CC-BY-SA(Contents)

©2014byComergeAG,Switzerland

ImpressumManagingEditor:

TillBayComergeAGBubenbergstrasse18045ZurichSwitzerland

Tel:+41435013838Fax:+41435013839

Email:till.bay@comerge.net

AssociateEditors:

BennoBaumgartnerMatthiasHüniMichelaPedroniEvaJutzeler

LayoutandArtwork:

EvaJutzeler

Publisher:

buch&netz,Zürichhttp://buchundnetz.com

Thisbookisavailableasprintorebook:

ISBN978-3-03805-035-3(Print)ISBN978-3-03805-101-5(PDF)ISBN978-3-03805-102-2(ePub)ISBN978-3-03805-103-9(mobi)

PrefacetothefirsteditionTherearemanybooksonagilemethodsandsoftwaredevelopmentbestpracticesavailabletoday.Sowhywriteanotherbookonthetopic?

There are a number of reasons: First of all, we do not believe in taking a book andfollowingitwordforword.Werathertrustinactionanddailypractice.Thebookyouareholdinginyourhandsdescribesasetofprocesspatternsthathaveworkedwellforusinthepast.Byconstantlyremixingandimprovingthem,weensurethattheycontinuetofitthe needs of our evolving company. In fact, the Co-Pilot includes a framework foradaptingtheprocesstochanges,thusdrivingitfurtheraswewrite.Hence,thisbookdoesnot describe a specificmenu to cook in the software kitchen, but it describes a list ofingredientsandspicesthatcanbemixedandmatched.

Thesecondreasonforturningourpracticesintowrittenformis:theideasdescribedintheCo-Pilotmaybereusedbyothercompaniesinotherenvironmentsapplyingasimilarmixand match approach. The way of working defines and significantly influences acompany’sculture,but itcanonlybecomeculture ifyouareconvincedof thepractices.We hope that the processes and methods described in the Co-Pilot will entice you tochoosesomeandinventyourownflavorofanagilesoftwaredevelopmentprocesstobeimplemented at your company. The name of this book—Co-Pilot—reflects this idea. Itservesasguidanceandinspirationandprovidesinputs,butyouremainthepilotincharge.

The processes and ideas that the Co-Pilot describes have roots in the history of ourcompany,Comerge.Comerge grew in its first tenmonths from four employees to overtwenty. During this rapid evolution, we were confronted with various managerial andtechnologicalchallenges.

Coming to a slowergrowthpace in recentmonths (wearenowalmost threeyearsold)motivatedus to lookback and identify the ideas that helpedusmaster these challengeswhilestillsatisfyingtheneedsofourcustomers.Manyoftheseideashavetheirrootsinour experience as employees or co-workers of inspiring proponents of agile softwaremethods:BennoBaumgartnerandTillBayhaveworkedatErichGamma’slab,fiveofusworked for BertrandMeyer at the Chair of Software Engineering at ETH Zurich, andothershavemanagedoutsourcingprojectswithprogrammers located inEasternEurope.TheCo-Pilotcollectstheseexperiencesandthebestpracticesofourpastandpresent.

Wehopethatyouenjoythereadandthat it inspiresyoutoputsomeof it intoactionatyourcompany.

We would like to thank the following people for making this book possible: DanielaBomatter,JulianTschannen,GeraldinevonRoten,andUrsDoennifortheirreviewsofthedrafts, Eva Jutzeler for her fantastic layout and drawings, and all our customers andemployeesfor theirconstantsupportandencouragement.Youaregreatand togetherwemaketheshippingofhighqualitysoftwarehappenandsafelylandagilesoftwareprojects.

November2010

Till Bay, Bernd Schoeller, Benno Baumgartner, Beat Herlig, Dennis Rietmann, andMichelaPedroni

PrefacetothesecondeditionA lot has happened since the first edition of theCo-Pilot cameout inNovember 2010:Comergehascelebrateditsfifthbirthdayandlookingbackatthelasttwoyears,Comergehasundergoneanevolutioninvariousareas.

Firstofall,wearehappytohavegainedmanynewtalentedandmotivatedComergersascolleagues.Thishasmeantforusthatnewideas,expectations,andneedshaveenteredourcompanylifeandhelpedshapewhatComergeistoday.Atthesametime,companygrowthhas put us up againstmanagerial and organizational challenges,which theCo-Pilot hashelpedushandle.ThesenewchallengeshavealsoleadtochangesintheCo-Pilotthat—whereneeded—wehaveadaptedtofitourneeds.

Secondly,we are proud of the going live of several large projects (themost prominentbeingtheMobilityproject,livesinceOctober2011).HavingsafelylandedthesesoftwareprojectshasaffirmedthevalueoftheCo-Pilotandstrengthensourbeliefinfollowingitsprocesseswhilecontinuouslyadvancingitsprinciplesasthecompany,theteam,andourprojectsevolve.

Thirdly,wehavemovedthetoolsupportfortheCo-PilotprocessfromOrigotoJIRAandhave startedusingGit insteadofSVNfor certainprojects.These technological changeshaverenderedsomeofthecontentsoftheCo-Pilot’sfirsteditionoutdatedandresultedinadaptations to theprocessdescriptionsandextensionsdetailing thepeculiaritiesof thesetools.

Allofthesedevelopmentshaveeffectsonhowweworkandtostayabreastofchanges,itishightimetobringoutasecondeditionoftheCo-Pilot!WehopeyouwillfindtheCo-Pilotinterestingandhelpful.

We would like to thank all our customers and employees for their loyalty, trust andcommitment to jointly developing high quality software.A special thanks goes toBeatFluri and Jonas Zuberbühler for the process descriptions they provided and to PatrickFerrarelli for his hints on book typesetting that have found their way into this secondeditionofthebook.

May2013

TillBay,EvaJutzeler,MichelaPedroni,BennoBaumgartner,andSaraBrigatti

PrefacetotheebookeditionAs agilemethods evolve, this book should do aswell. Handheld devices have becomeconvenienttoolstoreadandwatchdigitalcontentsowedecidedtogettheCo-Pilotreadyfor these devices. Matthias took care of the transformation process from preformattedHTML(generatedbyAdobeCS)tosimplifiedandcleanebook-readysources.

WearealsohappytoannouncethattheCo-PilotwillbepublishedbyZurichbased“buch& netz”. You may order the book as print or ePub / MOBI / PDFonhttp://buchundnetz.com.

June2014

TillBay,MatthiasHüni

OurvaluesGrowingrevenueandcuttingdownoncostsisakeytopicforsuccessfulbusinessesandcorporategoals areoften stated in financial terms.Butgoals that arepurely focusedongains may lead to opportunistic and unethical behavior. Recent newspapers are full ofexamples—insider trading, bribery, invasion of privacy—just to name a few. In somecases,thisevenresultsinthedownfallofemployeesortheentirecompany.

Createabusinesswecanbeproudof

Comergeisasinterestedinmakingprofitasanyothercompany.Butourvisionisalsotobeable to lookback20years fromnowand feelpride for thecompany thatwehelpedshape.Wewanttostandbehindtheethicalprinciplesitrepresentsandtheactionsthatwehavetakenthroughoutthecompany’shistory.

Thisiswhereourvaluescomein.Theygovernourstrategiesandhelpusmaketherightdecisionswhen short-termprofit or otherpressures enticeus to take awrongpath.Ourvaluesrepresentourcoreideologiesandarenon-negotiableprinciples.

Wehavecapturedourviews in fivestatements,eachreflectingwhoweare,howwedobusiness,andwhatwewanttofocuson.

TheComergeValuesBecurious

WefoundedComerge,becausewewantedtoknowwhatitmeanstohaveacompany.Notmuchhaschanged.Wechaseeveryopportunitytolearnsomethingnew–whereverwegoandwhomeverwetalkto.Weareinterestedinideasandviewsofothers:whenwespeaktoourcustomers, tousers, tocolleaguesatwork,or toour friends.Wearecreativeandchallengethestatusquo.Wearecurious,butweneverloosetrackofthegoals.

Becommercial

Weareacommercialbusiness.Hence,creatinggrowthandprofitforusandourcustomersiscentral.Weneedtobetough,butatthesametimefair.Wethinkclearly,actdecisively,andneverloosetrackofthetoppriorities.Wearecommercial,butwearealsoethical.

Beresponsible

Weknowwhattherightthingtodoisandwedoit.Weareconsciousoftheconsequencesofouractions,inboththeshortandthelongterm.Wetrytoleavethingsalittlebetterthanwefindthem,andweencourageothers to joinus in thisendeavor.Weappreciate ifourcolleaguesgoaheadandtakeresponsibilityforwhattheydoandwetrytofollowsuitandbeequallyproactiveinourdailydecisions.

Beengineering

Wewanttodowhatwedobetterthananyoneelse,andhavefundoingit.Andwhatwedobest is engineering. People count on our software and they trust us to build the bestsoftware possible.Wedo that becausewe are engineers at heart.Wedo not build half-bakedsoftware.

Beevolving

Withourfeedbacktoothers,withourworkguidedbyourvalues,bysimplylivingonthisplanet,weconstantlyseechange.Wevaluerespondingtochangemorethanfollowingaplan. Things never staywhat they are and by embracing change and evolving togetherwiththeworldaroundus,wecreateacompetitiveadvantageforourcustomersandamoreexcitinglifeforourselves.

HowtoreadThisbookdescribesanagilesoftwaredevelopmentprocess.Itreliesonthreecornerstones:thekeyprocessroles,aspecificiterationsetup,andthenotionofissues.Theprocessrolesdefinethehierarchicalstructureofstakeholderswithinaproject.Theyalsodeterminetheduties that the stakeholders have during a project and how they interact. The duties ofstakeholders result in tasks that theyworkon,which in the endwill lead to a softwareproduct.These tasks are captured in issues.The iterationsetup controlswhen and howissuesarehandled.Everyprojectisbasedonasequenceofiterationswithafixedlength(usually 5 weeks). At the end of each iteration (the milestone), the development teamprovidesareleasetothecustomer.

The rest of this book shows how these notions can be put to practice and describesprocesses to successfully land a software projectwith the help of theCo-Pilot.Tohelpnavigatethroughthedifferentchapters,wehavedividedthebookintofourparts:

Projects: This part describes all the processes revolving around the planning ofprojects, handling of issues, and organization of iterations. It also provides moredetailed informationonhow issues shouldbe reviewed,howweuse thebranchinginfrastructure ofGit to support this task, andwhatwe expect fromour employeesconcerningthetrackingoftheirtime.Meetings:Following theprocessesof theCo-Pilot, severalmeetings regularly takeplaceduringaniteration(e.g.,theretrospectivemeetingorthedailyScrummeeting).TheMeetingspartoftheCo-Pilotdetailsonthesetupandagendaofthesemeetings.Testing: Testing is a crucial activity when targeting the goal of delivering highquality software. Thus, the various testing practices are shown in this part of thebook.Customers:Agilesoftwaredevelopmententailsahighdegreeofinvolvementofthecustomer. This part of the book describes best practices when collaborating withcustomers and showshow toprovide support services to customers after aproducthasgonelive.

Notestothereader

Manyof the termsused in this bookhave very specificmeanings in the context of theprocess framework that the Co-Pilot describes. The glossary at the end of the bookprovidesdefinitionsofthetermsandweaskyoutorefertoit.

The book uses “he” and “she” interchangeably.Both pronouns alwaysmean to includemalesandfemales.Tomakereadingeasier,weconsistentlyusedthefemalepronounforcertainprocessrolesandthemalepronounforothers.

Projects

ProcessrolesOur softwaredevelopmentprocess is basedon the four roles: teammember, team lead,productmanager,andcustomer.

Teammember

Themainactivityofateammemberistoresolveissues.Issuescapturethingstodo.Theyaresufficientlysmallgrained tobesolved ina short time frame(usually takingatmostone day). Issues result from bug reports or enhancement wishes. Every issue can beassignedtoaspecificteammember,whothenisresponsibleforresolvingit(seeHowtoworkwithissuesformoreinformationonissues).Theteammembersofacompanymayhaveanyprofessionalbackground(e.g.,designers,marketingagents,assistants,educationspecialists),butinasoftwarecompanymostofthemwillprobablybesoftwareengineers.Asoftwaredevelopingteammemberownsaclearlydefinedportionofthecode.Asacodeowner,sheisresponsibleforhercodeandexpectedtobetheexpert.

Teamlead

Theteamleadcommunicateswithotherteamsandtheproductmanager.Heisresponsiblefor assigning issues to his teammembers and for planning an iteration. The team leadshould always know what his team members are working on and when they will befinished.Hemayredistributeworkamongthemandthusbalancetheworkloadevenly.Itistheteamlead’sresponsibilitythathisteamachievesthegoalsofaniteration.Theteamleadreportsthestatus(green,yellow,red)oftheiterationduringtheweeklycoremeeting.Theteamleadisalsoateammember.

Productmanager

Theproductmanager is responsible for theentireproduct.Shegathers the requirementsfromthecustomerandcommunicatestheserequirementstotheteamleadsbyusinguserstoriesandenhancements.Shemakessurethattheteamsimplementtheenhancementsasexpected.Hergoalistofindouthowtosatisfytheneedsofthecustomerwhiletakingintoaccounttheresourcesoftheteams.Theproductmanagerkeepsanoverviewofallteamsand directs their work towards one common goal. Ideally, the product manager is abusinessmanagerwithatechnicalbackground,andsometimes,sheisanemployeeofthecustomer.

Customer

Oneimportantgoaloftheprocessistosatisfythecustomer.Inreturn,thecustomerpaysthebill.Usually,thereisonepersonappointedascustomerrepresentative.Thispersonisanemployeeofthecustomerandhastwomainduties:

1. Hecontinuouslyobservestheprogressoftheproductdevelopmentandensuresthatitisontrack.

2. Heprotectstheprojectteamsagainstinternalcustomerpoliticsandactsasachanneltocommunicatecustomerdecisions.

If the customer representative is notwillingornot capableof fulfillingbothduties, theproductmanagertriestofillthegapandsupportsthecustomerrepresentative.Ifthisfails,theproductdevelopmentmaybe carriedout, but it is unlikely that theCo-Pilotwill beable to deliver a product that matches the needs of the customer. Another process orcustomershouldbeconsideredinthiscase.

HowtoplanaprojectAprojectisanendeavorundertakentobringanideatolifebycreatingauniqueproduct.Insuchasetting,changeshappenfrequently–thus,itisimportanttoidentifyandplanthefundamentalsoftheprojectthatremainstable.

Definegoalsandprinciples

Whatisthegoalofyourproject?TheproductmanagercreatesaprojectworkspaceontheIntranetandusesitto:

Clarifythefocus.Thisleadstostories.Documenttheresources(people,software,hardware,books,etc.)thatareneeded.Definesuccess.Clarify principles or constraints. For example: Is themain goal to please the boss,staywithinbudget,orfinishbyacertaindeadline?

Identifystories

Storiesaresimpledescriptionsofwhatthesoftwareshouldaccomplish.Thesestoriesaredeveloped by the customer and the developing team.Given a story, the teammemberscreateissues.Thisisanopenprocess;findingthestoriesmayrelyonanyusefultechniquelikebrainstormingormindmaps.

Note:Storiesdonotmentiontechnicaldetails.Thegatheringofstoriesusuallyhappensatthebeginningofeveryiteration.

Define enhancements: The product manager breaks down the stories intoenhancements,documents themasissues,andassignsthemtoteamsanditerations.Shealsoprovidespriorities anda roughchronologicalorder for the enhancements.Shethenhandstheiterationplanningovertotheteamleads.Iteration:Theteamscarryoutaniteration(seealsoHowtoiterate).Thismayleadtoadaptedornewenhancementsandstories.Review the iteration plan: After each iteration, the team leads and the productmanagergathertoreviewit.Thisreviewdiscussesifthegoalsoftheiterationwerefulfilled.Thisreviewcanbedoneaspartoftheretrospectivemeeting.

Assigningteammembers

Generally,it isabadideatoassignateammembertoworkontwoprojectsatthesametimeinoneiteration,becauseitrequiresalotofdisciplinefromtheteammember.

While it is possible to divide a week into two parts, each devoted to working on oneproject, work is in reality often fragmented. Fragmentation appears when the times inwhichthepersonneedstobeinoneplaceoverlapwithtimeswherethepersonneedstobesomewhereelse.Ifitcannotbeavoided(typicallythecaseinstartupswhereallemployeesshare theworkload andhelp eachother), it requiresvery clearplanningof theperson’s

resources.

ExampleThisexampleshowsauserstoryandrelatedenhancements.Theoverallgoalistodevelopasoftwarethatmanagesthecustomersofacompany.

Userstory

Title:OpeningacustomerbycustomerID

Description:Asacallcenteragent,IwanttoopenacustomerbyenteringhiscustomerID,sothatIcanquicklyaccesshisdatawhenheiscallingthecallcenterandidentifyinghimselfwithhiscustomerID.

Enhancementforthefrontendteam

The web user interface allows quick navigation to a customer profile by entering thecustomerID.

Task:ImplementanumberfieldthatallowstoenteracustomerIDonallthepagesofthesoftware. Hitting the button “Go!” or the “enter” key opens the customer’s profile, ifavailable.Iftheprofileisnotavailable,showamessagestatingthatthecustomerdoesnotexist.

Enhancementforthebackendteam

WeneedawaytoconstructaURLtoshowtheprofileofacustomergivenhiscustomerID.

Task:ImplementthegetCustomerUrlservice,whichconstructsaURLgivenacustomerIDorreturnsanerrormessageifthecustomerdoesnotexist.

HowtoiterateAniterationisonecycleinthereleaseprocess.Usuallyaniterationis5weekslongandhasthreephases:

Planning:2–3daysImplementing:~4weeksTesting:1week(seeHowtocreateareleasefordetails).

Theexactdurationisuptothetasteoftheteam.5weeksworksforus,butwealsoheardfromotherteamsthatashorterdurationispracticable.Wepreferouriterationstoalwayshavethesamelengths,toensurethattheteamisawareofitandembracestherythm.

Intheplanningphase…

…theteamleadassignstheenhancementsthatweredefinedintheprojectplanningtotheteam members. Additionally, the team lead also distributes tasks and issues to teammembers. Tasks are parts of an enhancement and can be used to break down anenhancement into a number of smaller pieces of work. Issues come from testing thesoftwareandfromuserfeedback.Intheplanningphase,theteamleadalsoassignsissuesthatwerepostponedfrompreviousiterationstoteammembers.

Intheimplementationphase…

…allteammembersworkontheirenhancements,issues,andbugs.Duringthisphase,norequests from outside of the team should be accepted (read below on how to handleasynchronous requests). During the core meeting, the team members report on theirprogressoftheprojectstheyareworkingon.

Inthetestingphase…

…thesoftwaredevelopment is first frozenandthen testedaccording toa testplan.SeeHowtocreateareleasefordetails.Aftercreatingthereleasetheiterationisoveranditistimetotakeanicebreak,readabook,plantatree,orhaveaBBQ.

Asynchronousrequests

Acustomerorproductmanagerapproachesateammemberwithanasynchronousrequestinthemiddleofaniteration.

Generallythisisnotallowed.Andthus,itisimportantthattheproductmanagerexplainsthisrule(andthegeneralprocess)tothecustomeratthebeginningoftheproject,sothattheyunderstandwhyarequestispushedback.Ateammemberthatfacesanasynchronousrequestmayhandleitinthefollowingway:

If it is theproductmanagerthatapproachesateammember,thentheteammembermaytellhertoimprovetheplanningnexttimeandrefusetoaccepttherequest.Ifitisthecustomer,thentheproductmanagerexplainstohimthatitisnotpracticalforthesuccessandqualityofthecurrentiteration.

If the request is critical and comes in before the freeze of the iteration’smilestone, theproductmanagermayoffertotradethenewenhancementagainstoneoftheenhancementsthatwasplannedfortheiteration.

HowtoworkwithissuesIssuesareoneofthecoreconceptsoftheCo-Pilot.Thereareseveralrulestofollowwhendealingwithissues:

Everycodechangeiscausedbyanissue.Everyrequestforacodechangemustbefiledasanissue.Anissuecanonlyberesolvedasfixed,ifithasanassigneeandfixversion.

Itisimportanttotrackissuesbecauseofthefollowingreasons:

Issuescanbeviewedasa listof things thata teammemberneeds todo.Filinganissueensuresthatthe“todo”isnotforgotten.Issuesmaybeassignedtoaperson.Onceanissueisassigned, it isclearwhois itsownerandthusresponsibletoresolveit.It isoftendifficult tounderstand somebodyelse’s codechangesandwhyachangehasbeendone.Anissuedescribingit,evenjustbriefly,helpsalot.Issueshelptrackchanges.Anissuecanbereopened,reassigned,prioritized,itcanbeusedfordiscussions,anditsupportsplanning.Issueshelpstakeholderswhodonotlookatthecommittedcodestayinformedontheproject’sprogressandsupportedfunctionality.Issuesvisualizewhat,when,andbywhomchangesoccur.This,forexample,allowstesterstoverifyfixes.

Themaingoalofissuesis toenableall involvedpartiestotracktheworkperformedbythe team members. As a consequence of this transparent setup, team members takeresponsibilityfortheirwork.Thisisnotusedtoblamethemforanymistakes,butithelpsto make problems and miscommunication visible while there is still time to react.Additionally,teammembersmaylearnfromthemistakesofothers.

IssuestatesStatus

Atanymomentin its lifetime,anissuehasexactlyonestatus.Duringthelifetimeofanissue,severalstatuschangesmayoccur.TheCo-Pilotdefinesfollowingstatuses:

Open:Anopen issue is part of an inbox thatwill be checkedperiodically by the teamlead.

Triaged:Thisisanissuethathasundergonethescrutinyofateamleadandisplannedinamilestoneorbecomespartofthebacklog.

Resolved: An issuewith a resolution tag. A resolved issue is no longer considered anissueintheproduct.Severaldifferentresolutionsexist:SeeResolutionsbelowfordetails.

Reviewed:Ifanissueneedstobereviewed,itsstatusshouldbesettoreviewingandthename of the team member who must review the issue should be included. Once thereviewer has successfully reviewed the issue, the reviewer should set the status of theissuetoreviewed.SeeHowtocreateareleasefordetailsaboutthereviewingprocess.

Verified:Ifanissueneedstobeverified,itsstatusshouldbesettoverificationandateammembershouldbeappointedtoverifytheissue.Oncetheverifierhassuccessfullyverifiedtheissue,theverifierstatusshouldbechangedtoverifiied.SeeHowtocreateareleasefordetailsontheverificationprocess.

Closed:Aresolvedissuecanbemarkedasclosed.Aclosedissuemustnotandcannotbeverified.

Resolutions

Whensettinganissue’sstatetoresolved,theassigneemustprovideareason,theso-calledresolution.Therearethefollowingresolutions:

Fixed:Thismeansthattheissueisfixed.

Won’tfix:Sometimesitdoesnotmakesensetofixanissue.Eitherbecauseithasalreadybeenfixedorbecauseitisirrelevant.Acommenttoexplainwhyanissuewillnotbefixedismandatory.

Worksforme:Insomecasesanissuescannotbereproducedbytheprogrammer.Inthiscasetheissuesshouldbeclosedasworksforme.

Duplicate:Sometimesthesameorsimilarissuesarecreatedmorethanonce.Inthiscasethenewerissuesorthosethatarelessdescriptivecanbeclosedasduplicate.

Verified:Whenanissuehasgonethroughtheverificationprocess,thenitsresolutionwillbeverifiedindicatingthatanadditionalpersonhascheckedthattheissueisfixed.

Assignee

Theassigneeofanissueisresponsiblefortheissuetoberesolved.Onlyissuesthathavean assignee can and will be resolved. It is common that the assignee of an issue isdetermined on the fly during iterations or at the beginning of each iteration during theiterationplaning.Largerprojectswithmultiple teamsusethe“component”tagtoassign

issueresponsibilitiestoaspecificteam.

AffectedVersion

Theaffectedversionspecifiestheversionoftheproductinwhichtheissuewasdetected.Thisinformationiscrucialtoreproducetheissue.

Fixversion

Eachissueshouldhaveafixversion.Iftheissueisstillopen,thefixversiondeterminesinwhichiterationitmustberesolved.Ifitisfixedorverified,itdescribesinwhichiterationtheissuewasresolved.Itiscommonthatthefixversionofanissuechanges.Thismighthappen if an issuemust be postponed to a later iteration because of lack of time or animpediment (a requiredother issue) thatcouldnotberesolvedon time,or if theprojectprogress allows to resolve an issue earlier than initially planned. It is also commonpractice to set the fixversionon the flyduringan iteration.To resolvean issue, the fixversionmustbeset.

ExampleThe followingexampledescribesa typical life cycle for an issue.Whencreatinganewissue,thefollowinginformationmustbeentered:

theprojectitbelongstoifavailable,thecomponentitisassociatedto(thisdeterminestheresponsibleteam,iftherearemultipleteamsinaproject)anaffectedversion,sothattheissuecanbereproducedan issue description stating the problem in such a way that another person canreproducetheerrororunderstandwhatneedstobedoneforanewfeature

Afterthecreationoftheissue,itwillbeinstatus“Open”.

The team leads regularlycheck theircomponent’s inboxand triage the issuesbysettingtheir status to “Triaged”, assigning them to a teammember, and determining their “Fixversion”.Before the teammember commits a fix, shemay request a reviewby anotherteammemberbysettingthestatusoftheissueto“Reviewing”.AfterhavingtheOKfromthereviewer,theissuemayalsoneedtobeverifiedbysettingitsstatusto“Verification”.

Oncetheissuehasbeenverified,itsstatusandresolutionwillbe“Verified”.

Priorities

An issue may have a priority. The higher the priority the faster the issue should beresolved.Acriticalorblockerissuehasalwayshighpriorityandaminoronehasalwaysalowpriority.TheCo-Pilotdefinesthefollowingpriorities:

Blocker: The product cannot be used without this issue being resolved. It blocksdevelopment and/or testing.The assigned teammember should immediately start fixingthisissue.

MajororCritical:Theissueisamustdoandneedstobedonefirst.Itisveryhardtousetheproductwiththisissue.Itisunacceptabletohavesuchanissueinarelease.

Normal: It is a normalbug. It shouldbe fixed if possible.Do this after all issueswithhigherpriorityhavebeenfixed.Issueswithnormalprioritiesaregenerallyexpectedtoberesolvedintheproduct.

MinororTrivial:Asmallbugwhichmighteven stayunrecognizedbymostusers.Dothisafterallissueswithhigherpriorityhavebeenresolved.Issueswithlowprioritiesareusuallynicetohave.Itisonlyacceptabletofixsuchanissueiftheriskofintroducinganew,moreseverebug,islow.Itisnoproblemtoreleasetheproductleavingtheseissuesunresolved.

ExamplesBlocker:Itisnotpossibletologin.

Critical:Productcrashes,dataislost,orsecuritydoesnotwithstandattack.

Major:Displayflickers,refreshsometimesdoesnotreload.

Normal:Acommonlyexpectedkeyboardshortcutdoesnotwork,e.g.hittingthe“enter”keyinatextboxforquickopeningacustomerprofileisnotworking.

Minor:Borderis2pixeltoofartotheleftinInternetExplorer7.

HowtotriageissuesChange is the only constant in a project. Thus, triaging issues is a continuous process.Wheneveranewissuecomesin, the triagingshouldhappenwithin thenext24hours toensurethattheprojectandtheteammembersstayontopofthings.Whiletriagingissues,theylearnhowtheircustomersusetheproductandnoticethedifficultspotsimmediately.Hence,triagingissuesisallaboutcommunication.

Takeanissuefromtheinbox

An unassigned, unowned issuewithout a target first appears in the inbox of the inboxtriager.Usually, the productmanager takes the role of inbox triager.He distributes theissues to the teams. The team leads of the components then process the issues in theircomponents’ inbox and assign them to their teammembers and decide on a target. If ateammemberreportsanissuethatisrootedinherownedcode,shemaycircumventthisprocessanddirectlyassignittoherself.Generally,allpartiesshouldconstantlykeeptrackoftheinboxandtheirissuestates,ataminimumonadailybasis.

Reproducetheissue

Tounderstandanissueitneedstobereproduced.Thereproductionshouldhappenshortlyafter the first issue report, because itmay require contacting the reporter to clarify anyuncertainties.Thereproductionmayresultinthreepossibleoutcomes:

Theissuecanbereproduced.Theissuecannotbereproduced.Itisunclearhowtoreproducetheissue.

There is a thin line between cannot and do not know how to reproduce. If the personworkingontheissueisnotabletoreproducetheissue,shecanalwaysrequestdetailsfromthereportertobetterunderstandwhathedid.

HandlingreproducibleissuesIssues that can be reproducedwillmost likely be resolved as “duplicate”, “won’t fix”,“fixed“,or“verified”.

Closeasduplicateorwon’tfix

An issue is resolved as “duplicate”, if it can be reproduced and is already captured byanotherissue.Thereportermustbenotifiedabouttheexistingissuebyaddingacomment,suchas“duplicateofissue#1234”,whenclosingtheissue.Iftheissuecanbereproducedandisresolvedas“won’tfix”,itwillnotbefixed.Theissuedescriptionneedstocontainagood,comprehensiblereasonfornotfixingit.Notgivingareasonviolatesthenetiquette.

Closeasfixedorverified

Iftheissueisunderstoodandithasbeendecidedtofixit,thentheissueisplannedand/orassigned.Itisrequiredtoeitherassigntheissuetoateammemberorplantheissueforaniterationorboth.Itisalsodesirabletosettheseverityandpriorityinthisstep.SeeHowtoworkwithissuesforadefinitionofalltheseverityandprioritylevels.

Fixinganissueinvolvesseveraladditionalsteps:

Fix the issue: Fixing the issue will result in a code change, thus it should beaccompaniedbyaunittest(ifpossible).Thisensuresthattheissuewillnotreappearinfuturereleases.Reviewingfix:Itmayalsoberequiredthatthecodechangeisreviewedbyanotherpersonbeforetheissuecanbeclosedasfixed.Thisisoptional.SeeHowtocreateareleasefordetailsaboutthereviewingprocess.Closeas fixed:After the fixing, the issue resolution is set to “fixed”.A commentaccompanies the issue and describes in which revision of the code the issue wasfixed.Thedevelopershouldmakesurethatallunittestsaregreenbeforetheyclosetheissue.Verify fix: Before the next release takes place, the issue should be verified. Thismeansthatapersondifferentfromtheowneroftheissuetriestoreproducetheissue.Ifhecannotreproduceit,theissuestateischangedto“verified”.Otherwise,theissueisreopenedandhastobeplannedandfixedagain.

IrreproducibleorcrypticissuesCloseasworksforme

Anissuemayreceivetheresolution“worksforme”,iftheassignedteammemberissurethat she understands the issue, but cannot reproduce it. The issue should contain anexplanationwhyandhowitworks.Asanexample,shemightwrite“Thisalreadyworks,see the FooBar preference page and enableX”.Usually, issueswith this resolution arecausedbyausererror.

Requestdetails

Iftheissuereportcontainsvagueorincompleteinformationandthusmakesitimpossibletoreproducetheissue,thereportershouldprovidemoreinformation.Asanexample,hemight need to provide the specific system (operating system, browser, programminglanguageversion)thatheworkedwith.Ifthereporterdoesnotreactorfailstoprovideanyinformationthatmakestheissuereproducible,theteammembermaydecidetoclosetheissueas“works forme”.Ofcourse, it isnotdesirable toclosean issue that isnot fullyunderstood,soeverythingpossibleshouldbedonetogetthefeedback.

HowtoplanareleaseweekPlanninga releaseweek involvesallocatingpeople to thefreezing, testingandreleasingactivitiessothatallinvolvedpartiescancompletetheirworkandcontributeoptimallytomaking the releasehappen.During a test and releaseweek, the tasks executedby teammembersandteamleadsdifferfromtheworkdoneduringthedevelopmentweeks.Thus,itisespeciallyimportanttounderstandwhatneedstobedoneandwherehelpisrequired.Theplanningofthetestandreleaseweekisthejoboftheproductmanager,theteamleadsandtheteammembers.Theproductmanageristhepersonthatknowsabouteverybody’sscheduleandalsohasanoverviewabouttheschedulesofotherprojectsthatmightruninparallel.

ReleaseweekactivitiesAllactivities

Who:TeammembersWhat:Announcesanyunavailabilitiesearlyon.

Thiswillhelptheteamleadsandtheproductmanagerorganizethereleaseweek.

Testing

Who:ProductmanagerWhat:Organizestestersandannouncesthetestingday.Ifappropriate,thistaskcanalsobedelegatedtotheteamlead.

Make sure that theplanned testers areavailableon the testingday.Possible sources fortestersare:

theprojectteampeoplefromotherprojectscustomersthatprovidetesters

Fixing

Who:TeamleadWhat: Ensures that at least one person with the needed technological background forfixingissuesisavailableforeverycomponent.

This is particularly important in small teams that use a technology that is not widelyspreadacrossteams.Talktotheproductmanagerbeforethereleaseweekifthiscannotbeensured.

Reviewing

Who:TeamleadWhat: Ensures that at least one other person for reviewing is available for everycomponent.

This is particularly important in small teams that use a technology that is not widelyspreadacrossteams.Talktotheproductmanagerbeforethereleaseweekifthiscannotbeensured.

Deployment

Who:TeamleadWhat:Ensuresthatthereisatleastonepersonwhohasthetechnologicalbackgroundtodeploythereleaseforeverycomponent.

This is particularly important in small teams that use a technology that is not widelyspreadacrossteams.Talktotheproductmanagerbeforethereleaseweekifthiscannotbeensured.

Releasing

Who:TeamleadWhat:Ensuresthatthereissomebodyavailableforwritingthe“NewandNoteworthy”ofhiscomponent.

Talktotheproductmanagerbeforethereleaseweekifthiscannotbeensured.

ThereleaseweekStay flexible during the releaseweek.We all knowwhat needs to be done in a releaseweek: write a test plan, test, fix, review, verify, write the “New and Noteworthy” andfinallydeploytherelease.TheCo-Pilotdefinestheseactivitiesprecisely,buttheamountofworktheyentailcanvaryverymuchbetweencomponentsandalsobetweenmilestones.Therefore,theteammembersshould

talktoeachotherofferhelpifalltasksassignedtoherhavebeenfinishedworkasateam

HowtocreateareleaseDuring the development phase, the team regularly creates releases – pieces of softwarethat combine a set of features and are fit for showing to the customer.Everymilestoneendswith such a release.This allows the customer to verify that the project iswell ontrackandtofindproblemsclosetowhentheyarise.Beingabletoreleaseaworkingbuildatanygivenmomentisalsothenumberonesuccessfactorofanagileteam.Todoso,itisessentialtoautomatizethebuilding,qualityassurance(runningautomatedtestsandtoolslikefindbugs)anddeploymentprocess.

FreezedayThe freezemarks the end of development in a specificmilestone.After the freeze, thedevelopmentcodeisnolongerchangeduntilafterthetestingday.

Deploythereleasecandidate

Themost important thingwhen creating a release is to test the system under end userconditions.Thismeansthatabuildisdeployedonthesystem(oratleastanexactcopyofthesystem)onwhichitwillgolive.Inanidealworld,thereleasecandidatewillbecomethe release without any changes. It’s the team lead’s responsibility that the releasecandidateisreleased.

Writeatestplan

In parallel to the deployment of the release candidate, the teams write the test plan.Usually, each teammemberwrites a test plan for the issues sheworked on during thedevelopment phase. It is important to gather input about the test items from allstakeholders that worked on the release candidate. The product manager notifies thetestersinadvancetoensurethattheyareavailableduringthetestingdays.Shemayalsoinvitecustomersonsitetoparticipateinthisactivity.Seethetestplantemplateattheendofthischapter.

TestingdayAssigntestitems

InsteadofaScrummeetingateammeetingisusedtoassignalltestitemstooneorseveraltesters.Afterthemeeting,everyoneintheteamknowswhattotestandeverytestitemhasatleastonetester.

Testtherelease

Duringthetestingdays,thedeployedreleasecandidateistestedaccordingtothetestplan.Thisusuallyonlytakesoneday,butinlargeprojectsitcouldbemore.Unlessablockingissue prevents testing, no code changes are allowed during this time, because a stablebaseline is needed tomake sure no new issues are introduced. The testers report everyfailure they discover as issues in the issue tracking system.SeeHow to test for detailsaboutreleasetesting.

Atestplanlistingthetestitemsandwhichtestershavetestedthem.

FixingdaysIssuetriagemeeting

After the test day each team triages all discovered issues. Triaging can be done by theteamlead,ateammemberorintheformofateammeeting.Ithasbeenproventobeveryeffective if the team leadmakes a first pass over the discovered issues and triages theobviousonesandthenschedulesameetingwiththeteamtodiscusstheremainingissues.Thegoalof the triaging is to identify the issues thatmustbe fixed inorder to reachanacceptablequality level for the release. It is important that theproductmanagerdefineswhatacceptablequalitymeansforthecurrentrelease.Thishighlydependsonthekindofrelease.Theacceptablequalityofamilestonediffersfromthatofaproductrelease.Theproduct manager may, for example, define that the release must not contain any openmajor issues.Usually, these quality requirements are directly derived from the contractmadewith thecustomer.Acceptablequalitynevermeansflawless.Thedecisionwhat tofix andwhat not to fix is a veryhardproblemanddependsonmany factors.A ruleofthumbisthatthehigherthechancethatthefixforanissuewillintroduceanewbugthelesslikelyitisthattheissuewillbefixedduringthefixingdays.Ifnomoreissuesremaintobefixed,thereleasecantakeplace.Otherwise,theteamsneedtofixtheidentifiedbugs,create a new release candidate, verify the fixes, and decide again if the quality isacceptable. This may, potentially, take forever, but usually requires only one or twoiterations.

Fixingandreviewing

Duringthefixingdays,theteammembersfixallissueswhichhavebeenplannedforthecurrent release during the issue triaging step. Each fix needs a corresponding issue.Atleastonereviewisrequiredforeachcodechange.Thedeveloperofthefixcanchooseanyteammemberforthereview.Fixesarenotcommitted,butsenttothereviewerasapatchfile (with SVN) or pushed to a branch (withGit). Issues can only be committed to themaindevelopmentlineafterasuccessfulreview.Ideally,allthefixingandreviewingwillbefinishedonthedaybeforetherelease,sothereleaseisnotstressful.FormoredetailsaboutreviewingwithSVNandGit,seeHowtoreviewissues.

VerifyingandreleasedayDeployanewreleasecandidate

The release candidate will be deployed again on the morning of this day under theresponsibilityoftheteamleads.Itwillincludeallfixedandreviewedissues.

Verifyfixes

All issues fixed during the fixing days are verified in the newly deployed releasecandidate.Verificationmeansthatatesterotherthanthedeveloperwhofixedtheissueandotherthanthereviewerofthefixtriestoreproducetheissue.Ifhecannotreproduceit,theissue is verified. Otherwise, the issue has to be reopened, fixed, reviewed and finallyverifiedagain.Everytimethishappens,anewreleasecandidatehastobedeployed,sothenewly fixed issue can be verified. This process is repeated until the issue can besuccessfullyverified.

Release

Once all team leads give their approval, the release takes place. In a perfectworld, therelease occurs without any discernible effects to the running system. In reality, thedeploymentusuallyrequiresconfigurationsteps,suchascopyingthereleasecandidatetoanothermachineordisablingaccesscontrol tomakeawebsitepubliclyavailable.Afterthis has been done, the product manager informs all stakeholders about the release. Adocumentcontainingwhatisnewandnoteworthyprovidesadescriptionofnewfeaturesdevelopedinthemilestone.

Openabottleofchampagne

Afterthereleaseitisimportanttothrowalittleparty,haveabeertogether,andgivetheteamacoupleofdaystorelax.Thisiscalledthedecompressionphase.

OneweeklaterRetrospectivemeeting

Intheweekaftertherelease,aretrospectivemeetingshouldbeheld.SeeHowtoholdaretrospectivemeetingfordetails.

Atestplanlistingthetestitemsandwhichtestershavetestedthem.

HowtoreviewissuesIssuesneed tobereviewedandverified if theyare fixedfora releasebutarenot testedduringthetestdaysofthereleaseweek.Thisisthecaseforalltheissuesfoundduringthetestdaysthatarebeingfixedduringthefixdaysofareleaseweek.Sincetheseissueswillnotgothroughatestingdayprocess,thesourcecodechangeshavetobepeerreviewedbyanother teammember.The reviewing stepof theCo-Pilot process helps ensure that thecode changes have a high quality. The verification step is done after the code changeshavebeencommittedandanewreleasecandidateisbuilt.Itservesasasecondinstanceofcontrol.Thischapteronlydescribesthereviewingprocess.

Ifanissuecomesin,theteamleadfirsttriagesitandthenassignsittotherespectiveteammember. The teammember develops a fix for the issue. The handling of the fix thendependsontheversioncontrolsoftwareusedfortherespectiveproject.

SVN

ThereviewingprocessinSVNusespatches.Afterateammemberhasproducedafixoftheissueinherdevelopmentenvironment,shewillcreateapatch,containingallthecodechanges.Preferably,thepatchcontainstheissuenumberandprojectnameinitsfilename.Thepatchshouldcontain the issuenumberand is thenattached to the issue in the issuetracker.Ifbinaryfilesareneededtoreviewtheissue,forexampleimages,thosehavetobeattached separately, as patches onlywork for textual files (e.g., code and configurationfiles).Then,areviewerisaddedtotheissueandtheissuereceivesthestatus“reviewing”.The reviewer applies thepatch toherownproject, checks the codeand tests the fixbydeployingtheprojectlocallyandcheckingthechangesvisually.Ifsheapprovesofthefix,shetagstheissueasreviewedandreturnsittotheteammemberwhoproducedthepatch.Afterasuccessfulreview,theteammemberthencommitsthechangestothedevelopmentstream.

Git

InGit thereviewingprocess isbasedonbranches.Whenan issue is reviewed, the teammemberworkingontheissuecreatesanewbranchonherlocalrepository.Thebranchisnamed containing the issue number. All code and file changes are then done on thisbranch.Oncedone,theteammemberpushesthisbranchtotheremoterepository,assignsareviewertotheissueandmarkstheissueasreviewing.Theteammemberthathasbeenassignedasareviewerpullsthebranchfromtheremoterepository,switchestothebranchandreviewsthecodeanddeploystheprojectlocallytocheckthechangesfunctionallyandvisually. If she approves, the reviewed code branch ismerged into themain branch byeitherthereviewerortheteammemberwhohasfixedtheissueandtheissueistaggedasreviewed.FormoreinformationonhowtodobranchingwithGit,seeHowtouseGit.

It isalsopossible thatareviewermayrejectanissue.Thiscanhappenonthefollowinggrounds:

thecodeorotherfilesofthepatcharefaultytherefactoringistoolargeandhasunforeseenimplicationsontheprojectthatcannot

betestedtheteamleaddoesnotagreewiththefix

HowtouseGit

GitisadistributedversioncontrolsystemandatComerge,weuseitforseveralprojects.OneofthepowersofGitisitsflexibilityinbranching.Thedownsideofthispoweristhedanger of introducing chaos into a repository. The Co-Pilot suggests a lightweight yetflexiblebranchingmodel toget themostoutofGitwithouthaving tocorrectbranchingandmergingmistakes frequently.ThisGit branchingmodel is highly influencedby theblogpostofVincentDriessen.

For each project, one or more central Git repositories exist. This central repository ishosted on a repository server and is called origin. The continuous integrationinfrastructureanddeploymentprocessalwaysworkwiththiscentralrepository.

Eachdeveloperhasherowncopy(i.e.,clone)oftherepositorylocallyonhercomputer.Itisuptothedeveloperthatshekeepsherlocalrepositoryinsyncwithorigin.Thatis,shepushesherchangestooriginwhenshehasworkingcommitsandpullslatestchangesfromotherdevelopers.

MasteranddevelopmentThe centralorigin repository holds two branches that will exist for the lifetime of theproject:

masterdevelopment

Theorigin/master branch is similar to the trunk in Subversion. The source code at theHEAD (latestcommit in thebranch)of themasterbranchpointsalways toaproductionstateoftheproject.Theorigin/masterreflectsacleanandstablerelease.

Theorigin/developmentbranch is themainbranchfordevelopment. ItsHEADpoints tothelatestpushofthedevelopers.Anyautomaticallytriggeredbuildfromourcontinuousintegration infrastructure uses this branch. If the project is ready to be released in thereleaseweek, thedevelopmentbranch ismergedback to themasterbranch.Themasterbranchisthentaggedwiththenewreleasenumber(moreonthistopicbelow).Therefore,a merge into the master branch always means that a new production release can andshouldbemade.

There are several caseswherebranchesother thanmaster anddevelopment are created.Thosecasesareexplainedbelow.

FeaturebranchesNormallybranchesofffrom:developmentMustmergebackinto:developmentBranchnamingconvention:issuenumberorfeaturename

Wehighlyencouragedeveloperstointegrateoftenandtoworkonthedevelopmentbranchonly. But, if it is unknownwhether the featurewillmake it into to the next scheduledreleaseornot,afeaturebranchshouldbeused.Inallothercasesdevelopersshouldn’tusefeaturebranches.Itisuptothedevelopertokeepherbranchinsyncwiththedevelopmentbranch and push it to origin so that its commits are available for other developers.However, if no one else needs the commits the feature branch should not be pushed toorigin.

ExampleofafeaturebranchCreatingafeaturebranch

When creating a feature branch, the development branch is the start point. A sensiblename(e.g.,thefeaturenameortheissuenumber)shouldbeusedtocreatethebranch:$gitcheckout-b<featurename>development

Syncingthefeaturebranch

Thelatestcommitsinthedevelopmentbranchcanbemergedintothefeaturebranchby:$gitcheckoutdevelopment

$gitpull

$gitcheckout<featurename>

$gitmergedevelopment

Mergingthefeaturebranchback

After finishing thework on the feature branch, it ismerged back into the developmentbranch:$gitcheckoutdevelopment

$gitpull

$gitmerge—no-ff<featurename>

$gitpush

The—no-ffflagshouldalwaysbeusedtoforceamergecommitevenifthemergecanbefast-forwarded.

Aftermerging,thefeaturebranchcanbedeleted:$gitbranch-d<featurename>

Ifthefeaturebranchwaspushedtoorigin,ithastobedeletedthereaswell:$gitpushorigin:<featurename>

FixBranchesMustbranchofffrom:developmentafterfreezeMustmergebackinto:developmentBranchnamingconvention:issuenumber

Thesebranchesarecreatedduringthereleaseweekafterthefreeze.Afixbranchhastobecreatedforeachissuethatisfixedduringthereleaseweek.Incomparisontothefeaturebranch, the fix branch has to be pushed to origin so that it can be reviewed.The issuenumber has to be used as the nameof the fix branch and it has to be created from thefreezeddevelopmentbranch.Oncethechangeisreviewed,thefixbranchismergedbackintothedevelopmentbranchandthecorrespondingissueismarkedasreviewed.

ExampleofafixbranchCreatingafixbranch$gitcheckout-b<issuenumber>development

Finishingfixbranches

Iftheworkontheissueisdone,thefixbrancheshastobepushedtoorigin.The-u flaghastobeusedtotrackthebranch.$gitpush-uorigin<issuenumber>

Mergingfixbranchesback

Afteranissueforthenextreleasecandidatehasbeenreviewed,thedeveloperwhofixedtheissuewillmergethefixbranchbackintothedevelopmentbranch:$gitcheckoutdevelopment

$gitpull

$gitmerge<issuenumber>

$gitpush

Itisuptotheteamlead(orproductmanager)whetherthefixbranchesaredeletednoworafterverification.However,theyhavetobedeletedbeforethenextmilestonestarts:$gitbranch-d<issuenumber>

$gitpushorigin:<issuenumber>

Sincethefixbranchwaspushedtoorigin,ithastobedeletedremotely,too.

After all fix branches have been merged to the development branch, the next releasecandidateiscreatedfromthedevelopment:$gittag<releasecandidate2>

$gitpush—tags

HotfixBranchesMustbranchofffrom:masterMustmergebackinto:masteranddevelopmentBranchnamingconvention:issuenumber

Incaseablockeron theproductionsystemhas tobefixedandcannotwait for thenextregularrelease,ahotfixbranchhastobecreatedfromthemasterbranch.Oncethehotfixchangesare reviewed, theyaremergedboth into themaster anddevelopmentbranches.Thenthefixedbugwillbereleasedinasmallreleasebetweenmilestones.

ExampleofahotfixbranchCreatingahotfixbranch$gitcheckout-b<issuenumber>master

#increasingthebuildversion,commit,andpush

#fixtheblocker

Mergingthehotfixbranchback

Aftertheblockerhasbeenfixed,reviewed,andverified,theteamleadhastomergebackthehotfixbranch into themaster anddevelopmentbranches.Sinceaminor releasewillresult,acorrespondingtagonthemasterbranchhastobemade,too:$gitcheckoutmaster

$gitmerge—no-ff<issuenumber>

$gitpush

$gittag<releasetag>

$gitpush—tags

$gitcheckoutdevelopment

$gitpull

$gitmerge—no-ff<issuenumber>

$gitpush

Thehotfixbranchcannowbedeleted$gitbranch-d<issuenumber>

$gitpushorigin:<issuenumber>

HowtotracktimeTimetrackingisimportantforcontrollingpurposesandhelpskeepprojectsontrackandthe work load manageable for the team. At Comerge, we track time because of thefollowingreasons:

1. Itservesasacontrolfortheemployeestomakesurethattheyhaveahealthywork–lifebalance.

2. ItservesasacontrolforComergetoensurethattheiremployeesputintheirregularhours.

3. It servesasabasis toanalyze ifemployeesworkingonseveralprojectsareable tospendadesignatedandplannedamountoftimefortherespectiveprojects.

4. Itservesasabasistocontroltheestimationsofworkandfurtherimprovethemforprovidingcorrectofferstocustomers.

5. Itservesasabasistobillcustomers.

Thisleadstothefollowingbasicrules:

Trackallthetimethatisspentworking

Thefirsttaskofanemployeeenteringtheofficeinthemorningistoturnontimetracking.Alsoactivitieslikereadingandansweringmails,readinguponanythingneededforworkshouldbe time tracked. Itdoesnot includechecking facebook (unless it isdone for thecompany’soracustomer’ssake)orreadingnewspapers.

Trackthetimeinthecorrectproject

Make sure that the time is tracked in the correct project.AtComerge,weprovide timetracking projects for every internal and external project, sometimes further divided intosubprojects for every component. Ifworking on an issue (for example, implementing afeature in theMobilityAndroidApp) this should be tracked in the corresponding timetracking project (e.g., “Mobility.Mobidroid”). Additionally, we have a general purposeproject(called“Comerge”inourtimetracker)anduseitforthetimetrackingofalltasksthatcannotbeclearlyattributedtoaspecificprojectsuchasreadingemails,cleaningupthe desk, etc. Scrummeetings, coremeetings and tech talks can also be tracked in thisproject.

Generally,whenworkingonanissue, trackthetimeonissuebasis.Always includetheissuenumberandtitle

When working on an issue, the general template to use for the time tracking entry is“<projectshorthand>-<issuenumber><issuetitle>”,e.g.,“COPILOT-136MovecertainchapterstotheCWW”.Theteamleadmightrequestadditionalinformationrelevanttotheissueinthetimetrackingentry.

Usemeaningfuldescriptionsfortaskswithoutanissue

Ingeneral,thereshouldalwaysbeanissueandthustheworkcanbetrackedasdescribedinthepreviousrule.Butif,forvariousreasons,itdoesnotmakesensetocreateanissue

(either because creating the issuewill take longer thandoing theworkor the issue cannever be closed because it is a frequently recurring task), it is important to use ameaningful description in the time entry.Entering a description saying “Working” doesnotprovideanyinformation.Trytobemorespecific,e.g.,“Triagingincomingissues”.

Team leads or the product manager control the time tracking and provideinstructionsonhowtodoit

Theproductmanageror team leadmightdecide to addadditional requirements.He/shemay also decide that tracking on issue basis is too fine grained and propose anothersolution(e.g.,trackingdevelopmenttimebywriting“Workingonissuesformilestone3”,becausetheyarenotinterestedintheworktimeperissue).

Thetimetrackingentriescouldbeusedinretrospectivemeetings

Thecomparisonofestimated/offered timewith theactual timeworkedonaprojectoraspecific feature helps control the health of a project. We have integrated such acomparisonintotheretrospectivemeeting.Sincethiscomparisonispresentedbytheteamleadof a component, it is in the interestof the team leads tomake sure that their teammemberstrackthetimecorrectly.

If there are any questions on how to track time, the team lead or the productmanagershouldhelpclarifythem.

Meetings

HowtoholdameetingSimilar toothercreativeprocesses,softwaredevelopment isacollaborativepracticeandefficientcommunicationwithothermembersofthedevelopmentteamisakeytosuccess.Inparticularinheterogeneousteamswithvaryingdegreesofefficiency,itisimportanttostructure the time spent together—for example in meetings—in an efficient and wellorganizedway.Hereareafewhintsforpreparingameeting:

BeforethemeetingWriteagenda

The organizer of themeeting prepares a short agenda. This puts all participants in thepicture of what will be the content of the meeting and will help them to preparethemselves.Theagendacontainsorderedtopics,includingtheirpriorityandexpectedtimeframeandtheagendatellseverybodyhowtheyshouldprepareforthemeeting.

Sendagendatoallparticipants

An agenda on a hidden page is useless. To be effective the organizer needs to send areadable formof the agenda bymail (the agenda directly or a link to the agenda). If aparticipanthasachangerequest,hewillneedtoannounceittoeverybodyinduetime(atleastonedayahead)andupdatetheagenda.

Organizemeeting

The organizer appoints a person to record themeetingminutes in advance and informshim.Additionally,hemayconsider the followingquestions:Are thenecessary tools forthekeeperoftheminutesavailable(paper,accesstoacomputer)?Aretherecommentsontheminutesofthepreviousmeeting?Arethereanylastminutechangestotheagenda?

DuringthemeetingTo make it possible to cover the entire agenda within a reasonable time frame, it isimportanttosticktotheagendaandavoiddigressions.

Writeminutes

Thekeeperoftheminutesrecordsthediscussiontopics,decisions,andanyotherpointsofinterest.

AfterthemeetingSendminutestoallparticipantsforcorrections

Afterthemeeting,thekeeperoftheminutessendsthemeetingminutestoallparticipantsforreview.

Correctminutes

Theparticipantschecktheminutesforcompletenessanderrors,andsendcorrectionsbacktotheauthoroftheminutes.

HowtoholdaScrummeetingThegoalof theScrummeeting is toengageall teammembers,hearabout their currentadvancesandvisualizethecurrentprogressoftheproject.Itisameetingtoseetheday-to-dayplanningofallteammembers.Ittakesplaceeverymorningandshouldnotlastmorethan10minutes.TheScrummeeting relieson theuseofa taskboardcontainingagridwithonerowperteammemberandthethreecolumns“todo”,“inprogress”,and“done”.

Prepare

The teammembers prepare the issues that theywill beworkingonduring theday in aform suitable for the task board, e.g., a post-it note with issue number and shortdescriptionoftheissue,whichcanbepinnedtothetaskboard.

Announce

The productmanager ensures that theScrummeeting is held every day; shewillmakesurethateverybodyjoinsthemeeting.

Meet

Allteammembersmeetinfrontofthetaskboard.

Report

Eachteammemberreportswhatshedidthedaybeforeandwhatshewillworkonduringtheday.Duringthisreporting,shemovestheissuesthatsheresolvedyesterdayfrom“todo”or“inprogress”to“done”andaddsnewissuestothetaskboardinthe“todo”and“inprogress” columns. Additionally there is a part on the task board that is called the“Backlog”.Ifanissuecannotbecompleted,itcanbemovedintothissectionofthetaskboard.Thismayhappen,forexample,becauseitreliesonacomponentorservicethatisnotyetready,orbecauseamoreurgentissuehascomeupandoverrulesallothers.

CommonpitfallsGranularityofissues:Theamountofworkthatisneededtocompleteanissueshouldnotexceedtheregulartimeframe(e.g.,morethanadayneededtoclosetheissue).Otherwise,itcanbefrustratingforateammember,becausenoprogressisvisibleonthetaskboard.

Too many things on one issue: There should be only one bug per issue or onefeature/enhancementperissue.

Gossip/chatter:Themeetingleadershouldavoidlettingthediscussionrunofftopic.Healsoremindstheteammemberstokeeptheirdescriptionofyesterday’sworkconcise.

Beingunclear/mumbling: Themost important pointwhen the teammembers describetheirpendingandclosedissuesistheiruseofsimplewordsandconciselanguage.Theirnotes need to bewritten legibly and they should speak loudly and clearly, such that allparticipantscanfollowtheirpresentation.

Theissuesforthedayarediscussed.

AtypicalScrumboard.

HowtoparticipateinacoremeetingDespiteallthesophisticatedtoolsandcommunicationchannels,softwaredevelopmentcanfeellikeasolitaryexercise.Developersgototheofficeinthemorning,getconnectedtothenetworkandstartdevelopingthecodeoftheircomponent.Oftentheyachievethebestresults when they get into a flow and quit noticing the world around them. The coremeeting (at Comerge, we hold it on Friday afternoon) is an institution that giveseverybodyanopportunitytoshowwhatheorshedidinthepastweekandtodemonstrateit to the others. The coremeeting is an important part of our company culture andwefoundcoremeetingstobeefficientupto15participants.

Prepare

Inthemorningbeforetheweeklycoremeeting,allparticipantsshouldpreparewhattheyplan to say during the meeting. They may produce notes to help present a report andpreventforgettinganykeyaspects.Also,ifateammemberplansademo,sheshouldtestitbefore(best:testitonthepresentationmachine).

Bethereontime

Asallcompanymembersparticipateinthecoremeeting,delaysresultinawasteoftimewithahighmultiplier.Theorganizershouldmakesurethatallparticipantsknowwhenthemeetingisscheduledandallparticipantsshouldappearintimeforthemeeting.

ManagementreportAt the beginning of the meeting, the management gives a statement on generalinformationandannouncements.Themanagementalsoreportsonstrategicdecisionsandplansforthefuture.

PersonalreportInturn,everyparticipantgivesashortpersonalreport.Thereportshouldcontainenoughinformationtoputallothersinthepictureoftheircurrentprogressesanditshouldbeheldin a form that is adequate for the entire audience (i.e., with different professionalbackgrounds and/or working on different projects). The personal report comprises twomain aspects of everyparticipant’s currentwork: a report on theworkdone in the pastweekandaplanoftheworktobedoneintheupcomingweek.

Pastweekreport

Summaryofwork:Describesthethreemostimportantpoints.Thereisnoneedforcompleteness,anoverviewsuffices.Themaingoalistoproduceinterestinthework.Demo:Wheneverpossible,thereportshouldincludeashortdemo.Thisdemoneedstobepreparedandtested.Thedemoisthemostexcitingpartofthecoremeeting.

Nextweekplan

Descriptionofnextweek’swork:Providesanideaofplannedactivitiesforthenextweek.Again,threemainpointsaresufficient,noneedforcompleteness.Questions: The coremeeting is a chance for the participantsworking on differentprojects to interact. Theymay find similarities in their current tasks and decide tohaveadeepertechnicaldiscussionoffline.Questionsmaybeaskedduringthecoremeeting, but they should stay focused and mainly target clarifications. In-depthdiscussionshouldbetakenoffline.

TeamleadstatusreportEvery team leadhas to summarize the statusofhis current project, using the followingscale:

Green:Everythingisfine,theprojectisgoingwell.Yellow:Theprojectisgoingasplanned,buttherearesomeproblemsoruncertaintiesthatneedtoberesolved.Yellowmeansthatateamleadwantstotalktotheproductmanagerorthecompany’smanagementaboutthestateoftheproject.Red: The project is definitely not going as planned, problems have to be fixed.Managementneedstohelp/act.

HowtoholdaretrospectivemeetingAsstatedintheintroduction,everythingwedescribehereissubjecttoevolutionandweconstantlytrytoimprovetheprocessesoftheCo-Pilot.Tolearnfrommistakes,theymustbe identified and actions developed to counter their repetition. This is the goal of theretrospectivemeeting.

Goal

In the retrospective meeting the team discusses their perception of the completedmilestone. The retrospective meeting acts as an open discussion platform. If the teamidentifiesaproblem, theydiscusscountermeasuresaspartof theprocesses toprevent itfromreoccurring.

BeforeProductmanagerinvitestothemeeting

There is no special need for an extensive agenda. Instead, the productmanager shouldcreate a wiki page based on the retrospective meeting template. The mail to theparticipantsshouldincludealinktothispage,witharequesttoaddpositiveandnegativepointsbeforethemeeting.

DuringThreepositiveandthreenegativepoints

Eachparticipantwritesthreepositiveandthreenegativepointsaboutthemilestoneonthewikimeetingpageinadvance.Participantreports:Everyparticipantgivesanexplanationon

threeitemsthatwentwellduringthemilestone.threeitemsthatwentbadlyduringthemilestone.

Milestoneplanvalidation

Eachteamleadreports if themilestoneplanwasfulfilledforhiscomponent,andifnot,whytheyfailedtodoso.

Discussion

Eachpointoftheabovewillbediscussedandnewpossibleimprovementstotheprocessaresuggested.

Whatneedstobechanged?Howshoulditbechanged?Howwilltheimprovementsbetested?

The participants also discuss any open issues and countermeasures that arose in pastretrospective meetings. If the process was improved by addressing an issue through acountermeasure and succeeded in an improvement, the issue is closed. If the problempersists,itwillbeaddedtothediscussionlistagain.Themeetingleaderaddsalldiscussedpointstothewikimeetingpage.

AfterAssigningtasks

The product manager creates issues on the process issue tracker to add theseimprovementstotheprocessandassignsthemtohermembers.

Tests

HowtotestTestingisafundamentalpartofthesoftwaredevelopmentprocess.AtComerge,weviewtestingasacontinuousprocess that is tightly integrated intoourdailywork through thefollowingrules:

1. Neverreleasewithouttesting.2. Neverchangecodewithoutunittests(ifaunittestcanbedeveloped).3. Never implement a new feature without a unit test infrastructure to test the new

feature.

Testing comes in various flavors that complement each other. Using all of them incombinationensuresahighqualityendproduct.Thefollowingteststrategiesexist:

Unittest:Automatictestsexecutedbyanautomaticbuildsystem.Smoketest:Atestdocumentexecutedbyatester.Releasetest:Freestyletestingexecutedbyagroupoftestersdrivenbyatestplan.Acceptancetest:Endusersworkingwiththeproduct.

Asampletestplan

Atestplancontainsinstructionsonhowtotestallthenewfeaturesandalltheissuesthatwere implementedand fixedduring the iteration.The testplanassigns testers tocertainfeatures that should be tested. If in a later step a regression is found, the tester can becontactedtofindoutwhetheritalreadyexistedatthisstep.

HowtounittestWhenever a software developer implements a new enhancement or fixes a bug, thedevelopedcodeshouldbeaccompaniedbyaunittest.Asaconsequence,thetestsuitewillgrow together with the system’s source code base. The key goal of unit testing is toprevent regressions. Providing a well designed test case (or a set of test cases) for aparticularissuetogetherwithitsimplementationwillensurethatfuturebreakingchangestothecodewillbedetectedifthetestsuiteisrunregularly.Ofcourse,thequalityofthetestsuitedeterminesitsabilitytodetectbreakingchanges.Howtowritegoodtestsisanart by itself and goes beyond the scope of this process documentation.The process forresolving an issue anddeveloping the associatedunit test follows the schemedescribedbelow.

Takeabugoranenhancement

Asafirststep,thesoftwaredeveloperdecidesonanissuetoresolve.Thismaybeabugoranenhancement.

Writeaunittest

Beforeactuallyimplementingthefixorfeature,shewritesaunittesttestingthechanges.This is called test driven development.Writing unit tests before developing the sourcecodetoresolveanissueensuresthefollowingkeypoints:

Thedeveloperactuallywritesunittests.Without the code the unit tests fail and hence, unnecessary developments do notoccur.Thedesignofthecodemakesitpossibletowriteunittests.

Implementissue

Inathirdstep,shedevelopsthefixforthebugorimplementationofthefeature.

Commit

Oncetheunittestspasslocally,shecommitshercode.

Waitforbuildtosucceed

After the commit, an automatic build will run. If the build succeeds, the issue isconsideredasresolved.Ifthebuildfails,furtherimprovementsarenecessary.

Resolveasfixed

Inalaststep,theissue’sstateissettofixedandtheissuecanbeclosed.Thesourcecodehasbeenintegratedinthesoftwaresystemandtested.

HowtosmoketestThe goal of smoke testing is to find blocking issues before the customers or end usersreceive a build. The team lead appoints a smoke tester. The smoke tester is a teammember.Thesmoketesterusesthesmoketestdocumenttotestagivenbuild.Thesmoketestdocumentdescribestestsforallimportantfeaturesofthesoftwareandhence,ensuresthecorrectexecutionandusabilityofthosefeatures.Thefollowingsequenceofsteps,helpcarryoutasmoketest:

Takebuild

Asmoketestrequiresasoftwarebuildastestingobject.Asmoketestmaytestanykindofbuild,butmostcommonlyitisdoneonceaweektoverifyanintegrationbuild.

Smoketest

The smoke tester takes the smoke test document and tests the build. The smoke test isusually considered successful, if no blocking bug was discovered. Otherwise, thedevelopingteamneedstofixthefoundbugsandrepeatthesmoketestwithanewbuild.Foradefinitionofseverities,seeHowtoworkwithissues.

If a software runs on several different OS versions or as a web application on severaldifferentbrowsers,thesmoketesthastobeperformedatleastonthemostimportantOSandthemostimportantbrowsersthesoftwareisrunningontoensurequality.

Fixbugs

If thesmoke testerdiscoversablockerbug, itneeds tobefixed immediatelyandanewbuildisproducedafterthefix.

Asmoke testdocumentcontains storiesdescribinghow the smoke tester shoulduse thesoftware andwhat he shouldbe able to achieve.Typically, smoke test documentsgrowovertimetobecomelongdocumentsthatcovermostofthecorefeaturesofthesoftware.Writing smoke test documents also helps evaluate whether the software is easy tounderstand.

HowtotestareleaseThe goal of release testing is to ensure the high quality of new and existing features.Testingareleasemaytakeuptoseveraldays,butusuallyonedayisenough.Duringthesedays, thesourcecode isonlychanged ifablocking issueprevents testing.Asmoke testbefore release testingminimizes the likelihoodofhavingablocking issue in the releasecandidate.

Setupreleasecandidate

The release testers need access to a release candidate. For example, theymay need todownloadandinstallareleasecandidateontheirlocalmachine.

Choosetestitemfromtestplan

Everytesterhasasetoftestitemsassignedtohim.Hechoosesinwhichorderhewilltestthem,butthefinalgoalistocoverallassignedtestitems.Inafirststep,hechoosesoneofthetestitems.

Testthetestitem

Heteststheitembyfollowingthetestitemdescription.Themaingoalistomakethenewfeaturefailand/or tofindusability issues.The testercreatesanewissuereport foreachproblemhediscovers.

Marktesteditemsontestplan

After havingworked througha test item, the testermarks the itemas testedon the testplan.AtComerge,weprint thetestplan,pinit toawall,andall testersmarkwhattheyhavetestedonthissheet.Hethengoestothefirststepagainandteststhenextitemuntilnoneofhisitemsareuntestedanymore.

Ensureallitemstested

Theproductmanagerensuresthatallitemsfromthetestplanhavebeentested.Todoso,shecheckswhether the testershavemarkedallassignedtest itemsas“done”onthe testplan.

Improvesmoketestdocument

Sometestitemsfromthetestplancanbecomepartofthesmoketestdocument.Theteamleadassignsateammemberresponsibleforupdatingthesmoketestdocument.

HowtodoacceptancetestingThe goal of acceptance testing is to find out whether a product fulfills the users’requirementsandexpectations.Inparticular,acceptancetestingfocusesontheusabilityofthe final product and makes sure that the intended users of the product are able toefficientlyworkwiththeproduct.Thetestingobjectisalwaysarelease.

Organizetestusers

Foracceptancetesting,thetestersneedtobepartofthegroupoftheproduct’sendusers.Usually,thecustomerorganizestheavailabilityoftestersforacceptancetests.

Createrelease

Thedevelopmentteamprovidesareleaseastestingobject.SeeHowtocreatearelease.

Instructtestusers

It isunlikely that the testersofanacceptance testhaveworkedwith theproductbefore.Thus, they need clear instructions on several properties of the product and the testingprocedure,covering

whattheycanexpectfromthesoftwarewhattheycannotexpectfromthesoftwarehowtheyshouldcarryoutthetestswhattheyshouldtesthowtheycanprovidefeedback

Lettestuserstestrelease

Theacceptance testingdurationmaybeset toseveraldays.During this time, the testersmayindividuallytestthesoftware.

Collectandprocessfeedback

Themostimportantstepintheacceptancetestingprocessistocollectasmuchfeedbackas possible from the testers. The development team then creates issues based on thetesters’feedback.

Customers

HowtoworkwithcustomersManycustomersarenotfamiliarwiththemethodologyofagilesoftwaredevelopmentandare,inconsequence,oftensurprisedbytheextentoftheirinvolvementthatisexpectedofthemduringthedevelopmentphase.Constantexchangeandcommunicationare,however,a key factor for progressing in the desired direction even if voids in specifications arediscovered or if requirements are changed or extended. The following sections list anumberofprovenmeasuresforhandlingrelationshipswithcustomersandforfunctionalcommunicationinterfaces:

Infrastructureforcommunicationwiththecustomer

A shared issue tracking platform provides an effective means for organizing workpackages, filing bugs and feature requests and allows to document decisions and storedocumentsinarelevantway.Itisimportanttoreachacommonunderstandingonhowtousethisplatform.Again,manycustomersarenotfamiliarwithusingsuchaplatformasprimaryformforwrittencommunication.

Theuseofasharedcalendarhelpsorganizemeetings,synchronizeprojectdeadlines,andprovidesinformationontheavailabilityoftheinvolvedparties(e.g.,holidays).

Discussionsaremostefficientlyconductedbytalkingtoeachother,sofavorphonecallsorface-to-facemeetingsoverwritingemails.

Understandingthecustomer

Understanding the joband the ideasof thecustomer in itsentirety isaprecondition forsuccessfulprojectcompletion.Exposingthedevelopmentteamasmuchaspossibletothecustomer’s business, for example by organizing visits to the customer, may help toidentifyhowsoftwarecanimprovetheprocessesofthecustomer.Theclearerthebusinessistothedevelopmentteam,thebettertheendproductwillfitthecustomer’sneeds.

Anotherwaytodevelopanunderstandingfortheneedsandideasofthecustomeristoaskhimforstoriesdescribingwhatheseekstoaccomplishwiththesoftware.

Whencustomersdosoftwaretesting,itisimportanttoacknowledgethattheytypicallyarenotprofessionaltesters.Theunderstandingthatfindingissuesisgood,notbad,doesnotcomenaturallyandshouldbeemphasized.Support thecustomer infiling issues thataremeaningfultothedevelopmentteam.

The answer to a customer request or a decision should never be “this won’t work”.Instead,thelineofargumentationshouldshowconsequencesofdecisions.Consequencescanalwaysbefoundinthetriangle:time,costsandfunctionality(orquality)andcanhelpthecustomertounderstandtheimplicationsofadecision.

Basesfordiscussionswiththecustomer

The productmanager holds a weekly conference call (during critical phases alsomoreoften) with the project leaders of the customer. Additional participants can be invitedwhenthismakessense.Allparticipantspreparediscussionpoints,ideallybymeansofanagendathatisdistributedbeforehand.Decisionscanbetakenimmediatelyandshouldbedocumentedintheformofissuesandpossiblymeetingminutes.

Amonthlycontrollingmeetingwiththepeopleinchargeatthecustomerservestoinformthemandtomarkettheproject.

HowtodocustomersupportContractswithcustomersmaynotonlyinvolvesoftware,butalsosoftwareservices.Aftera product is released and used productively by the customer, support questions and/orsituationsmayarise.Thispageservesasaguideforplanningandprovidingsuchsupportservices.

Infrastructure: All projects requiring/offering support to customers must address thefollowingissues:

Separationofsupporttiers(“1st/2ndlevelsupport”).Timetabletocoversupporttimespanandresponsibilities.Email infrastructure:Often, thecustomerwilluseothercommunicationchannels toreportanincidentorseeksupportthanwedo,forexamplebecauseheusesanothersystem internally. An automated email system serves as an interface betweencustomers seeking support, support staff, and management (forbookkeeping/invoicing).

ExampletiersThisexampleexplainsthetiersetupbetweenComergeandafictionalcompany“Initech”.Itillustratesthenotionofsupporttiersanddescribesapossiblesetup.

1stlevel

EmployeesofInitechat theirofficeinGenevaprovide1st levelsupport toallconnectedstakeholders,i.e.,tradersand/ormanagementofaffiliatedbanks.

1st level support is the main interface for stakeholders, all support requests arechanneledthroughit.When initializing any support activity, a ticket is opened. This serves to trackprogress, findings, communication, and time (e.g., for bookkeeping data) for allparties.1stlevelsupportactsdirectlyonallsupportrequeststhatcanbeprocessedgiventheirtools,specifically

GeneralquestionsActionsinvolvingtheback-endrichclient

Actions requiring further assistance are escalated to 2nd level support using thesupporttickets,e.g.,directlychangingdatabasevalues,etc.The telephone hotline at Comerge serves as a red phone for urgent assistancerequiringimmediateactions.

2ndlevel

Comergeprovides2ndlevelsupportforInitech.

It reacts on incoming support tickets within reasonable time depending on theirpriority.Supportticketsmaybeanswered/actedonoutsideofthehotlinehours.Comergeprovidestelephonesupportforurgentproblems.Thishotlineisguaranteedtobeactiveduringthearrangedhours.2nd levelsupporthasfullaccesstoallsystems,andthereforehandlesanyproblemsrequiring direct manipulation of these systems’ software, i.e., all applicationsbelongingtotheInitechsystem.

Glossary

GlossaryA

Acceptancetest:Acceptance tests aredoneby thepeoplewhoarepartof the finalendusergroupoftheproduct.

Assignedissue:An issuecanbeassigned toa teammember.Suchan issue iscalledanassignedissue.Iftheissueisassignedtoateammemberitisexpected,thattheassigneeresolvestheissue.Onlyanassignedandplannedissuecanbefixed.

B

Build:Theresultofbuilding.Thereareanumberofdifferentkindofbuilds:

Continuous build: A build which runs “all the time”. Usually, such a build isautomatically triggered whenever the build machine detects a code change. Thisbuildistestedbyunittestsonly.Integration build: A build which integrates code changes from multiple teams.Usually,takesplaceonceaweekandistestedbyunittestsandsmoketests.Milestone build: The build which results from amilestone. Usually, takes placeevery5weeksandistestedunittests,smoketests,andreleasetests.

Building:Theprocessofconvertingsourcecode files intostandalonesoftwareartifactsthatcanberunonacomputer.

Blocker:Anissuewithseverityblocker.Seeseverityfordetails.

C

Criticalissue:Anissuewhichhasatleastaseverityofcritical.Seeseverityfordetails.

Code owner: The developer who is responsible for a portion of the source code.Frequently,thecodeowneristhedeveloperwhowrotethecodeinthefirstplace.Butovertime, theownershipofcodecanchange.Thecodeowner is responsible tomaintain theowned code. The code owner is also the expert for the owned code. It is considered aviolationofthenetiquetteifsomeonechangescodehe/shedoesnotownwithoutapprovalofthecodeowner.

Component: One part of a product. Usually, a team owns several components. Thecomponentowner is responsibleformaintaining thecomponent.Splittingaproduct intocomponents such that the components can be developed in parallel by several teams isdifficult.ItiscommonpracticetosplitaproductatleastintoacoreandaUIcomponent.The core component provides themodel (data) and the UI component provides a userinterface,whichallowstopresentandmodifythemodel.

Continuousbuild:Onetypeofabuild.Seebuildfordetails.

Customer:Acustomerisaprocessrole.

D

Decompression phase: The time after a release in which the pressure on the teammembers isminimized togive them time to recoverand spend timeon thingswith lowpriority.

Duplicateissue:Anissuewhichisaduplicateofanotherissue.Thismeansthattheexactsameissuewasreportedbefore.Suchissuesareresolvedasduplicate.

Dooropener:Apersonyouinteractwithduring thesalesprocess. Inoder tobeable totalk toapotentialbuyer,youneed toget to them.Adooropener isaperson fromyournetworkwhointroducesyoutothepotentialbuyeroratleastcanhelpyoutogetameetingwiththem.

F

Filedagainst:Anissuecanbefiledagainstateam.Thismeans,thattheissueisownedbythe teamand theowning team is responsible toeither resolve the issue or file it againstanother team.The team owning the code causing the issue shouldown the issue in theend.

Fixday:Adayduringwhichonlybugsarefixed.

Feature: A feature is a function of the software to be created. All features togetherconstitutetheproduct.

G

Gatekeeper:Apersonwhocontrolsaccesstoaresourceyouwishtoacquireorapersonyouwish to interactwith. In the salesprocess, agatekeeper typically stands in thewaybetweenyouandapotentialbuyeryouwanttocontact.

I

Integrationbuild:Onetypeofabuild.Seebuildfordetails.

Inbox:Allissueswithstatenewareconsideredtobepartoftheinbox.Besidestheglobalinboxeachcomponentalsohasaninbox.Anewissuecanbeassignedtoacomponent tobecomepartoftheassignedcomponent’sinbox.

Inboxtriager:Theoneresponsibletotriageissuesfromacomponent’sinbox.SeeHowtotriageissuesfordetails.

Issue:Somethingtodo.Itiseitherabugtofix,oranenhancementtoimplement.Anissuehasanissuestate,aseverityandapriority.

Issueowner:Theownerofanissue.Itistheonewhichisassignedtotheissue.Seealsoassignedissue.

Issuereport:Thereportofanissue.Usuallyissuesarereportedinwrittenformusinganissuetracker.

Issuestate:Anissuehasexactlyonestate.ForalistofallpossiblestatesrefertoHowtoworkwithissues.

Issuetracker:Asoftwarewhichcanbeusedtoreportandtrackissues.Wellknownissuetrackersystemsarebugzilla,Trac,JIRA,andOrigo.

Issuetriage:Triagemeans to take somethingandput it into thecorrectplace,where itbelongs.Foranissuethismeansthattheissueiseitherresolvedand/orassignedtoateamand/oratarget.SeeHowtotriageissuesfordetails.

Iteration:One cycle in the releaseprocess.Usually an iteration is 5weeks long.Eachiterationhas3phases:

Planning:2–3DaysImplementing:~4weeksTesting:1week,seeHowtoplanaprojectfordetails.

M

Milestone:Amilestoneeitherreferstoaniterationortoamilestonebuilddependingonthecontext.

Milestonebuild:Seebuilds.

N

Netiquette:Implicitruleswithinaproject/processculturewhicheveryparticipantshouldfollow.Aviolationofthenetiquettemightbeconsideredanoffensebyotherparticipants.Followingisanincompletelistofthingsnottodo:

Donotchangecodeyoudon’town.Donotcommitcodewhichdoesnotcompile.Donotbypasstheteamlead.Donotcloseissuesaswon’tfixunlessyouhaveareallygoodreasontodoso.

New and Noteworthy: A document, usually a web page, describing all the new andnoteworthy features of a release of a product. The idea is to give your users a quickoverviewofwhatcouldbeofinteresttothem.

P

Plannedissue:Anissueassignedtoareleaseisconsideredaplannedissue.Iftheissueisassignedtoarelease,itisexpectedthattheissueisfixedwithintheassignedrelease.Onlyissueswhichareplannedandassignedcanbefixed.

Priority:Anissuecanhaveapriorityassigned.SeeHowtoworkwithissuesfordetailsaboutpriorities.

Product:Thesoftwaretobecreated.Thesumofallfeatures.

Productrelease:Thefinalrelease.

Productmanager:Aproductmanagerisaprocessrole.

Process:Activitiesortasksthatproduceaspecificserviceorproductforacustomer.Theprocessdescribeshowtheentitieswhichparticipateinaprojectcooperatetocreateoneorseveralproducts.

Processrole:Differentroleswithinaprocess,seeProcessroles.

Project:Thegoalofaprojectistocreateoneorseveralproductsusingaprocess.

R

Regression: If a code change introduces a new bug this bug is called a regression.Somethingwhichusedtoworkisnowbroken.

Release:Atestedbuild.Theresultofaniteration.

Releasecandidate:Apossiblerelease.Thereleasecandidateistestedtodecideifithasthequalitytoqualifyasarelease.SeeHowtocreateareleasefordetails.

Releasetest:Releasetestinghappensduringthereleaseweek,beforetheproductisgivento the customers for acceptance testing. Its goal is to ensure a high release candidatequality.

Reopenissue:Theprocessofchangingafixedissue’sstatebacktotriagedoropened.

Reporter:Theonewhoreportedanissue.

Requirement:Somethingwhichisrequiredforaproducttomakearelease.Theproductmanagerisresponsibleinidentifyingthisrequirementtogetherwiththecustomer.

Resolveissue:Theprocessofchangingthestateofanissuetoresolved.

Resolved:Astateofanissue.Seeissuefordetails.

Resolution: Several different causes can change the state of an issue to the final statesresolved,closed, orverified. SeeHow toworkwith issues for a list of all the possibleresolutions.

Review:Acodechange is checkedbyaprogrammerother than theonewhowrote thecodechange.Usually,thispeerreviewhappensbeforethecodechangeisreleasedintothesourcerepository.Thegoalofareviewisthatthereleasedcodehashighqualityanddoesnotintroducearegression.

Role:Seeprocessrole.

S

Severity:Abugcanhavedifferentlevelsofseverities.Anenhancementhasnoseverity,butapriority.SeeHowtoworkwithissuesfordetailsaboutseverities.

Signing off a build: The team leads and the productmanager can sign off a build. Ifeverybodyhassignedoffthebuild,itisreleasedandthenextiterationstarts.

Smoketest:Asmoketestisdonebeforeabuildisgiventoacustomerformoreextensivetesting and has the purpose of making sure that it will not catastrophically fail. Oftensmoke tests aremanual executions of themost important operations. For example, in areservationsystemthiswouldincludecreating,editing,andcancelingreservations.

Stakeholder: Everyone interested in a product: team member, team lead, productmanager,customer.

T

Team:Asetofteammembers.Everyteamhasateamlead.

Teamlead:Ateamleadisaprocessrole.

Teamleader:Seeteamlead.

Teammember:Ateammemberisaprocessrole.

Testday:Duringthetestdayareleasecandidateistested.Nocodeischangedunlessitisrequiredtoresolveablocker.

Testplan:Thetestplancontainsatleastwhotestswhatonwhichsystem.Forexample:BennotestseditimageonFirefox3.5.SeeHowtotestformoredetails.

U

Unittest:Aunittestchecksanindividualunitofthesourcecodeusingtestdatatofindoutifitisfitforuse.Aunitcanbesinglemethodsoraninterface.Unittestsshouldalwaysbeindependentfromotherunittests,sothattheycanberunindividually,inparallel,orinsequence.

User:Theoneusingtheproduct.

Usererror:Amistakemadebyauserwhichmightlooklikeanissueatfirstglance.Suchissues,ifreported,areusuallyresolvedasworksforme.

V

Verified:Anissuestateandresolution.Seeissuefordetails.

Verifyissue:Theprocessofchangingthestateofanissuetoverified.Theverifiertriestoreproducetheissue–ifhecannot,theissueisconsideredverified.

Verifyfix:Thesameasverifyissue.

W

Won’tfix:Anissuewhichwillnotbefixed.Itisoneoftheresolutionstatesofanissue.

Worksforme:Anissuethatcannotbereproduced.

ComergeAGBubenbergstrasse18045ZurichSwitzerland

Tel:+41435013838Fax:+41435013839

Email:info@comerge.net

http://www.comerge.net

TableofContentsCo-Pilot

ImpressumPrefacetothefirsteditionPrefacetothesecondeditionPrefacetotheebookeditionOurvaluesHowtoread

Projects

ProcessrolesHowtoplanaprojectHowtoiterateHowtoworkwithissuesHowtotriageissuesHowtoplanareleaseweekHowtocreateareleaseHowtoreviewissuesHowtouseGitHowtotracktime

Meetings

HowtoholdameetingHowtoholdaScrummeetingHowtoparticipateinacoremeetingHowtoholdaretrospectivemeeting

Tests

HowtotestHowtounittestHowtosmoketestHowtotestareleaseHowtodoacceptancetesting

Customers

HowtoworkwithcustomersHowtodocustomersupport

Glossary

Glossary