Agile
Agile
Agile
AGENDA
AGILE SCRUM XTREME PROGRAMMING AGILE TESTING
AGILE-In Brief by
Introducing Agile
Software development Life cycle model that focus on customers.
Iterative development, where requirements and solutions evolve through collaboration between self-organizing crossfunctional teams.
Why Agile????
3 KEYS
Incremental, Iterative, Adaptive
Incremental Build a system gradually Demonstrating progress Iterative Multiple releases or check points , closer to the target Iterations include requirements, development and testing Adaptive Goals change based on lessons from prior iterations, feedback and business opportunities
Process
Prioritize
How people spend their time in Agile:
Analysis 16% Design 17% Code/Unit Test 34% System/Integration Test 18% Documentation 8% Implementation/Install 7%
7 Principles
Satisfy the customer through The most efficient method early and continuous delivery of conveying information to of valuable software. and within a development team is face-to-face Working software is the conversation. primary measure of progress. Business people and Deliver working software developers must work frequently, from a couple of together daily throughout weeks to a couple of months. the project. Welcome changing Simplicity--the art of requirements, even late in maximizing the amount of development. work not done--is essential.
Benefits
Empirical (relies on observation and experience) Lightweight Adaptive Fast but never hurried Exposes wastefulness Customer-centric Pushes decision making to lower levels Fosters trust, honesty and courage Encourages self-organization
Scrum by,
Team-based approach Controls the chaos of conflicting interest and needs Improve communication and maximize cooperation A way to maximize productivity
JASS 2006 Agile Project Management - Scrum 12
History of Scrum
1995:
analysis of common software development processes not suitable for empirical, unpredictable and non-repeatable processes Design of a new method: Scrum by Jeff Sutherland & Ken Schwaber Enhancement of Scrum by Mike Beedle & combination of Scrum with Extreme Programming
1996:
introduction of Scrum at OOPSLA conference
2001:
publication Agile Software Development with Scrum by Ken Schwaber & Mike Beedle
Successful appliance of Scrum in over 50 companies Founders are members in the Agile Alliance
JASS 2006
13
Functionality of Scrum
JASS 2006
14
component View
3 Men Army
Scrum Master -> a Project Manager or Team Leader and is responsible for enacting scrum values and practices Scrum Team -> 5-10 people who are Cross-functional, Working full-time and self-organizing Product Owner -> product manager works on what needs to be build and in what sequence this should be done
Process
Sprint Planning Meeting
Meeting in the beginning of each Sprint between the stake holders where the goal is determined and the project kickoff is done.
Sprint
A month-long iteration, during which is incremented a product functionality
Contd
Daily Scrum
Meeting to track the progress of the Team
Scrum Artifacts
Product Backlog
Requirements and outcomes for a system, expressed as
a prioritized list of Backlog Items in Spread Sheets.
Sprint Backlog
Define the work for a Sprint, created and updated every day by Team members
XTREME PROGRAMMING
lightweight methodology for smallto-medium-sized teams developing software in the face of vague or rapidly changing requirements. promises to reduce project risk, improve responsiveness to business changes, improve productivity throughout the life of a system, and add fun to building software in teams
NEED
Software project failures are legendary Traditional software methodologies are unable to:
Handle faster delivery cycles Nor able to embrace frequent change They cant live in web world
4 principles
Communication Simplicity Feedback Courage
Basic Activities
Coding Testing Listening Designing
Release cycle
Practices 1
Incremental planning Requirements are recorded on Story Cards and the Stories to be included in a release are determined by the time available and their relative priority. The developers break these Stories into development Tasks . The minimal useful set of functionalit y that provides business value is developed first. Releases of the system are frequent and incrementally add functionalit y to the first release. Enough design is carried out to meet the current requirements and no more. An automated unit test framework is used to write tests for a new piece of functionalit y before that functionality itself is implemented. All developers are expected to refactor the code continuously as soon as possible code improvements are found. This keeps the code simple and maintainable.
Small Releases
Refactoring
Practices 2
Pair Programming Collective Ownership Developers work in pairs, checking each other work and s providing the support to always do a good job. The pairs of developers work on all areas of the system, so that no islands of expertise develop and all the developers own all the code. Anyone can change anything. As soon as work on a task is complete it is integrated into the whole system. After any such integration, all the unit tests in the system must pass. Large amounts of over-time are not considered acceptable as the net effect is often to reduce code qualit y and medium term productivity A representative of the end-user of the system (the Customer) should be available full time for the use of the XP team. In an extreme programming process, the customer is a member of the development team and is responsible for bringing system requirements to the team for implementation.
Continuous Integration
Sustainable pace
On-site Customer
Key Ideas
Code in Pairs Stay in Contact with the Customer Create Tests before Coding then Test Heavily Short Iterations Keep it Simple Dont Anticipate: Code for Current Needs Collective Ownership
Advantages
Built-In Quality Overall Simplicity Programmer Power Customer Power Synergy Between Practices
Agile Testing
An iterative approach of software development involving all the stake holders right from the requirement phase of the development cycle. Test Driven Development test cases are developed, and often automated, before the software is developed to run the test cases.
Project Development Test Manager Manager Manager
Concept (Inception)
Deploy
I0
In
+1
Analysis
I1
In+1
Key Stakeholders
I1
Design (TDD)
Business Rep / Customer Security Tester Performance Tester
In+1
Showcase Tests
Iteration Manager
I1
Architect
Business Analyst
I1
+ In
Regression Tests
In+1
In+1
I1
3 Models
$ $
Concept
Marketing
Key Stakeholders
Concept
Marketing
Deploy
Business Rep / Customer
Marketing
Key Stakeholders
Key Stakeholders
Analysis
Business Business Rep / Customer Analyst
Concept (Inception)
Deploy
Design
Architect Senior Developer
Analysis
Senior Tester Test Team
Acceptance Test
Analysis
Project Manager Security Tester
Project Manager
Develop
Development Team
Senior Architect Developer
Design
Senior Tester Test Team
Test Manager
Senior Tester
Performance Tester
Test
Test Toolsmith Senior Tester Development Manager Test Team
Design (TTD)
Acceptance Test
Project Manager
Architect
Deploy
Develop
Unit Test
Development Team
Test Manager
Testing Roles
Traditional Roles Test Manager Senior Tester / Test Lead Test Analyst Technical Tester Performance Tester Test Toolsmith Security Tester Agile Roles Test Manager Senior Tester / Test Lead Test Analyst Technical Tester Performance Tester Test Toolsmith Security Tester Iteration Manager Showcase Tester
Slide 34
Slide 34
Risks 1
Risk
Requirements changing.
Solution
Acceptance of change that is what Agile is about. Clear understanding of the features and stories by the entire team. Early team involvement in meetings, Wall ware all can see it. Just Enough documentation. Automated unit tests. Skilled testers using Exploratory Testing.
No documentation.
Testers not involved early in iteration lack of knowledge of testing = using Exploratory Testing.
Slide 35
Slide 35
Risks 2
Risk
Little or no unit testing.
Solution
Education of developers, experience and team maturity. More unit testing with tester involvement, more points allocated to testing. Provision for Smoke Tests
REGRESSION!
No clear definition of Done Regular involvement of and Burn charts not accurate. reporting to the Business.
Slide 36
Slide 36
Benefits
Early delivery of working software Quality is built into the products everyone involved in quality Defect prevention (stopping them from getting beyond the requirements) Clear acceptance criteria Early involvement of all key players No surprises to the business on delivery
Slide 37
Slide 37