Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change** **over following a plan
Principles of Agile Methods
Customer Collaboration
- Users should work closely with the development team.
Users should provide feedback on the system and suggestions for requirements/improvement.
Embrace Change
Changes to the requirements can happen at any time during the development.
Plans can quickly become inaccurate with the rapid change to the requirements.
Incremental Delivery
It is more important to deliver the software than following the plan.
The software should be developed incrementally and iteratively with each delivery having more functionalities included.
Maintain Simplicity
Keep everything simple, for both the software and the software process.
Focus on delivering valuable software to the customer rather than writing comprehensive documentation.
People, not Process
Focus on the people on the team. Tools and practices are second.
- People should be left to develop their own ways of working, rather giving prescriptive processes.
- Exploit and explore skills and knowledges of team members and trust them.
eXtreme Programming (XP)
“XP is a style of software development focusing on excellent application of programming techniques, clear communication, and teamwork…”
Principles: “A set of complementary principles, intellectual techniques for translating the values into practice…”
Practices:”A body of practices proven useful in improving software development.”
Values: “A philosophy of software development based on the values of communication, feedback, simplicity, courage, and respect.”
XP Principles
- Humanity
- Balance the needs of the individual with the needs of the team
- Economics
- The time value of money
- The option value of systems and teams
- Mutual Benefit
- Every activity should benefit all concerned
- Write automated tests that help the design and implementation better today; leave the test as the ‘documentation’ for future programmers
- Refactor to improve simplicity, clarity and coherence
- Self-Similarity
- Use the structure of one solution into a new context, even at different scales (it’s a good place to start)
- Improvement
- Get an activity started right away, then refine the results over time.
- Diversity
- Programmers should work together on the problem and all opinions should be valued
- Reflection
- Review and analyze why they succussed or failed
- Flow
- Continuous flow of activities rather than discrete phase (small increments, continuous integration)
- Opportunity
- Seeing problems as opportunities for changes (personal growth, deepening relationships, and improved software)
- Redundancy
- Difficult problems in software development should be solved in several different ways.
- Failure
- If you have 3 ways to implement a user story, but you don’t know which to use, try all of them
- Quality
- Quality can be measured in defect, design quality, and the experience of development
- Baby Step
- Proceeds one test at a time, and integrates and test a few hours’ worth of changes at a time
- Accepted Responsibility
- Responsibility cannot be assigned; it can only be accepted
XP Workflow
- At the beginning of the project development, the product manager and the user write Stories (programmers may also be involved).
- The programmers estimate the stories and tasks.
- if a story is too big, the product manager and/or the user split the story; if the programmers don’t understand the topic, initial a Spike.
- The product manager and/or the user decide on a “theme” (the big picture) for a Quarterly Cycle.
- The process iterates until the project finishes.
- The product manager, the users and/or the programmers pick a reasonable number of user stories for Weekly Cycle and add some Slacks.
- The process iterates until the end of the Quarterly Cycle
XP – Planning the Release
Scrum
A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Transparency :
- Process must be visible to all team members.
- Use common language and share a common definition.
Inspection:
- Scrum artifacts and progress must be inspected frequently without interfering team’s work.
Adaptation:
- If a process or development deviates outside the plan, adjustment must be made in time.
- Use an iterative and incremental approach to control risk.
- Make decisions based on what is known.
The Components of Scrum Framework
Values: The Scrum team members learn and explore the value of commitment, courage, focus, openness and respect as they work with the Scrum roles, events, and artifacts.
Team: A typical Scrum Team includes a Product Owner, the Development Team, and a Scrum Master.
Events: Four formal events are common to all Scrum teams, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective.
Artifacts:
• Product Backlog
• Sprint Backlog
• Portfolio Backlog
• Program Backlog
Rules: Binding all components together
Scrum Workflow — Vision
— Product Backlog Management
— Sprint Planning
Manage User Stories in Sprint Backlog
Scrum Workflow – Sprint
— Daily Scrums
— Sprint Review
— Sprint Retrospective
