agile development - university of texas at...

Today’s Agenda

• Agile Development

– Extreme Programming (XP)

– SCRUM

1UTA - CSE 5324, Ali Sharifara

Agile Development

CSE 5324, Summer 2017

Outline

• What is Agile Development?

– The XP Process

– The Scrum Process


What is Agile (Development)?

• A philosophy and a set of development

guidelines

– customer satisfaction, early incremental delivery,

minimal documentation, simplicity, small project

teams

– Active and continuous communication between

developers and customers

• What Do We Mean By “Agile?”

– In agile software development, “agile” tends to

mean “the ability to respond to change.”


What is Agile (Cont.)

• The core ideas in Agile Development:

– Adaptive

– Iterative/incremental

– People-oriented

• Adaptive: Teams and the process should be flexible

in the presence of “rapid-fire change”.

• Iterative and incremental :Agile Development

produces working products in stages – a growing set

of “completed and working software”.

• People-oriented: Team organization and processes

will support good people, who are the most important

ingredient to project success.


Cost of Change


Unpredictability

• Difficult to predict which software

requirements will persist and which will

change

• Difficult to predict how much design is

necessary before construction

• Difficult to predict the progress of software

development activities


Iterative development


One way to organize agile development is using short iterations:

Today Ship date

Each iteration step:

• Has some analysis, some design, some

coding, some integration and testing

• delivers some kind of internally or externally

usable functionality – intermediate demos or

deliveries are possible!

Internal

prototype

(demo 1)

Customer-

viewable

prototype

(demo 2)

Customer-

viewable

prototype

(demo 3)

iteration

planning

iteration

1

iteration

2

iteration

3

iteration

4

iteration

5

iteration

6Each iteration

might be 2-4 weeks

Question:

• Could we do a “demo”

every iteration?

• Absolutely yes! The

team gets practice at

doing system integration

Main characteristics of Agile

Development


Agile Development as a “software development framework” says:

– keep things small

– deliver partially-completed software frequently

– talk to the customer often

– write more code than documentation

– everyone on the team learns together

Work for future

iterations

Work for the

current

iteration

Every 2-4 weeks, produce a

new shippable product

Agile Practices


Product Backlog Items

for current Sprint

Agile principles

9. Continuous attention to

technical excellence and

good design enhances agility.

10. Simplicity--the art of

maximizing the amount of

work not done--is essential.

11. The best architectures,

requirements, and designs

emerge from self-organizing

teams.

12. At regular intervals, the

team reflects on how to

become more effective, then

tunes and adjusts its behavior

accordingly.

5. Build projects around

motivated individuals. Give

them the environment and

support they need, and trust

them to get the job done.

6. The most efficient and

effective method of conveying

information to and within a

development team is face-to-

face conversation.

7. Working software is the

primary measure of progress.

8. Agile processes promote

sustainable development. The

sponsors, developers, and

users should be able to

maintain a constant pace

indefinitely.

1. Our highest priority is to

satisfy the customer through

early and continuous delivery

of valuable software.

2. Welcome changing

requirements, even late in

development. Agile processes

harness change for the

customer's competitive

advantage.

3. Deliver working software

frequently, from a couple of

weeks to a couple of months,

with a preference to the

shorter timescale.

4. Business people and

developers must work together

daily throughout the project.

Requirements process


• There is no “standard way” to gather requirements in Agile development

– Could be a normal “Software Requirements Document”

– But it is better to be more lightweight

One way to collect requirements:

Start with a much slimmer “initial

requirements document” at the beginning of

the iterations…

Initial list of overall “systems capabilities”

– written in the form of User Stories

Plus a section containing “global non-

functional requirements” (security,

reliability, performance, usability, etc.)

The list of system capabilities and global

non functional requirements will be the first

draft of the SRD.

In each iteration, elaborate a small set of

the functional requirements (the high-

priority behavior)

This avoids creating a big requirements

document too soon

A good strategy is to delay writing most of

the “fine details” in the requirements until

the iteration when they will be

implemented

Why? Because you will have learned

more about the problem…

For some key requirements, create some

acceptance tests at the same time as you

write the requirements

How hard is it to be Agile?

• “Don’t do Agile, be Agile”

– Just doing “development in iterations” isn’t enough

• Agile Development is about:

– Keeping the process lightweight

– Making real progress in each iteration

– Communicating – face-to-face when possible

– Actively gathering customer input – early and

often

– Being willing to make minor changes to your

process


Agile Modeling

• The purpose of modeling is primarily to

understand, not to document

– Discover, understand, and share the

understanding

• A collection of values, principles, and

practices for modeling software in an effective

and light-weight manner

– Model with a purpose, use multiple models, travel

light, content is more important, know the models

and the tools, adapt locally


Agile Modeling Practices

• Don’t model to all or most of the software

design.

• Use the simplest tool possible.

• Don’t model alone, model in pairs.

• Create models in parallel.

• Use “good enough” simple notation while

sketching.

• Know that all models will be inaccurate.

• Developers should do the modeling for

themselves.


Agile Methodologies


Extreme Programing (XP)


What is

Extreme Programming (XP) ?

• “XP is a lightweight methodology for small-to-

medium-sized teams developing software in

the face of vague or rapidly changing

requirements.” (Kent Beck,1990’s)

• An agile development methodology

• 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


XP - The 12 Practices

1. The Planning Game

2. Small Releases

3. Metaphor

4. Simple Design

5. Testing

6. Refactoring

7. Pair Programming

8. Collective Ownership

9. Continuous Integration

10. 40-Hour Workweek

11. On-site Customer

12. Coding Standards


1-The Planning Game

• Planning for the upcoming iteration– Predicting what will be accomplished by the due date

– Determining what do to next

• Uses stories provided by the customer

• Technical persons determine schedules, estimates,

costs, etc

• A result of collaboration between the customer and

the developers

• There are 2 key planning steps in XP addressing

these 2 question– Release Planning

– Iteration Planning


1-The Planning Game

• Advantages: – Reduction in time wasted on useless features

– Greater customer appreciation of the cost of a

feature

– Less guesswork in planning

• Disadvantages:– Customer availability

– Is planning this often necessary?


2-Small Releases

• Small in terms of functionality

• Less functionality means releases

happen more frequently

• Support the planning game


2-Small Releases Cont.

• Advantages:

– Frequent feedback

– Tracking

– Reduce chance of overall project slippage

• Disadvantage:

– Not easy for all projects

– Not needed for all projects

– Versioning issues


3-Metaphor

• The oral architecture of the system

• A common set of terminology


3-Metaphor Cont.

• Advantages:

– Encourages a common set of terms for the

system

– A quick and easy way to explain the system

• Disadvantages:

– Another opportunity for miscommunication

– The system is often not well understood as a

metaphor


4–Simple Design

• K.I.S.S.

• Do as little as needed, nothing more


4-Simple Design Cont.

• 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


5-Testing

• Unit testing and Functional Tests

• Test a little, code a little – Test-first programming

• Tests give confidence in the system

• Tests give courage to change the system


5-Testing Cont.

• 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


6-Refactoring

• Goal : Optimal code design

• Changing how the system does something

but not what is done

• Improves the quality of the system in some

way


6-Refactoring Cont.

• Advantages:– Prompts developers to proactively improve the

product as a whole

– Increases developer knowledge of the system

• Disadvantages:

– Not everyone is capable of refactoring

– Refactoring may not always be appropriate

– Would upfront design eliminate refactoring?


7-Pair Programming

• Two Developers, One monitor, One

Keyboard

• One “drives” and the other thinks

• Switch roles as needed


7-Pair Programming Cont.

• Advantages:– 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?

• Disadvantage:– Many tasks really don’t require two programmers


8-Collective Ownership

• Goal : Spread responsibility to whole team

• The idea that all developers own all of the

code

• Any developer can change any code if

needed to complete a task

• Enables refactoring


9-Continuous Integration

• Goal : reduce the impact of adding new

features

• New features and changes are worked into

the system immediately

– Merge tasks and tests to whole as soon as they

are completed


9-Continuous Integration Cont.

• Advantages:

– 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


10 – 40-Hour Week

• The work week should be limited to 40 hours

per week

• Regular overtime is a symptom of a problem

and not a long term solution


10 – 40-Hour Week Cont.

• Advantages:

– Most developers lose effectiveness past 40-Hours

– Value is placed on the developers well-being

– Management is forced to find real solutions

• Disadvantages:

– Some may like to work more than 40-Hours


11 – On-Site Customer

• Just like the title says!

• Acts to “steer” the project

• Gives quick and continuous feedback to the

development team

– E. g. Product owner in scrum


11 - On-Site Customer Cont.

• 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 does

– May not have authority to make many decisions

– Loss of work to the customer’s company


12 – Coding Standards

• All code should look the same

• It should not possible to determine who

coded what based on the code itself


12 – Coding Standards Cont.

• Advantages:

– 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


XP – Advantages

• Built-In Quality

• Overall Simplicity

• Programmer Power

• Customer Power

• Synergy Between Practices


XP – Disadvantages

• Informal, little, or no documentation

• Scalability

• Contract Issues

• Misconception on the cost of change

• Tailoring


Scrum


Scrum in 100 words

• Scrum is an agile process that allows us to focus on

delivering the highest business value in the shortest

time.

• It allows us to rapidly and repeatedly inspect actual

working software (every two weeks to one month).

• The business sets the priorities. Our teams self-

manage to determine the best way to deliver the

highest priority features.

• Every two weeks to a month anyone can see real

working software and decide to release it as is or

continue to enhance for another iteration.


Characteristics

• Self-organizing teams

• Product progresses in a series of month-long

“sprints”

• Requirements are captured as items in a list

of “product backlog”

• No specific engineering practices prescribed

• Uses generative rules to create an agile

environment for delivering projects

• One of the “agile processes”


How Scrum Works?


Sprints

• Scrum projects make progress in a series of “sprints”

– Analogous to XP iterations

• Target duration is one month

– +/- a week or two• But, a constant duration leads to a better

rhythm

• Product is designed, coded, and tested during the sprint


Sequential vs. Overlapping Dev.


Requirements Design Code Test

No changes during the sprint


SprintInputs Tested Code

Change

Plan sprint durations around how long you can commit to keeping change out of the sprint

Scrum Framework

• Roles :

– Product Owner

– Scrum Master

– Team

• Ceremonies:

– Sprint Planning

– Sprint Review

– Sprint Retrospective

– Daily Scrum Meeting

• Artifacts :

– Product Backlog,

– Sprint Backlog,

– Burndown Chart


Product Owner

• Define the features of the product

• Decide on release date and content

• Be responsible for the profitability of the

product (ROI)

• Prioritize features according to market value

• Adjust features and priority every iteration, as

needed

• Accept or reject work results.


The Scrum Master

• Represents management to the project

• Responsible for enacting Scrum values and

practices

• Removes impediments

• Ensure that the team is fully functional and

productive

• Enable close cooperation across all roles and

functions

• Shield the team from external interferences


Scrum Team

• Typically 5-10 people

• Cross-functional

– QA, Programmers, UI Designers, etc.

• Members should be full-time

– May be exceptions (e.g., System Admin, etc.)

• Teams are self-organizing

– What to do if a team self-organizes someone off

the team??

– Ideally, no titles but rarely a possibility

• Membership can change only between sprints


Ceremonies

• Sprint Planning Meeting

• Sprint

• Daily Scrum

• Sprint Review Meeting


Spring Planning Meeting


Sprint Planning

Meeting

Product Backlog

Team Capabilities

Business Conditions

Technology

Current Product

Sprint Backlog

Sprint Goal

Parts of Sprint Planning Meeting

• 1st Part:

– Creating Product Backlog

– Determining the Sprint Goal.

– Participants: Product Owner, Scrum Master,

Scrum Team

• 2nd Part:

– Participants: Scrum Master, Scrum Team

– Creating Sprint Backlog


Pre-Project/Kickoff Meeting

• A special form of Sprint Planning Meeting

• Meeting before the begin of the Project


Sprint

• A month-long iteration, during which is

incremented a product functionality

• NO outside influence can interfere with the

Scrum team during the Sprint

• Each Sprint begins with the Daily Scrum

Meeting


Daily Scrum

• Parameters– Daily

– 15-minutes

– Stand-up

– Not for problem solving

• Three main questions:1.What did you do since the last meeting?

2.What obstacles are you encountering?

3.What do you plan to accomplish by the next team meeting?


Daily Scrum

• Is NOT a problem solving session

• Is NOT a way to collect information about

WHO is behind the schedule

• Is a meeting in which team members make

commitments to each other and to the Scrum

Master

• Is a good way for a Scrum Master to track the

progress of the Team


Scrum FAQs

• Can Scrum meetings be replaced by emailed status

reports?

– No!

• Entire team sees the whole picture every day

• Create peer pressure to do what you say you’ll do


Sprint Review Meeting

• Team presents what it accomplished during the sprint

• Typically takes the form of a demo of new features or

underlying architecture

• Informal

– 2-hour prep time rule

• Participants

– Customers

– Management

– Product Owner

– Other engineers


Product Backlog

• A list of all desired work (features and

requirements ) on the project

– Usually a combination of

• story-based work (“let user search and replace”)

• task-based work (“improve exception handling”)

• List is prioritized by the Product Owner

– Typically a Product Manager, Marketing, Internal

Customer, etc.


Product Backlog

• Requirements for a system, expressed as a

prioritized list of Backlog Items (requirements

or features).

• Is managed and owned by a Product Owner

• Spreadsheet (typically)

• Usually is created during the Sprint Planning

Meeting

• Can be changed and re-prioritized before

each PM


Sample Product Backlog

67CSE 5324, Ali Sharifara

From Sprint Goal to Sprint Backlog

• Scrum team takes the Sprint Goal and

decides what tasks are necessary

• Team self-organizes around how they’ll meet

the Sprint Goal

– Manager doesn’t assign tasks to individuals

• Managers don’t make decisions for the team

• Sprint Backlog is created


Sprint Backlog during the Sprint

• Changes

– Team adds new tasks whenever they need to in

order to meet the Sprint Goal

– Team can remove unnecessary tasks

– But: Sprint Backlog can only be updated by the

team

• Estimates are updated whenever there’s new

information


Sprint Backlog

• A subset of Product Backlog Items, which

define the work for a Sprint

• Is created ONLY by Team members

• Each Item has it’s own status (To do, In

progress, Resolved, Verified and tested)

• Should be updated every day


Sprint Backlog

• No more than 300 tasks in the list

• If a task requires more than 16 hours, it

should be broken down

• Team can add or subtract items from the list.

(Product Owner is not allowed to do it)


Sample Sprint Backlog


Sprint Burndown Chart

• Depicts the total Sprint Backlog hours

remaining per day

• Shows the estimated amount of time to

release

• Ideally should burn down to zero to the end of

the Sprint

• Actually is not a straight line

• Can bump UP


Burndown Chart - Example


Actual

Ideal

Release Burndown Chart

• Will the release be done on right time?

• X-axis: sprints

• Y-axis: amount of hours remaining

• The estimated work remaining can also burn

up


Scrum Pros/Cons

• Advantages

– Completely developed and tested features in short iterations

– Simplicity of the process

– Clearly defined rules

– Increasing productivity

– Self-organizing

– Each team member carries a lot of responsibility

– Improved communication

– Combination with Extreme Programming

• Drawbacks

– “Undisciplined hacking” (no written documentation)

– Violation of responsibility


Scrum


Let’s Review Scrum again!


https://www.youtube.com/watch?v=XU0llRltyFM

https://www.youtube.com/watch?v=XU0llRltyFM

agile development - university of texas at...

Documents