Agile Development

Agile Software Development تقديم عامر يسير عبدالله الاسماعيل لؤي جيرودية محمد سليم فواز بإشراف د . محمد الحجي

WATERFALL DEVELOPMENT PROCESS Agile Software Process

AGILE DEVELOPEMENT Agile Software Process

WATERFALL VS. AGILE WATERFALL CHANGE AGILE CHANGE Agile Software Process

AGILE MANIFESTO Agile Software Process We 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 That is, while there is value in the items on the right, we value the items on the left more.

AGILE THINKING EXPLAINED Agile Software Process

THE 12 AGILE PRINCIPLES - Principle 1/12 Development Team Will get feedback on the system under development which guide to the next step Management Customer feedback acts as a confirmation Organization Feed back indicate the project is on the right track Development Cycle Support all development cycles (requirement ,analysis, design and implementation .. etc) Satisfy customer through early and frequent delivery. Agile Software Process

THE 12 AGILE PRINCIPLES - Principle 2/12 Synchronies and stabilize approach Engineers make changes in design until late in the project Keeping individuals more synchronized and the evolving project more or less stable This approach is used in a very complex products Pricing Strategies Unstable requirement lead to adaptive pricing strategies Welcome changing requirements even late in the project. Agile Software Process

THE 12 AGILE PRINCIPLES - Principle 3/12 Requirement Management Will becomes more efficient because the product is being tested and altered quickly Short Development Cycles Each iteration will lead requirement and the development process to be more suitable and precise The feedback gained after each iteration will lead the entire development cycle more precisely Keep delivery cycles short (e.g., every couple of weeks). Agile Software Process

THE 12 AGILE PRINCIPLES - Principle 4/12 Meet Business peoples expectations Usually business peoples doesn’t work enough on development projects The result is a product that doesn’t meet their expectation Business Decision vs. Technical Decision Business decision should be left to business peoples Technical decision should be left to developers Business people and developers work together daily throughout the project Agile Software Process

THE 12 AGILE PRINCIPLES - Principle 5/12 Hire experienced motivated peoples Experienced motivated peoples are the key factor to any project success Experienced vs. Inexperienced Build a team full of experienced peoples If your team consists of experienced peoples & inexperienced peoples, the experienced people's time will be wasted in helping the non-experienced ones Build projects around motivated individuals Agile Software Process

THE 12 AGILE PRINCIPLES - Principle 6/12 Face-to-Face communication Face-to-face communication will decrease the amount of documentation needed Enables instant feedback The best way to convey the tacit knowledge between a highly professionals Assist in analysis & design as problems can be discussed and solved in a rich communication mode Place emphasis on face-to-face Communication Agile Software Process

THE 12 AGILE PRINCIPLES - Principle 7/12 Working software is the main measure of progress Applying all agile principles guarantee us to satisfy all different quality measurements. Quality metrics: addressed in 1 st & 2 nd Principles Technical metrics: addressed in 9 th & 11 th principles Size-Oriented-Metrics: addressed in 9 th principle. Human-oriented-metrics: addressed in 11 th & 12 th principle Agile Software Process Working software is the primary measure of progress.

THE 12 AGILE PRINCIPLES - Principle 8/12 Project effectiveness Nobody can work for more than forty house with the same level of intensive required creative work Tired stuff is not agile, because the tired employees doesn’t make good result Social responsibility Projects should be organized in a way that everyone involved should work for a reasonable working hours Everyone should stay alert not engaged Promote sustainable development pace Agile Software Process

THE 12 AGILE PRINCIPLES - Principle 9/12 Making good design Developers should make a good design from the early stage of the project The design should continuously refined Better designs will facilitate other development cycles Continuous attention to technical excellence and good design Agile Software Process

THE 12 AGILE PRINCIPLES - Principle 10/12 Developer should only implements features that have been agreed with the customer Start with simple requirement , which will become clearer as the project evolve Simplicity – the art of maximizing the amount of work not done Agile Software Process

THE 12 AGILE PRINCIPLES - Principle 11/12 Agile Team Can be organized again and again. Agile team consist of individuals with common focus Mutual trust and respect and collaboratively Ability to work with ambiguity The best results emerge from self organizing teams Agile Software Process

THE 12 AGILE PRINCIPLES - Principle 12/12 Development team meeting Team will Discuss their working habits Organization Agility Team reflects regularly where and how to improve Agile Software Process

DELIVER BUSINESS VALUE Focus On Purpose, Not Process Concentrate on building product rather than serving process Deliver business value early and continuously Welcome changing requirements Consider them as competitive advantages

STEADY FLOW Arrange work in a prioritized queue that delivers a steady flow of running tested software (weekly/monthly/quarterly) Product Owner should pull business value from the Team

THINK BIG. START SMALL Get something small and hard-hitting out there early Collect feedback from real users Build on it quickly with regular incremental releases

WORK FROM THE OUTSIDE, IN Let the users drive your efforts See everything from the user’s point of view Understand value from the user’s perspective Ask the users what they want next

FIX TIME AND BUDGET. VARY SCOPE Vary scope only to deliver on time and on budget Never compromise on quality

MAKE SMALL DECISIONS Made quickly Keep you moving forward Reversible

WORKING CODE BEATS EVERYTHING Running tested software (RTS) is the best measure of progress Focuses attention Provokes more meaningful feedback Learn more about what you’re building

MAKE IT RUN. MAKE IT RIGHT . MAKE IT FAST Develop software iteratively Get something working Perfect it afterwards through successive refinement Release incrementally Deliver running tested software regularly Build on what’s there Build quality in from the start, don’t inspect for it afterwards

LET THINGS EVOLVE Let details emerge as things come into focus and you get feedback Worry about details when they really matter The best architectures, requirements and designs evolve over time

REFLECT TO IMPROVE At regular intervals, reflect on the past and how to become more effective Seek improvement Be Effective, Don’t get so busy that you lose your ability to be effective

HOW AGILE CAN YOU BE? Agile Software Process

AGILE UMBERLLA Agile Software Process

XP Method eXtreme Programming

XP Values Communication Within the team, and with customers Simplicity What is the simplest thing that could possibly work? Feedback Test results are the best concrete feedback. Courage If there is a flaw, fix it.

The 12 Key Practices The Planning Game Small Releases Metaphor Simple Design Test-Driven Development Refactoring Pair Programming Collective Ownership Continuous Integration 40-Hour Workweek On-site Customer Coding Standards

1. Planning Game Planning game is the point of interaction between customers and developers. Release Planning is where the customer articulates the required features, the programmers estimate the difficulty Iteration Planning is where a subset of the required features are broken down into tasks, estimated in more detail, and allocated to programmers

1. How it works for me? Customer provides all the story cards that have been written Developers write on each card an estimate of how long it will take to implement Customer chooses stories by priority to fill the available time Don’t plan too far ahead Play the Planning Game after each increment

2. Small Releases As small as possible, but still delivering business value Get customer feedback early and often. The team Incrementally improve the system, adding small features. Do the planning game after each iteration Do they want something different? Have their priorities changed?

2. How it works for me? Small releases are really valuable Manage the risk of delivering something wrong Helps the customer to define better the requirements Release every few weeks Large projects are not so flexible Try to release something, even you know that it will be changed .

3. Simple Design XP teams consider the simplest thing that could possibly work and try to implement it. DTSTTCPW – “Do The Simplest Thing That Could Possibly Work XP teams view design as something done continuously through the course of the development. keep things simple by not implementing anything you don’t need right now, often known as YAGNI (“You Aren’t Gonna Need It”)

3. How it works for me? Simple design does not mean "no design" It is about establishing priorities It's a set of tradeoffs you make If something is important for this release and for the whole system, it should be designed well

4. Pair Programming Pairs produce higher quality code Pairs complete their tasks faster Pairs enjoy their work more Pairs feel more confident in their work products

4. . How it works for me? “ Programming isn’t typing” Pair programming is great for complex and critical logic When developers need good concentration Where quality is really important Especially during design Trivial tasks can be done alone most programmers enjoy it once they have tried it.

5. Test-Driven Development Tests play the most important and central role in XP Tests are written before the code is developed. In this environment, change is low cost and encouraged.

5. How it works for me? This helps with two things: It forces programmers to focus on the “what”, the interface itself, before the “how”, the implementation. It means that there are tests for every facet of the system. TDD is good for most projects, not for all.

6. Continuous Integration XP teams force integration as often as they can. XP teams don't have code freezes, or go through integration hell – they just integrate all the time.

6. How it works for me? Integrating often is really valuable Sometimes you cannot finish a task for one day and integrate it. For small projects with small teams integration is not an issue. For large and complex projects it's crucial Think of automated build environment

7. Collective Code Ownership Code to belongs to the project, not to an individual engineer! Anyone can change any part of the part at any time. Programmers are not required to work around deficiencies in code they do not own Faster progress No need to wait for someone else to fix something This eliminates bottlenecks (“I can't work on that until Steve's free”)

8. Coding Standard All the code produced by an XP team should look like it was produced by the same person. An XP team needs this to support effective pairing and collective ownership. Common code formatting .

9. On-Site Customer Customer has to be present and available full-time for the team. Clarify user stories Make critical business decisions Customer is considered part of the team Developers don’t make assumptions Developers don’t have to wait for decisions Face to face communication minimizes the chances of misunderstanding

10. Metaphor For effective communication, everyone in an XP team needs to be able to talk about the system using the same vocabulary and language Often they communicate through a metaphor. The default metaphor is the business domain, and it’s usually just fine

11. Forty-Hour Work Week Kent Beck says, “ . . . fresh and eager every morning, and tired and satisfied every night” Tired developers make more mistakes, which slows you down more in the long run A maximum of 40-hour working a week.

12. Refactoring Improve the design of existing code without changing its functionality Relies on unit testing to ensure the code is not broken Bad smells in code: Long method / class Duplicate code Methods does several different things (cohesion) Too much dependencies (coupling) Complex / unreadable code

13. The 13 th Practice? The Stand Up Meeting Start day with 15-minute meeting. Everyone stands up (so the meeting stays short) in circle Going around the room everyone says specifically: What they did the day before What they plan to do today Any obstacles they are experiencing

13. People Communicate Most Effectively Face-to- Face

Main Roles in XP Programmer Customer Tester Tracker Coach Consultant

Who benefits from XP? get clear requirements & priorities can do a good job can make technical decisions don’t work overtime get accurate feedback get most business value first can make informed business decisions can change their mind Programmers: Customers:

When to Use XP XP works when: Requirements are changing rapidly High risk, new challenge projects Small groups of programmers (between 2-10) Direct customer involvement is possible

When does Extreme Programming fail? Using the wrong people. Having the wrong customer. Poor communication.

SCRUM CHARACTERISTICS Simple and scaleable Easily combined with other methods and doesn’t prescribe engineering practices Empirical process Short-term detailed planning with constant feedback provides simple inspect and adapt cycle Simple techniques Requirements are captured as user stories in a list of product backlog Progress is made in a series of 1 to 4-week Sprints

SCRUM CHARACTERISTICS Self-organizing Teams collaborating with the Product Owner Optimizes working environment Fosters openness

EMPIRICAL PROCESS Visibility Keep everything visible at all times There's no hiding problems , issues, or obstacles See them , understand them, deal with them Keep working software in plain sight and in the Product Owner’s mind

EMPIRICAL PROCESS Visibility Inspection Inspect frequently Create as many opportunities to obtain feedback as possible

EMPIRICAL PROCESS Visibility Inspection Adaptation Adapt frequently to optimize results Be driven by results and not by effort Measure progress by goals achieved and not by the effort it took to achieve them

PRODUCT BACKLOG Evolving queue of work expressed as user stories Prioritized by business value Aim to deliver highest business value user stories first

SPRINT BACKLOG User stories planned in Sprint Sprint Goal Owned by Team Product Owner cannot change Sprint Goal nor Sprint Backlog once Sprint has started Team can: Request new user stories if others completed early Update estimates Ask Product Owner to de-scope user stories that can’t be completed Terminate Sprint

SPRINT Fixed time-box of 1-4 weeks to build something valuable for the Product Owner Delivers potentially shippable increment of product Includes development, testing , etc

PRODUCT OWNER 1 per Team, collocated with Team

PRODUCT OWNER 1 per Team, collocated with Team Visible, vocal and objective driving force making all business decisions for product Responsible for business value delivered by Team Reviews/accepts/rejects user stories delivered in Sprint

PRODUCT OWNER 1 per Team, collocated with Team Visible, vocal and objective driving force making all business decisions for product Keeper/owner of the Product Backlog Defines goals Writes/evolves user stories narrowing their focus as they approach release/iteration planning Prioritizes Product Backlog by business value to set development schedule

PRODUCT OWNER 1 per Team, collocated with Team Visible, vocal and objective driving force making all business decisions for product Keeper/owner of the Product Backlog Attend every Release/Sprint Planning Game and Sprint Review Communicates user story details to Team and provides timely feedback throughout development

SCRUM TEAM Small team, 7±2 full-time people, collocated Self-organizing , self-disciplined Create and implement their own process and improvements Organize themselves around the work Empowered, accountable Authority to do whatever is needed to meet their commitments Accountable for their commitments

SCRUM MASTER 1 per Team, collocated with the Team Servant leader to Team Facilitator without authority Removes obstacles to help the Team maintain a sustainable pace Mediates between management and the Team Helps Product Owner: Drive the development effort directly Authority for Scrum process Ensures the Team uses the values, principles and the practices

SPRINT PLANNING GAME Planning up close Plan only next Sprint in detail when it starts Use Velocity as best guess of future progress (Yesterday’s Weather)

PIGS AND CHICKENS Scrum Team are known as pigs because they’re committed to delivering Sprint Goal People who are involved but not dedicated to the project are known as chickens Attend Daily Scrums as observers

DAILY SCRUM ≤ 15 mins, standing up at same time every day, at same place Team members (pigs) talk , observers (chickens) listen Heartbeat of Scrum Pigs co-ordinate today's work and checks progress Provides daily status snapshot to chickens Commitments and accountability Say what you’ll do and do what you say Take discussions/problem-solving offline

SPRINT REVIEW ≤ 30 minutes at end of every Sprint Product Owner, Team and other Stakeholders Informal demonstration of functionality delivered in Sprint Product Owner inspects completed business value Establish whether Sprint Goal has been satisfied Accepts/rejects functionality delivered by user stories Provide feedback

RETROSPECTIVE Time to reflect Amplify learning , seek improvement and adapt Release retrospective Heartbeat retrospective 1 hour at end of every Sprint Team Reflect on process and how Team is working and initiate improvements

REFERENCES An Introduction to Agile Methods by Steve Hayes (Khatovar Technology) INTRODUCTION TO AGILE AND SCRUM by Simon Baker Agile Software Development Methodologies and XP Svetlin Nakov National Academy for National Software DevelopmentSoftware Development Kent Beck. “Extreme Programming Explained: Embrace The Change” Ron Jeffries. “Extreme Programming Installed” Kent Beck, Martin Fowler. “Planning Extreme Programming” Kent Auer, Roy Miller. “Extreme Programming Applied: Playing to Win” Martin Fowler. “Refactoring: Improving design of existing code”

Agile Development

More Related Content

What's hot (20)

Similar to Agile Development (20)

Recently uploaded (20)

Agile Development