it specialist program initiative for reality-based advanced learning it spiral...

IT Specialist Program Initiative for Reality-based Advanced Learning http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/

IT Spiral 先端ソフトウェア工学シリーズ

Agile ProgrammingAgile Programming

Hajimu IidaSoftware Design Laboratory,

Nara Institute of Science and Technology

Mike BarkerNara Institute of Science and Technology

IT Specialist Program Initiative for Reality-based Advanced Learning

http://sel.ist.osaka-u.ac.jp/topics/IT-Spiral/index.htm2007/4/1

2

What is agile programming?What is agile programming?

13 principlesExamples XP (extreme programming): Bec

k Scrum Agile Unified Process: Larman EVO Crystal: Cockburn Adaptive Software Development

(ASD)Feature Driven Development (FD

D)Dynamic Systems Development

Method (DSDM)

XP Prinicples: Rapid feedback Simplicty Incremental changes Embrace change Quality work

XP Practices Pair programming refactoring, unit and accepta

nce tests, collective code ownership, continous integration



3

The Agile Manifesto (www.agilealliance.com)The Agile Manifesto (www.agilealliance.com)

We valueIndividuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan



4

The Agile PrinciplesThe Agile Principles

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

3. Deliver working software frequently

4. Businesspeople and developers must work together daily throughout the project

5. Build projects around motivated individuals. Given 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

9. The sponsors, developers, and users should be able to maintain a constant pace indefinitely (Not in all lists)

10.Continuous attention to technical excellence and good design enhances agility

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

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

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



5

Agile AssumptionsAgile Assumptions1. Visibility: project visibility can be achieved solely through delivery of working code.2. Iteration: a project can always be structured to be short fixed-time iterations3. Customer-interaction: customer teams are available for frequent interaction when

needed by developers.4. Team-communication: developers are co-located so they can have frequent, intensive

communication5. Face-To-Face: face-to-face interaction is the most productive method of

communication with customers and among developers6. Documentation: developing extensive and consistent documentation and software

models is counterproductive.7. Changing requirements: requirements always involved because of changes in

technology, customer needs, and business domains, or acquisition of new customers8. Cost-of-change: the cost of change does not dramatically increase over time9. Team-experience: developers have the experience needed to define and adapt their

processes appropriately.10.Self-evaluation: teams are able and willing to evaluate themselves11.Self-organization: the best architectures, requirements, and designs emerge from self-

organizing teams12.Quality-assurance: the evaluation of software artifacts (products and processes) can

be restricted to frequent informal interviews, reviews, and code testing.13.Continuous-redesign: systems can be continuously redesigned (re-factored) and still

maintain their structural and conceptual integrity14.Application-specific-development: reusability and generality should not be goals of

application-specific software development Turk, France, and Rumpe (2005)



6

Agile LimitationsAgile Limitations

Personnel limitationsLimited support for distributed development environments

Limited support for subcontractingLimited support for development involving large teams

Product limitationslimited support for building reusable artifactsLimited support for developing safety critical software

Limited support for developing large, complex software Turk, France, and Rumpe (2005)



7How does it differ from disciplined How does it differ from disciplined development?development?

Disciplined development: Waterfall and spiral



8heavyweight and lightweight software heavyweight and lightweight software development methodologiesdevelopment methodologies 　 based on factors such as

1. Planning and documentation2. Well-defined phases in the development process3. Composition of the development team4. Use of well elaborated modeling and coding

techniques to generate software development artifacts

Agile methodologies often characterized as Incremental Cooperative Straightforward Adaptive Meso and Jain (200

6)



9When should you use agile When should you use agile development?development? Barry Boehm’s five dimensionsComplex Adaptive SystemsAgile Distributed Development



10

Complex adaptive systems (CAS)Complex adaptive systems (CAS)

Principle of open systemsPrinciple of interactions and relationshipsPrinciple of transformative feedback loopsPrinciple of emergent behaviorPrinciple of distributed controlPrinciple of shallow structurePrinciple of growth and evolution us

Meso and Jain (2006)



11

Mapping Agile and CASMapping Agile and CAS

Agile practice CAS principle

Frequent releases Growth and evolution

Frequent feedback Transformative feedback loops

Positive value of change

Emergent order

Loose environment Distributed control

Minimal planning Growth and evolutionEmergent order

Continuous learning and improvement

Growth and evolutionInteractions and relationships

Working software product

Path of least effort

Meso and Jain (2006)



12Challenges of Agile Distributed Challenges of Agile Distributed

DevelopmentDevelopment

Ramash, Cao, Mohan, and Xu (2006)



13Practices to achieve distribution and Practices to achieve distribution and

agilityagility1. Continuously adjust the process

Planning iterations to finalize requirements and develop designs Documenting requirements at different levels of formality

2. Facilitate knowledge sharing Maintain product/process repository Focus on well-understood functionality rather than critical new

functionality Short cycle but not time-boxed development

3. Improve communication Synchronized work hours Informal communication but through formal channels Balanced coordination Constant communication

4. Build trust Frequent visits by distributed partners Sponsor visits Build cohesive team culture

5. Trust but verify Distributed QA Supplement informal communication with documentation

Ramash, Cao, Mohan, and Xu (2006)



14Why should you use agile Why should you use agile

development?development?



15Test Driven Development Drives Software Test Driven Development Drives Software

QualityQuality Write unit tests BEFORE you write code Not just unit tests, also functional, system, end-to-end, performance, security, and usability tests

TDD code practices mean more tests passed and fewer defects

Why does it help?Tests provide a common language for users and developers

Tests define a feature or story’s scopeTest-first helps good design Crispin (2006)



16

Agile Methodology Adoption DecisionsAgile Methodology Adoption Decisions

Critical adoption factorsProject

Duration of the project Acceptance of change Criticality of project

Team Team size Skill level of team

Customer Location of customer Customer involvement

Organization Organizational and reporting structure Process Documentation requirements Layout of the workspace

McAvoy and Sammon (2005)



17

Practice and projectsPractice and projects

See McAvoy and Sammon (2005). They used a list of critical adoption factors, then had the students assign weights and rankings for two case studies.



18

Ａｄｏｐｔｉｏｎ　ＡｓｓｅｓｓｍｅｎｔＡｄｏｐｔｉｏｎ　Ａｓｓｅｓｓｍｅｎｔ　Ｍａｔｒｉｘ　Ｍａｔｒｉｘ

ＷｅｉｇｈｔＲａｎｋＲｅｓｕｌｔ

Duration of the project

Acceptance of change

Criticality of project

Team size

Skill level of team

Location of customer

Customer involvement

Organizational and reporting structure

Process

Documentation requirements

Layout of workplace



19



20A Class Project: Putting the Agile principles A Class Project: Putting the Agile principles

and practices in contextand practices in context

Consider the Agile Manifesto, principles and practices.

What are the Disciplined principles and practices?

How do you personally weight these items?How do you think companies weight them?Consider three groups: developers, companies, and users. Why would these principles or practices be important to them? What do they want?



21

Why do projects fail?Why do projects fail?

Requirements are not clearly communicatedRequirements do not solve the business problemRequirements change prior to the completion of the project

Software (code) has not been testedSoftware has not been tested as the user will use itSoftware developed so that it is difficult to modifySoftware used for functions for which it was not intended

Projects not staffed with resources requiredSchedule and scope commitments made before understanding requirements or technical risksLindstrom and Jeffries (2004)



22

Extreme Programming (XP)Extreme Programming (XP)

Instead of “what are all of the practices I might ever need on a software project?” ask “what is the simplest set of practices I could possibly need and what do I need to do to limit my needs to those practices?”

XP Values:CommunicationSimplicityFeedbackCourage Lindstrom and Jeffries (2004)



23

Extreme Programming (XP) PracticesExtreme Programming (XP) Practices

Practices:Whole Team: every contributor to the project is a member,

including the customer Planning Game: simple planning and trackingSmall releases: small, fully integrated releases that pass

allAcceptance Tests: defined by the customerPair programmingSimple designTest-driven developmentDesign improvementContinuous integrationTeam code ownershipCoding standard: consistent styleMetaphor: common and simple picture of what the system

looks likeSustainable pace

Lindstrom and Jeffries (2004)



24

Extreme Programming (XP) PracticesExtreme Programming (XP) Practices




25

Whole TeamWhole Team

All contributors sit together as members of one teamMust include a business representative, the customer, who

provides requirements, sets priorities, and steers the project.Must include programmers.May include testers, who help the customer define the

customer acceptance testsMay include analysts, who help the customer define the

requirementsOften includes a coach who helps the team stay on track and

facilitates the processMay include a manager, who provides resources, handles

external communication, and coordinates activitiesRoles are not necessarily the exclusive property of just one

individual. Everyone on an XP team contributes in any way that they can.




26

Planning GamePlanning Game

Two key questions: predict what will be accomplished by the due date, and determine what to do next.

Focus on steering the project instead of trying to predict what will be needed and how long it will take.

Release planning: customer presents desired features, programmers estimate their difficulty, customer lays out plan for project.

Iteration planning: two week iterations, with running useful software. Customer presents features desired for two weeks, programmers estimate tasks and commit to what will be undertaken for current iteration.




27

Customer TestsCustomer Tests

as part of presenting each desired feature, the customer defines one or more automated acceptance tests

Team builds the tests first, then uses them to prove that the feature is implemented correctly

Use automated testing and always run the full set of regression tests




28

Small ReleasesSmall Releases

the team releases running, tested software, delivering business die you chosen by the customer, with every iteration.

always release software to the end-users frequently.




29

Simple DesignSimple Design

bill into a simple design.Start simple, and stay simple.

Design fits current functionalityDesign is neither one time nor upfront, but all-the-time.




30

Pair ProgrammingPair Programming

two programmers sit side-by-side at the same machine to build production software




31

Test Driven DevelopmentTest Driven Development

Add a test, then make the function work




32

Design ImprovementDesign Improvement

Deliver business value in every iterationcontinuous design improvement through re-factoringRemove duplicationIncrease cohesion and lower coupling

comprehensive testing




33

Continuous IntegrationContinuous Integration

build many times and test every timeInfrequent integration means

lack of practice with integration more bugsLong code freezes




34

Collective Code OwnershipCollective Code Ownership

any pair of programmers can improve any code any time




35

Coding StandardCoding Standard




36

MetaphorMetaphor

Simple description of how the program works




37

Sustainable PaceSustainable Pace

work hard but sensiblyMaximize productivity week in and week out




38

Other practices sometimes usedOther practices sometimes used

open workspace Retrospectives: feedback on how performing

self-directed teams: the team makes the decisions

customer teams: instead of one Customer, a team that handles multiple stakeholders, resource allocation, and feedback




39

Making Agile Methodologies WorkMaking Agile Methodologies Work

Management and organizational issues Conflict with organizational culture Management style: shift from command-and-control to leadership-and-collaboration. Project manager role changes from planner/controller to facilitator

Organizational forms: blend autonomy and cooperation to provide flexibility, responsiveness, and synergy

Move from managing software development knowledge through documentation to tacit knowledge in teams

Teams more important than individual roles, requiring changes in performance measurements and reward systems

Nerur, Mahapatra, and Mangalaraj (2005)



40


People issues Agile methodologies require cooperative social process, communication, collaboration, community of members who value and trust each other (a team). Programmers used to working alone find shared learning, reflection workshops, pair programming, and collaborative decision making hard.

Requires high level of competence. Requires customers to be collaborative, representative, authorized, committed, and knowledgeable – can the company find such customers? Nerur, Mahapatra, and Mangalaraj (2005)



41


Process issues changing focus from process to people and features difficult

Changing to short, iterative, test-driven development emphasizing adaptability

can agile methods be used with large, scalable projects?

selecting an appropriate agile method




42


Technology issues (tools and techniques) Appropriateness of existing technology and tools

new skill sets – refactoring, configuration management, JUnits




43

What research shows?What research shows?

A few case studies and experience reports pair programming studies“hard, empirically-based economic evidence is lacking” (p. 95)

Erickson, Lyytinen, and Siau (2005)



44

Traditional patterns or processesTraditional patterns or processes

Systems development life cycle (SDLC) Spiral method Waterfall approach Rapid Application Development Unified Process Object-oriented PrototypingCMM and CMMI Almost all have analysis, design, coding, test steps Erickson, Lyytinen, and Siau (2005)



45

XP Principles and ActivitiesXP Principles and Activities

Four valuesCommunicationsSimplicityFeedbackCourage

Four ActivitiesCodingTestingListeningDebugging

Erickson, J., Lyytinen, K., & Siau, K. (2005)



46

Agile ModelingAgile Modeling

simplicityIterative developmentRobustnessIncremental releasesStaying on taskProducing a quality productCreating models and accompanying documentation only as necessary

Multiple modelsFast and clear feedback on changes to the modelDiscard models and documentation to go back more than a few iterations




47

What is wrong with this picture?What is wrong with this picture?

60% of a typical system’s O&M budget goes to band-aid solutions to inadequate analysis and development

2/3 to ¾ of information systems developed are failures because they do not provide required functionality

programmers are taught to build throwaway systems which are often obsolete before the project is complete

The users of systems are systematically excluded from development (p. 97)




48

Is this a paradigm change?Is this a paradigm change?

Kuhn: paradigm is “coherent tradition of scientific research” including knowledge, techniques, research agendas, etc.

Consider paradigm as “coherent tradition of software development”

HistorySoftware starts in 1950s1960s: software engineering and waterfall metaphor

Rajlich (2006)



49

Is this a paradigm change?Is this a paradigm change?

Software evolution based onEmpirical studies of actual software life cycles

DevelopmentEvolution or growthServicing and code decayPhase-outClose-down

Iterative program development

Rajlich (2006)



50

New Research AgendaNew Research Agenda

Incremental changeHow can we summarize, model, formalize, improve, tea

ch, and support the practice of incremental change? Concept location: where do changes in existing softwar

e have to be made? Impact analysis: what components will be affected by a

n incremental change? What change propagation needs to happen to make the change?

Refactoring Code decayCognitive aspects of software development and program comprhension

Rajlich (2006)

it specialist program initiative for reality-based advanced learning it spiral...

Documents