Semen Cirit

Process and tools

Individuals and interactions over

Following a planResponding to change over

Source: www.agilemanifesto.org

Comprehensive documentationWorking software over

Contract negotiation

Customer collaboration over

12 PRINCIPLES Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

12 PRINCIPLES Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

12 PRINCIPLES Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

INTRODUCTION EXTREME PROGRAMMING? An agile development methodology XP is “a light-weight methodology for small to medium-sized teams developing software in the face of vague or rapidly changing requirements

It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation?

Created by Kent Beck in the mid 1990’s A set of 12 key practices taken to their “extremes” A mindset for developers and customers

EXTREME PROGRAMMING Hence XP is a lightweight (agile) process:

Instead of lots of documentation nailing down what customer wants up front, XP emphasizes plenty of feedback

Embrace change: iterate often, design and redesign, code and test frequently, keep the customer involved

Deliver software to the customer in short (1-3 week) iterations

Eliminate defects early, thus reducing costs

XP MODEL (FROM WWW.EXTREMEPROGRAMMING.ORG)

XP EMPHASIZES ITERATION

XP EMPHASIZES COMMUNICATION

TEST-DRIVEN DEVELOPMENT

FOUR CORE VALUES OF XP Communication Simplicity Feedback Courage

XP PRACTICES The Planning Game Small Releases Metaphor Simple Design Testing Refactoring Pair Programming Collective Ownership Continuous Integration 40-Hour Workweek On-site Customer Coding Standards

THE PLANNING GAME Planning for the upcoming iteration Uses stories provided by the customer Technical persons determine schedules, estimates, costs, etc A result of collaboration between the customer and the

developersAdvantages Reduction in time wasted on useless features Greater customer appreciation of the cost of a

feature Less guesswork in planningDisadvantages Customer availability Is planning this often necessary?

Small in terms of functionality Less functionality means releases happen more frequently Support the planning gameAdvantages Frequent feedback Tracking Reduce chance of overall project slippage

Disadvantages Not easy for all projects Not needed for all projects Versioning issues

METAPHOR The oral architecture of the system A common set of terminology The system metaphor is a story that everyone - customers, programmers, and

managers - can tell about how the system works. It's a naming concept for classes and methods that should make it easy for a team member to guess the functionality of a particular class/method, from its name only. For example a library system may createloan_records(class) for borrowers(class), and if the item were to become overdue it may perform a make_overdue operation on a catalogue(class). For each class or operation the functionality is obvious to the entire team.

Advantages Encourages a common set of terms for the system Reduction of buzz words and jargon A quick and easy way to explain the system

Disadvantages Often the metaphor is the system Another opportunity for miscommunication The system is often not well understood as a metaphor

SIMPLE DESIGN K.I.S.S (Keep it simple Stupid) Do as little as needed, nothing more The author should ask themselves 'is there a simpler way to introduce the

same functionality?'. If the answer is yes, the simpler course should be chosen. Refactoring should also be used, to make complex code simpler.Advantages Time is not wasted adding superfluous functionality Easier to understand what is going on Refactoring and collective ownership is made possible Helps keeps programmers on track

Disadvantages What is “simple?” Simple isn’t always best

TESTING Unit testing Test-first design All automated

Advantages Unit testing promote testing completeness Test-first gives developers a goal Automation gives a suite of regression test

Disadvantages Automated unit testing isn’t for everything Reliance on unit testing isn’t a good idea A test result is only as good as the test itself

REFACTORING Changing how the system does something but not what is

done Improves the quality of the system in some way

Advantages Prompts developers to proactively improve the product as a whole Increases developer knowledge of the systemDisadvantages Not everyone is capable of refactoring Refactoring may not always be appropriate Would upfront design eliminate refactoring?

PAIR PROGRAMMING Two Developers, One monitor, One Keyboard One “drives” and the other thinks Switch roles as neededAdvantages

Two heads are better than one Focus Two people are more likely to answer the following questions:

Is this whole approach going to work? What are some test cases that may not work yet? Is there a way to simplify this?

Disadvantages Many tasks really don’t require two programmers A hard sell to the customers

COLLECTIVE OWNERSHIP The idea that all developers own all of the code Enables refactoring

Advantages Helps mitigate the loss of a team member leaving Promotes developers to take responsibility for the

system as a whole rather then parts of the system

Disadvantages Loss of accountability Limitation to how much of a large system that an

individual can practically “own”

CONTINUOUS INTEGRATION New features and changes are worked into the system immediately

Code is not worked on without being integrated for more than a dayAdvantages Reduces to lengthy process Enables the Small Releases practice

Disadvantages The one day limit is not always practical Reduces the importance of a well-thought-out

architecture

40-HOUR WEEK The work week should be limited to 40 hours Regular overtime is a symptom of a problem and not a long term solutionAdvantages Most developers lose effectiveness past 40-Hours Value is placed on the developers well-being Management is forced to find real solutions

Disadvantages The underlying principle is flawed 40-Hours is a magic number Some may like to work more than 40-Hours

ON-SITE CUSTOMER Acts to “steer” the project Gives quick and continuous feedback to the development team

Advantages Can give quick and knowledgeable answers to real development questions Makes sure that what is developed is what is needed Functionality is prioritized correctly

Disadvantages Difficult to get an On-Site Customer The On-Site customer that is given may not be fully knowledgeable about what the company May not have authority to make many decisions Loss of work to the customer’s company

CODING STANDARDS All code should look the same It should not possible to determine who coded what based on the code itselfAdvantages Reduces the amount of time developers spend

reformatting other peoples’ code Reduces the need for internal commenting Call for clear, unambiguous code Disadvantages Degrading the quality of inline documentation

Customer Writes User Stories and specifies Functional Tests Sets priorities, explains stories May or may not be an end-user Has authority to decide questions about the stories

Programmer Estimates stories Defines Tasks from stories, and estimates Implements Stories and Unit Tests

Coach Watches everything, sends obscure signals, makes sure the project stays on course Helps with anything

Tracker Monitors Programmers’ progress, takes action if things seem

to be going off track. Actions include setting up a meeting with Customer, Coach or another Programmer to help

Tester Implements and runs Functional Tests (not Unit Tests!) Graphs results, and makes sure people know when test

results decline. Doomsayer

Ensures that everybody knows the risks involved Ensures that bad news isn't hidden, glossed over, or blown

out of proportion

Manager Schedules meetings (e.g. Iteration Plan, Release Plan),

makes sure the meeting process is followed, records results of meeting for future reporting, and passes to the Tracker

Possibly responsible to the Gold Owner. Goes to meetings, brings back useful information

Gold Owner The person funding the project, which may or may not

be the same as the Customer

Coding: You code because if you don't code, at the end of the day you haven't done anything.

Testing: You test because if you don't test, you don't know when you are done coding

Listening: You listen because if you don't listen you don't know what to code or what to test

Designing: And you design so you can keep coding and testing and listening indefinitely (good design allows extension of the system with changes in only one place)

Exploration Phase: In this phase the customer will provide a shortlist of high-value requirements for the system. These will be written down on user story cards.

Commitment Phase: Within the commitment phase customer and developers will commit themselves to the functionality that will be included and the date of the next release.

Steering Phase: In the steering phase the plan can be adjusted, new requirements can be added and/or existing requirements can be changed or removed

Iterative process of gathering requirements and estimating the work impact of each of those requirements.Write a Story: Customer has come with a problem; during a meeting, Developer will try to define this problem and get requirements. Based on the business problem, a story (user story) has to be written. This is done by Customer, where they point out what they want a part of the system to do. It is important that developer has no influence on this story. The story is written on a user story card.Roles : Customer , Developer Artifact : User Stories

Estimate a Story: Developer estimates how long it will take to implement the work implied by the story card. Developer can analyze or solve the problem. These solutions are used for estimation and discarded once everyone gets clear visualization of the problem. Again, this may not influence the business requirements.

Split a Story: Design critical complexity has to be addressed before starting the iteration planning. If developer isn't able to estimate the story, it needs to be split up and written again.

This phase involves the determination of costs, benefits, and schedule impact. It has four components: Sort by Value: Customer sorts the user stories by

business value Sort by Risk: Developer sorts the stories by risk. Set Velocity: Developer determines at what speed they

can perform the project. Choose scope: The user stories that will be finished in

the next release will be picked. Based on the user stories the release date is determined.

The business side sorts the user stories by business value. They will arrange them into three piles:

Critical: stories without which the system cannot function or has no meaning.

Significant Business Value: Non-critical user stories that have significant business value.

Nice to have: User stories that do not have significant business value.

The developers sort the user stories by risk. They also categorize into three piles: low, medium and high risk user stories. The following is an example of an approach to this:

Determine Risk Index: Give each user story an index from 0 to 2 on each of the following factors: Completeness (do we know all of the story details?)

Complete (0) Incomplete (1) Unknown (2)

Volatility (is it likely to change?) low (0) medium (1) high (2)

Complexity (how hard is it to build?) simple (0) standard (1) complex (2)

All indexes for a user story are added, assigning the user stories a risk index of low (0–1), medium (2–4), or high (5–6).

Within the steering phase the developer and customer can "steer" the process. That is to say, they can make changes. Individual user stories, or relative priorities of different user stories, might change; estimates might prove wrong. This is the chance to adjust the plan accordingly.

Plans the activities and tasks of the developers. In this process the customer is not involved..Role : Developers

3 Phases of Iteration Planning

Exploration Phase: requirement will be translated to different tasks. The tasks are recorded on task cards.

Commitment Phase: The tasks will be assigned to the programmers and the time it takes to complete will be estimated.

Steering Phase: The tasks are performed and the end result is matched with the original user story

It is about creating tasks and estimating their implementation time.

Translate the requirement to tasks: Place on task cards.

Combine/Split task: If the programmer cannot estimate the task because it is too small or too big, the programmer will need to combine or split the task.

Estimate task: Estimate the time it will take to implement the task

Within the commitment phase of the iteration planning programmers are assigned tasks that reference the different user stories.

A programmer accepts a task, each programmer picks a task for which he or she takes responsibility.

Programmer estimates the task, because the programmer is now responsible for the task, he or she should give the eventual estimation of the task.

Set load factor: The load factor represents the ideal amount of hands-on development time per programmer within one iteration. For example, in a 40-hour week, with 5 hours dedicated to meetings, this would be no more than 35 hours.

Balancing: When all programmers within the team have been assigned tasks, a comparison is made between the estimated time of the tasks and the load factor. Then the tasks are balanced out among the programmers. If a programmer is overcommitted, other programmers must take over some of his or her tasks and vice versa.

The implementation of the tasks is done during the steering phase of the iteration planning.

Get a task card: The programmer gets the task card for one of the tasks to which he or she has committed.

Find a Partner: The programmer will implement this task along with another programmer. This is further discussed in the practice Pair Programming.

Design the task: If needed, the programmers will design the functionality of the task.

Write unit test: Before the programmers start coding the functionality they first write automated tests. This is further discussed in the practice Unit Testing.

Write code: The programmers start to code. Run test: The unit tests are run to test the code. Refactor: Remove any code smell from the code. Run Functional test: Functional tests (based on the requirements in the associated user story and task card) are run.

Story Cards Task Cards

A short description of the behavior of the system from the point of view of the Customer

Use the Customer’s terminology without technical jargon

One for each major feature in the system Must be written by the users Are used to create time estimates for release planning

Replace a large Requirements Document

Drive the creation of the acceptance tests Must be one or more tests to verify that a story has

been properly implemented Should only provide enough detail to make a

reasonably low risk estimate of how long the story will take to implement.

Written by the Customer, not the Programmers, using the Customer’s terminology

More “friendly” than formal Use Cases

User stories have three crucial aspects: Card

Enough information to identify the story Conversation

Customer and Programmers discuss the story to elaborate on the details

Verbal when possible, but documented when required Confirmation

Acceptance tests to confirm that the story has been properly implemented

A user wants access to the system, so they find a system administrator, who enters in the user's First Name, Last Name, Middle Initial, E-Mail Address, Username (unique), and Phone Number.

Risk: Low Cost: 2 points

RESEARCH ISSUES http://martinfowler.com/articles/planningXpIteration.html http://www.extremeprogramming.org/