We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byBrooke Maldonado
Modified over 3 years ago
© Connextra 2003 John Nolan & Rachel Davies XP @ Connextra
© Connextra 2003 The Connextra Story Web technology company products & services: – Sidewize bar – Active Ad workbench Established in May 1999 on XP principles – Development team assembled by John Nolan & Tim Mackinnon See http://www.connextra.com
© Connextra 2003 XP was a good fit for us XP is a lightweight methodology for small to medium sized teams developing software in the face of vague or rapidly changing requirements. Extreme Programming Explained - Kent Beck (Addison Wesley 2000)
© Connextra 2003 We used all the XP Practices Planning game Small releases Simple Design Testing – Unit – Functional – Test First Refactoring Pair Programming Collective Ownership Continuous Integration Sustainable Pace Onsite Customer Coding Standards Metaphor
© Connextra 2003 Reinforcing Practices
© Connextra 2003 Customer team XP customer, our Marketing team Reponsible for: – product direction – budgets – sales forecasts – direct sales – account management Team size: varied from 3 to 6 members
© Connextra 2003 Development team Responsible for: – software development – testing – web design – client support – infrastructure (servers/deployment) Team size: grew to 12 in first year - scaled back to maintenance team of 4 in Apr'03 Staff Retention: over 3 years only 3 developers left after a year but 1 came back
© Connextra 2003 Recruitment Hired XP compatible people comfortable with our practices: – No comments in code – Collective ownership – Pairing Candidates paired with us for half a day
© Connextra 2003 Release Planning Domain: Disruptive technology – new market, new product, no direct competitors – as we learned about the market we focussed on specific market sectors based on earned value Strategy: develop specific stories to learn about client needs then provide generic toolkit support for same functionality Frequency: Quarterly brainstorm meetings were held to generate new product stories – Some Product Development stories were selected per month – Other stories were specific services per client generated as a result of client meetings
© Connextra 2003 Iteration Planning Monday morning, company standup meeting, followed by Customer team meeting – to list of stories (on flipchart paper) for this week and next week with ranking (1,2,3..) and any deadlines marked Velocity metric for iteration just finished is calculated After lunch, Developers assemble for collective estimating of all cards on the table – Quick overview of the commercial priorities from Customer team for Developers – Estimates (in ideal days) for stories on table agreed by group Decomposition for complex stories Main tasks per story noted on index cards Developers explain estimates to Customer team, who make final cut bounded by measured velocity
© Connextra 2003 Writing Stories Stories are tokens for a conversation between Customer and Dev Written on index cards Useful format: As I want so that Also title, author, date of writing Avoid implementation details
© Connextra 2003 Completion Criteria Reliable estimates cannot be given if scope is not clear Acceptance tests defined by the Customer upfront, so that you can determine when the implementation is complete ResultAction The sports service displays links for players on that page Visit the Arsenal home page
© Connextra 2003 Tracking Measure your velocity – Total of story estimates completed in an iteration Recorded on internal wiki web Iterations of fixed duration make it easier to compare Load Factor is depracated
© Connextra 2003 Visible Feedback Visible iteration plan – Story and Task Cards pinned on a pinboard create a wall Gantt Coloured stickers are used to indicate progress on tasks in iteration plan – Red for unfinished – Yellow for development complete – Green for customer accepted
© Connextra 2003 Standups Standup Checkov – What happened yesterday? – Any new cards? – Any meetings? – Whos exposed? – Mark time spent – Whos pairing with who? If you cant keep it under 15 mins use a kitchen timer!
© Connextra 2003 Selecting pairs Worked through iteration stories in priority order No story owners Team select tasks and form pairs based on previous work and preference using a pair rotation rule as a guide A+B -> B+C -> C+D.. Team lead only step in where problems arise
© Connextra 2003 Simple Design and Refactoring Refactoring: A series of small steps, each of which changes the programs internal structure without changing its external behaviour Simple Design – Code for present needs – Remove redundant code Keeping the codebase tidy makes it more malleable IDE support helps! Connextra used IBM VisualAge for Java at the start but migrated to Eclipse to take advantage of the tool support for refactoring like extract method, etc.
© Connextra 2003 Collective Ownership Modules are owned by the team not by individuals Everyone has the right to check out and modify any code (in a pair) – Things are fixed when they are found All programmers are familiar with all of the code – Bus Factor of: n-1 – Team can accept absences No-one can be identified to a piece of code – Eliminates a blame culture
© Connextra 2003 Coding Standards Team agrees on a set of coding standards they adhere to – Reached by consensus – Everyone agrees to follow them – No reformatting according to individual tastes! Same development tools and preferences on each workstation – Any person can pair equally well on any machine Developers May Find This Hard – Explain advantages of collective ownership and lack of blame culture
© Connextra 2003 Pair Programming All code written in pairs at a single workstation – Convex desks – Large screens Each developer has a locker and adjustable chair but no desk Developers take turns to drive Pairs work together for less than a day
© Connextra 2003 Continuous integration Nightly builds are for wimps (Kent Beck) – We build and integrate hourly Reduces interface mismatch Reduces the impact of collisions – Only a small amount of code has changed – Everyone remembers what they have done The sooner code is integrated the sooner many pairs of eyes will refactor and simplify it
© Connextra 2003 Testing Test should be automated – Xunit framework Levels of Testing – Unit – Acceptance/Functional Test first design – Test cases are written before the code – forces us to design the code from a clients point of view Mock objects
© Connextra 2003 Metaphor The architecture is captured by a system metaphor – a simple shared story of how the whole system works which guides development Example: – C3 Payroll System was like an assembly line with parts and bins – Calculations were moved from bin to bin
© Connextra 2003 40 hour week Pair programming is very intense and tiring. Typical day: 09:15 - 09:30 arrive / time for emails 09:45 - 10:00 standup team meeting 10:00 - 12:30 paired development 12:30 - 14:00 lunch (often eaten together) 14:00 - 17:30 paired development
© Connextra 2003 Retrospectives The team looks back on a past period of work so that they can learn from their experience and apply this learning to future projects Started using Retrospectives after talking to RoleModel Software at XP2001 Retrospectives helped us to improve our process: – Communication both inside and outside the company Improved Planning Game, Standup meetings Client Support – Our development environment Language, IDE, OS
© Connextra 2003 Why hold a Retrospective? To reflect and learn from the past To decide how the team will work in the future To improve communication within the team To allow a team to own and drive their development process
© Connextra 2003 Innovation A Gold Card is reserved time for learning and exploration XP Perspectives 2002 Index Card with a gold star on it! – Entitles developer to 1 day of work on new ideas – 2 cards per month – Developer chooses when to use them – Demonstrated at weekly Show & Tell Resulted in new product features, development tool improvements and motivated team
© Connextra 2003 Food and Toys A kitchen where we could prepare food and eat together Developers lunch at local cafe Bar downstairs Tacky gifts
An Introduction to eXtreme Programming Michael L. Collard, Ph.D. Department of Computer Science Kent State University.
Extreme Programming Mark Steverson. What Is Extreme Programming? ● Extreme Programming (XP) is a lightweight, agile methodology developed by Kent Beck.
© Connextra 2001: delivering the right information to the right people at the right time© eXtreme Tuesday Club 2003 Rachel Davies Retrospectives Reflect.
Extreme Programming Based on and
One XP Experience: Introducing Agile (XP) Software Development into a Culture that is Willing but not Ready Joe Bergin * Fred Grossman * David Leip **
Extreme Programming מתודולוגיה לפיתוח פרויקטי תוכנה.
1 e X treme P rogramming D. Dranidis September 2000 CITY College.
CS223: Software Engineering Lecture 18: The XP. Recap Introduction to Agile Methodology Customer centric approach Issues of Agile methodology Where to.
Extreme Programming Daniel Baranowski 3/29/06. What is Extreme Programming? An agile development methodology Created by Kent Beck in the mid 1990’s A.
1 김 수 동 Dept. of Computer Science Soongsil University Tel Fax
Extreme programming (XP) Advanced Software Engineering Dr Nuha El-Khalili.
XP (not Microsoft) e X treme P rogramming Can KOMAR
December Using Software Development Methodology (SDM) in the Third Teaching Unit (laboratory) CS Teachers Conference Dr. Orit Hazzan & Yael Dubinsky.
Agile and XP Development Dan Fleck 2008 Dan Fleck 2008.
Agile Software Development کاری از : مهدی هوشان استاد راهنما : استاد آدابی.
Software Engineering Process - II 5.1 Unit 5: Alternate Software Development Methodologies Software Engineering Process - II.
Extreme Programming Alexander Kanavin Lappeenranta University of Technology.
Sofia Bulgaria Summer School IST eXPERT: Best Practice on e-Project Development 30 June - 2 July 2003 eXtreme programming.
Coming up: What is Agile? XP Development Dan Fleck 2010 Dan Fleck 2010.
AP-1 4. Agile Processes. AP-2 Agile Processes Focus on creating a working system Different attitude on measuring progress XP Scrum.
Chapter 3 Agile Software Development (1/2) Yonsei University 2 nd Semester, 2015 Sanghyun Park.
Roles Managers Technical Team Leaders Programmers Customers Database Administrators Instructors.
Agile Development Chapter 10 - part 2. Agile Philosophy A guiding philosophy and set of guidelines for : developing information systems in an unknown,
Agile Requirements Methods CSSE 371 Software Requirements and Specification Mark Ardis, Rose-Hulman Institute October 26, 2004.
BTS530: Major Project Planning and Design Iterative Development References: Agile & Iterative Development, by Craig Larman, 2004, Addison Wesley. Agile.
1 March Extreme programming. Presentations Tuesday Campus Tour Sami Says Hawks Thursday Read2Me UNCSET Oral Lab NetVis If helpful, invite your client.
Extreme Programming. Extreme Programming (XP) Formulated in 1999 by Kent Beck, Ward Cunningham and Ron Jeffries Agile software development methodology.
Extreme programming (XP) Variant of agile Takes commonsense practices to extreme levels © 2012 by Václav Rajlich1.
Copyright 2002 by RoleModel Software, Inc. Extreme Programming: So What? Roy W. Miller RoleModel Software, Inc.
Extreme Programming (XP). Agile Software Development Paradigm Values individuals and interactions over processes and tools. Values working software over.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall B.1.
Agile development By Sam Chamberlain. First a bit of history..
Lecture 4 – XP and Agile 17/9/15. Plan-driven and agile development Plan-driven development A plan-driven approach to software engineering is based around.
1 Introduction to eXtreme Programming Remko Popma Azzurri Ltd.
Scrum. An evolutionary/iterative/incremental/agile software process The main roles in Scrum are: – Scrum team: Team of software developers – Scrum master.
Extreme Programming: Practices and Strategies Extreme Programming Practices and Strategies Mohammad Alshayeb Information and Computer.
Computer Engineering 203 R Smith Agile Development 1/ Agile Methods What are Agile Methods? – Extreme Programming is the best known example – SCRUM.
IS3320 Developing and Using Management Information Systems Lecture 20: Project Management Rob Gleasure
Agenda: Overview of Agile testing Difference between Agile and traditional Methodology Agile Development Methodologies Extreme Programming Test Driven.
Extreme/Agile Programming Prabhaker Mateti. ACK These slides are collected from many authors along with a few of mine. Many thanks to all these authors.
Information Architecture 2 Mailing List? No Class Scheduled October 23 Books? -Beck, K. (1999). Extreme Programming Explained: Embrace Change.Extreme Programming.
© Connextra 2001: delivering the right information to the right people at the right time© eXtreme Tuesday Club 2003 John Nolan & Rachel Davies Exploring.
5 Levels of Planning Adapted from 5 Levels of Agile Planning by Hubert Smits Daily Standup Iteration Plan Release Plan Product Roadmap Product Vision.
Extreme Programming David Li CTO, DigitalSesame. Problem in Developing Software The Basic Problem - Risk –Schedule slips –Project canceled –System goes.
1 Department of Computer Science, University of Sheffield eXtreme Programming - Practices Dr. Marian Gheorghe.
Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall Appendix B Agile Methodologies B.1.
SoberIT Software Business and Engineering Institute HELSINKI UNIVERSITY OF TECHNOLOGY 1 eXtreme Programming – one of the Agile Software Development Methodologies.
Chapter 3 – Agile Software Development Lecture 1 1Chapter 3 Agile software development.
Extreme Programming and Systems Engineering Similarities and Synergy (based on talk given to INCOSE New England Chapter) Joseph (Yossi) Weihs Sept 10 th,
© 2017 SlidePlayer.com Inc. All rights reserved.