• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Intro to agile
 

Intro to agile

on

  • 1,327 views

Introduction to what Agile development is, what it isn't, recommendations and the common pitfalls.

Introduction to what Agile development is, what it isn't, recommendations and the common pitfalls.

Statistics

Views

Total Views
1,327
Views on SlideShare
808
Embed Views
519

Actions

Likes
0
Downloads
6
Comments
0

3 Embeds 519

http://www.tigerteam.dk 510
http://localhost 8
http://trimm.tigerteam.dk 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 45minutterermegetkorttidtil at fortælleom Agile, sådeteressensenaf Agile vi tager fat på.Deterumuligt at kommetil bunds I emnetpåsåkorttid
  • Man kanvistnemtsige at folk der dyrker agile på den mådeer clueless
  • Hvorforændrepånoget vi alleredekender? Allekanjoforstå at vi arbejder I faserogleverertilsidstTest ervores buffer tilsidstsom vi kanbrugetil mere udviklingKraverfrossetgennemforløbet, sådet vi leverervardet vi gernevill ha’ haft for 2 årsidenÆndringerblirtilundtagelserogsvære at håndtereVi kanikke lade tidenståstilleogglemmeverdenomkringos. DetfungererikkeAlleer 80% færdige I 80% aftidenMan kanikkestoppemidt I et projektfordiinteterheltfærdigtførprojekteterfærdigtWW Royce – manden der beskrevVandfaldsmodellen, som et eksempelpå en risikofyldt model, foreslogselviterativudviklingsomløsningen.
  • Der er et STORT OVERHEAD - Typical developer estimates are multiplied by a factor of 3 to 6 to give the actual time spent
  • Hvadergrundenetil at vi vil ha Agile? Der er mange flere end dem her. F.eks:Minimer overhead - Brugtidenpådet der ervigtigt
  • Baggrund for the Agile Manifesto. The Agile Principles vilikkeblivegennemgået I dag
  • Devigtigeorder med orange kant:Uncovering: Deternoget vi finder udafudfravoreserfaring. Der erikke en måde der altidfungererDoing it: Detbyggerpåpraktiskerfaringog vi indarbejdererfaringerneHelping: “Vi ersammenomdet her, Mulle”. Vi skalhjælpeandre for at vi tilsammenkanblivebedreOver: Der står “at detvejertungere!!! Der stårikke “erstatter” eller “I stedet for”
  • Agileskulleegentligt have heddet Adaptive men Jim Highsmithhavdealleredeudgivet en bog der hedder “Adaptive Software Development”Jegsynsselv at deter en vigtig pointe og at det passer bedre end Agile
  • Derer 2 store “Spillere” pådet agile metodeområde. Scrum og XPBåde XP og Scrum erlavpraktiskeprincipper der harbevist sit værdogsomsåerblevetbeskrevetog sat I system
  • En storfordelvedletvægtsprocesser - som XP - er, at de erlette at forstå. Derforbrugerprojektermindreenergipå at bekymre sig omprocessen. Ogderforharprojekterne mere overskudtil at tænkepåbrugerneskravogdet system, de udvikler.Figurenheroverviser et XP-projekt:Brugerneskriverdereskravsom “stories” på “story-cards”Med disse story-cards som basis giver teametnogleestimater - og laver en plan (bare en plan-skitse - for planenbliversikkertændretalligevel)Baseretpå stories vilteametgradvistdiskuterekraveneistørreogstørredetalje - parallelt med, at du udviklersystemet. Hvis (når!) der opstårtvivlogspørgsmål - så vender udviklerne sig omogspørgerbrugeren, somsidderved et skrivebordisamme rum, sammen med udviklerne.Efterhåndensomsystemudviklingenskriderfrem - ogbrugernebegynder at se deres system tage form - kommerbrugerne med nye stories ogændringertileksisterende stories, somudviklernetagerimod
  • ”The Planning Game” er en session, somudføresifællesskabafbrugereogudviklere. Brugerneskriverderes stories, udviklernespørgerogfårsvar, udviklerneestimerer, brugerneprioriterer, ogplanenudarbejdesifællesskab.Small Releases betyder, at der udviklesikorteiterationer - og at nyeversionerigangsættesofte. F.eks. Hver 14. dag - ellerhvermåned.En Metaphor kanbrugestil at fåideertil at kiggepåsystemet med andreøjne. F.eks. kan man tænkepå et fly-booking system, hvis man erved at udvikle et tog-booking system.Simple Design: Lav kun enkleløsninger! Og kun til at håndtere de stories vi kender nu! Al kode, der tager sig afevt. udvidedekrav, tilføjerunødigkompleksitetogvilmuligvisaldrigblivebrugt.Testing: Der arbejdes med automatiserede tests - og med at definere sine tests før man udvikler en ny stump kode.Refactoring er re-design afkoden, hvisdesignetikkeunderstøtter den nyefunktionalitet, man skaltil at udvikle. Ved at gennemførealle tests kan man sikre sig, at alt stadigvirker.Pair Programming foregårved, at man altider to om en skærm, når der programmeres. Den eneskriver, den anden ”tænker” - ogparretdiskutererlystigt. Giver kodeafvæsentlighøjerekvalitet.Collective Ownership betyder, at alleerfællesom at ”eje” al kode.Continous Integration betyder, at al nyfunktionalitet ”checkesind” isystemeti et miljø, der tilstadighedbådeerkørende - ogsamtidigindeholder alt, der erlavettildato.40-hour week: Når vi ertrætte, laver vi fejl. Fejlsomtageroceaneraftid at findeogrette. Derforarbejder vi ikke, når vi ertrætte.On-site Customer: Brugerenerkonstantogheletidentilstedeiprojektlokalet, såudviklernealtidkanfåsvarpåderesspørgsmål - Prompte!Coding Standard: Fællesejerskabtil al kodeforudsætter en visensartethed, så man ikkeførstskaltil at sætte sig indandresprogrammeringsstil.
  • Scrum er for projektlederehvor XP ermerudviklerrettet
  • Scrumog XP byggerpåpraktiskerfaringoghvad der virker. Deterformaliseret best practicesVIGTIGT: Scrum, XP og RUP udelukkerikkehinanden. De kankomplereterehinandenpåglimrende vis.Rup harfasernesom man ofteglemmer I de andremodellerXP sigerintetomstyringafprojektetScrum sigerintetomhvordan man udviklerRUP har et dokumentsæt man kantageudgangspunkt IRup sigerintetomhvordan man skalstyre et projektlavpraktisk. Her kommer SCRUM indRUP’s faser passer fintind I en PRINCE2 model
  • Skill: We all need to become more professional. Management needs to understand what they’re trying to manage and developers need to give proper feedback and not only resort to complaining or choosing framework/tools for the fun of it Close contract: Walk the talkAutomation: Continous Integration, Testing, Deployment, Code generation
  • Der errigitgt mange måder at fejlepå.
  • Agile og Lean er symptom behandlinger!

Intro to agile Intro to agile Presentation Transcript

  • Introduction to AGILE 31. March 2011Jeppe Cramon – jeppe@tigerteam.dk
  • Does this sound familiar?• “We are doing Agile so we”: • Do not Document • Do not handle and register Requirements • Do not do formalized testing • Do not plan more than 2 days in advance • Do not follow up on expenses and economy • Do not ____________________ (Fill in yourself)
  • From the movie “Clueless”
  • Same procedure as last year?“Even a dead fish can float down a waterfall”
  • Can 9 women deliver a baby in 1 month? • More developers on a project decreases developer efficiency – Communication overhead – More ceremony (Documents and Process) • Close contact with product owner and business experts leads to effective developers • Writing code typically only amounts to 30% of the total project time
  • Why Agile?• Focus on the Business and what they need• Focus on delivering quality• Doing the “right thing” – not just doing things right• Get feed-back often and act on it• Work on things that directly improves the end result• Minimize overhead Do what we are paid for as Developers!
  • We need an Agile Machine!
  • Who?• Take 17 IT gurus: – Kent Beck, Alistair Cockburn, Martin Fowler,… – Add them to a ski resort in Utah• Let them simmer for 2 days: – February 11-13 2001• You can now serve: – The Agile Manifesto, The Agile Principles – Agile Software Development Alliance
  • What? The Agile ManifestoWe are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
  • According to the Oxford Dictionary• Agile – “Able to move Quickly and Easily” – “Able to think Quickly and in an Intelligent way”• Adaptive – “Concerned with Change” – “Able to change when necessary in order to deal with different situations”
  • Can be?Confusing Unified Process XP Scrum AGILE Sterile Virile Lean
  • eXtreme Programming (XP) Iteration Plan Iterations plan System!!! ”Stories” Stories User Bruger Whiteboard Whiteboards Developer UdviklereEngineering Practices Kommunikation og samarbejde
  • XP Practices• The Planning Game • Pair Programming• Small Releases • Collective Ownership• Metaphor • Continuous Integration• Simple Design • Normal work week• Testing • On-site Customer• Refactoring • Coding Standards
  • ScrumProject Management Practices
  • Scrum Practices• Self managed teams • Estimates are made by those• 30 days iterations, Sprints who will do the actual work• Daily Scrum meetings • All contact to the project is via• All participates in Planning the Scrum Master• User Stories becomes Tasks • Teams on max 10 people• Customer on site – Product Owner • Everyone is in the same room• Tasks are not assigned but chosen • Use of Sprint and Product• The Scrum Master is not “just” Backlogs and burndown charts project manager • “Pigs and Chickens”
  • How they compare? Waterfall(One iteration) Iterations Few Documents Many Documents Little Ceremony High Ceremony Ceremoni Scrum Unified Process XP Many short IterationsSource: Craig Larman: Agile & Iterative development, a managers guide
  • So, What’s next?
  • Please…..• Agile is not a solution. It’s a tool! – Focus on your problems and how to solve them• There is no such thing as an Agile process! – Agile is a way of thinking and not a product• You HAVE to work Iteratively to become Agile – The only way to get feedback from our Customers• Trust in people – Agile is Trust over Control
  • Pretty Please……..• Apply your learnings iteratively – It’s the least expensive way• Pick the right tools for the right job• Use proper test approaches to ensure quality. – This helps you discover when new learning’s break old assumptions• Focus on importance and criticality
  • With sugar on top…….We need:• Smaller teams (5-10 people)• More skilled developers and managers• Close contact to Product owner and Business Experts• Higher level of Abstraction• High degree of Automation• Shorter feedback cycles• Make it cheaper to make mistakes and learn from it
  • Excerpts from a 3 hour seminar on how to fail with Agile and Iterative Development
  • Failing with Iterations• Waterfall iterations – “Analysis iteration”, “Design Iteration”….• Remember to minimize technical risks early• A time box has a fixed length – Max 1 month! Longer than that it’s no longer an iteration – Do not extend an iteration. Take things out!• Done is Done! – Done is including TEST! No hidden work• Changes are a part of the process. Not an exception
  • Failing on a Management level• Unclear goals. What are we trying to achieve?• Method = Product – Buy a license and a consultant, then we are OK• Isolate Agile to one project alone• Going Agile is an iterative a process in itself• Use traditional follow-up and management processes• You will NOT get pay-off from the day one
  • Failing on a larger scale• Agile affects the whole organization – Users, business, management, test, deployment,..• Understand what you do. Try before dissing – Scrum Buts: “We use Scrum, but……”• Be pragmatic and proactive – Focus on results and not on following the book
  • What to do?• Communication, communication, … – Make sure to involve people in the process – Listen, Learn and Adapt – Implement iteratively and actively by doing!• Have realistic goals. Short and long term• Accept changes – “Only 10% of what you worry about will ever happen”• Get professional help
  • How to supercharge AgilityA “radical” shift – to a larger degree of automation 
  • Lean & AgileAre both treatmenting Symptoms not providing a cure!
  • We can’t control everythingRather than focus on being Agile which may lead to beingsuccessful, focus on being successful, which may lead you to being Agile
  • ThanksFor more informationjeppe@tigerteam.dk or @jeppec on Twitter