Spikes nad SCRUM_Se lect6 btech
Upcoming SlideShare
Loading in...5
×
 

Spikes nad SCRUM_Se lect6 btech

on

  • 450 views

 

Statistics

Views

Total Views
450
Views on SlideShare
450
Embed Views
0

Actions

Likes
0
Downloads
5
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs LicenseCC Attribution-NonCommercial-NoDerivs License

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
  • Release planning meeting is used to create the release plan which lays out the overall project User Stories drive the creation of the acceptance tests -> T o verify the user story has been correctly implemented.
  • Project management activities, which include data collection & analysis, monitoring the progress of the project and the development of project plan required 13.4% of the total effort.
  • Data shows that in this project roughly 10% is required for planning the release contents.
  • coding in terms of unit test development, production code, development spikes and refactoring took the majority, i.e. 54.7%, of the total Note that no unit tests were developed for JSP code. Unit test development shown in Figure 1 is with respect to Java code. effort. Yet, the proportion of actual coding is less than the expectations put forward in the popular XP literature. Project meetings took 4.5% of the total effort.
  • Project meetings took 4.5% of the total effort
  • Essential Agile Development Jeff Patton, jpatton@acm.org, www.agileproductdesing.com
  • Essential Agile Development Jeff Patton, jpatton@acm.org, www.agileproductdesing.com
  • Essential Agile Development Jeff Patton, jpatton@acm.org, www.agileproductdesing.com
  • Essential Agile Development Jeff Patton, jpatton@acm.org, www.agileproductdesing.com
  • Essential Agile Development Jeff Patton, jpatton@acm.org, www.agileproductdesing.com
  • Essential Agile Development Jeff Patton, jpatton@acm.org, www.agileproductdesing.com

Spikes nad SCRUM_Se lect6 btech Spikes nad SCRUM_Se lect6 btech Presentation Transcript

  • What are Spikes
  • Spike Solutions• Create spike solutions to figure out answers to tough technical or design problems.• A spike solution is a very simple program to explore potential solutions. Build a system which only addresses the problem under examination and ignore all other concerns.• The goal is reducing the risk of a technical problem or increase the reliability of a user storys estimate.
  • Big Design Up Front (BDUF)
  • What are the purpose of UserStories…
  • Purpose• User Stories are used to create time estimates for the release planning meeting.• They are also used instead of a large requirements document.• User Stories also drive the creation of the acceptance tests.
  • What is Planning Feedback Loop
  • 7
  • The XP Roadmap
  • XP practices—a road map(from www.extremeprogramming.org)9
  • XP emphasizes iteration
  • XP emphasizes iteration11
  • XP emphasizes communication
  • Communication is important13
  • Test-driven development
  • Test-driven development15
  • References/LinksBooks• Kent Beck, "Extreme Programming Explained," Addison-Wesley, 2000.• Giancarlo Succi, Michelle Marchesi, "Extreme Programming Examined," Addison-Wesley, 2001. Websites• http://www.extremeprogramming.org• http://www.xprogramming.com• http://www.jera.com/techinfo/xpfaq.html• http://www.c2.com/cgi/wiki?ExtremeProgrammingRoadmap• http://ootips.org/xp.html• http://pairprogramming.com/
  • Effort Distribution in a XP project…
  • Effort Distribution: Project Management
  • Effort Distribution: Planning
  • Effort Distribution: Coding
  • Effort Distribution: Project Meetings
  • SCRUM
  • SCRUM• SCRUM is an • Agile Project Management Methodology• Characteristics of an ‘Agile’ methodology are: • ADAPTIVE, not PREDICTIVE • LIGHTWEIGHT, not HEAVYWEIGHT • DESCRIPTIVE, not PRESCRIPTIVE
  • SCRUM• Scrum is a lightweight process that can manage and control software and product development. – It is a Project management process.• However, instead of promoting the traditional analysis, design, code, test, deploy "waterfall" approach, Scrum embraces iterative and incremental practices.
  • SCRUM• Similarly, instead of being "artifact-driven", whereby large requirements documents, analysis specifications, design documents, etc. are created, Scrum requires very few artifacts.• It concentrates on what’s important: managing a project or writing software that produces business value.
  • SCRUMSCRUM has the following ELEMENTS :• A project team called a SCRUM Team• A Product Backlog of all known Requirements• A Sprint Backlog of requirements being worked on• A period of work referred to as a Sprint• Daily Stand-up Meetings with the SCRUM Team• A Burndown Chart to track progress of the Sprint• An Incremental Delivery at the end of each sprint
  • A Model of SCRUM Burndown Chart Daily SCRUMProduct Backlog Sprint Sprint Backlog Incremental Delivery 2 - 4 Weeks
  • The SCRUM Team• Is all the people who will COMMITTED to the delivery of the backlogs• One role is ‘SCRUM Master’ who is in practice the PM• Is staffed by PMs, BAs, Developers, Testers, Support – i.e. ALL the typical project staff
  • Product Backlog• Contains all the currently known requirements for a product• Is managed by the Product Owner and can change as needed
  • Sprint Backlog• Contains the set of prioritised Product Backlog items that are currently being worked on• Are not to be changed during the Sprint
  • Sprint• Is a fixed period of development and testing• Results in an incremental delivery of usable product• Usually lasts 2 to 4 weeks
  • Daily SCRUM Meeting• Brief ‘Stand-up’ meeting each morning with SCRUM Team only• What value did you add yesterday?• What value will you add today?• What will stop you making progress?
  • Burndown chart• Charts delivery of the Sprint Backlog against Sprint Duration.• Simple, at-a-glance view of progress showing velocity and traction• Easy to keep updated
  • Incremental Delivery• Output of the Sprint• Working functionality that can be deployed• Delivered every 2 to 4 weeks, tested and working
  • Scrum’s three questions
  • What is Scrum Roles?• Product Owner • Possibly a Product Manager or Project Sponsor • Marketing • Internal Customer • etc.• ScrumMaster • Represents management to the project • Typically filled by a Project Manager or Team Leader • Responsible for enacting Scrum values and practices • Main job is to remove impediments and remove any politics• Project Team • 5-10 members • Cross-functional: QA, Programmers, UI Designers, etc. 36
  • Scrum Process Flow
  • Process Comparison
  • The product owner plans theproduct in layers© 2006-2007 Jeff Patton, 40All rights reserved,www.agileproductdesign.
  • The product owner plans the product in layers Product Release or Project How can we release value incrementally? What business What subset of business objectives will the objectives will each release product fulfill? achieve? What user constituencies will the release serve? What general capabilities (big stories) will the release offer? Release planIterationWhat specifically will webuild? (user stories) Story (Backlog Item)How will this iteration What user or stakeholder need will themove us toward release story serve?objectives? How will it specifically look andIteration Plan behave? How will I determine if it’s completed? Story Details Acceptance Tests 41
  • The Planning Onion can grow to include product portfolios and business strategy Product or Release Product or Project Project How can we release value incrementally? What business Release What subset of business objectives will the objectives will each release product fulfill? achieve? What user constituencies will Iteration the release serve? What general capabilities (big stories) will the release offer? Release planIteration StoryWhat specifically will webuild? (user stories) Story (Backlog Item)How will this iteration What user or stakeholder need will themove us toward release story serve?objectives? How will it specifically look andIteration Plan behave? How will I determine if it’s completed? Story Details Acceptance Tests 42
  • The Planning Onion can grow to includeproduct portfolios and business strategy Product or Project Release Iteration Story 43
  • The Planning Onion can grow to includeproduct portfolios and business strategy Business Strategy Product Portfolio Product or Project Release Iteration Story 44
  • Design and Coded Features Pass Back andForth Between Tracks Sprint 0 Sprint 1 Sprint 2 Sprint 3 • planning • gather user input for • gather user input for • gather user input for • data gathering iteration 3 features iteration 4 features iteration 5 features • design for iteration • design iteration 2 • design iteration 3 • design iteration 4 1 features – high features features features technical • support iteration 1 • support iteration 2 • support iteration 3 requirements, low development development development user requirements • validate iteration 1 • validate iteration 2 features features support dev support dev fea gs y t fea + abil es tu fou esti bu it us tu ur re re de nd i g at sig n fe d es n ed ign d n • development implement iteration 1 co implement iteration 2 implement iteration 3 environment setup features features features • architectural fix iteration 1 bugs if fix iteration 2 bugs if “spikes” any any time 45
  • Who uses Scrum?• Microsoft, Sun, Sammy Studios, Siemens, CNA, State Farm, State Street Bank, Philips, BBC, IBM, SAIC, LMCO, APL, Ariba, Federal Reserve Bank, HP, Motorola, Nokia, TransUnion, IDX, Siemens Medical, Gestalt, Yahoo, Conchango, BMC, Lexis-Nexis, Bently Systems, Bose, CapitalOne,Federal Reserve Bank, ClearChannel, Xerox, Patient Keeper, British Telecom, PayPal, …
  • What is Scrum process flow
  • Scrum process flowPlanning Product owner and team decide which stories are actually feasible to be moved from the Product backlog to the Sprint backlog.Sprint The team is left alone to perform the user stories which it has committed itself in the planning meeting. The product owner may attend the “daily scrums” if a granular status update is desired.Review The team presents its work and verifies what it has done indeed satisfies the utmost desires of the product owner.
  • User Stories in SCRUM
  • User Stories• A user story is a software system requirement formulated as one or two sentences in the everyday language of the user.• It is written by the Product Owner, with the help of the ScrumMaster and Team, if desired and necessary.• Once completed, it is put in the Product Backlog and prioritized, by the Product Owner, by its relative placement to other user stories.• Before a user story is to be implemented, appropriate acceptance criteria must be written to ensure proper testing or otherwise determine whether the goals of the user story have been fulfilled.• Some formalization finally happens when the developer accepts the user story and the acceptance procedure as his work specific order.
  • User Stories - structure
  • User Stories - structure• Who (user role) – is this a customer, employee, system administrator?• What (goal) – What is the specific functionality that is to be achieved or developed?• Why (reason) – Helps the developer to understand the broader scope of the story and eliminate any ambiguities that may arise.• Putting it all together: As a [user role], I want to [goal], so I can [reason].• “As a registered user, I want to log in, so I can access subscriber content.”
  • USER STORIESCHARACTERISTICS – I.N.V.E.S.T.
  • User Stories – I.N.V.E.S.T. • Independent - For some systems, its near impossible to make each feature completely independent. In other solutions, e.g. web sites, its easier. But its an important aspiration. User Stories should be as independent as possible. • Negotiable - User Stories are not a contract. They are not detailed specifications. They are reminders of features for the team to discuss and collaborate to clarify the details near the time of development. • Valuable - User Stories should be valuable to the user (or owner) of the solution. They should be written in user language. They should be features, not tasks. • Estimatable - User Stories need to be possible to estimate. They need to provide enough information to estimate, without being too detailed. • Small - User Stories should be small. Not too small. But not too big. • Testable - User Stories need to be worded in a way that is testable, i.e. not too subjective and to provide clear details of how the User Story will be tested.
  • Scrum has been used for:• Commercial software• In-house development • Video game development• Contract development • life-critical systems• Fixed-price projects • Satellite-control software• Financial applications • Websites• ISO 9001-certified • Handheld software applications • Mobile phones• Embedded systems • Network switching applications• 24x7 systems with 99.999% • Some of the largest applications in uptime requirements use