Background

Background of Agile method

[Rapid software development]

• The most critical requirement for software systems
  • "Poor quality에 1년 마다 나오는 SW" vs "High quality에 10년 마다 나오는 SW"
• Agile method > Plan-driven methods
  • The need for rapid SW development that can handle changing requirements.
  • ex) Extreme Programming(1999), Scrum(2001), ...

Agile development

[Common characteristics of agile methods]

• Program specification, design and implementation are interleaved.

  • No detailed system specification, minimized design documentation

• The system is developed as a series of versions(v1 -> v2 -> ... v10) or increments.

  • Stakeholders propse new requirements for a later version of the system.

• Extensive tool support is used to support the SW development.

  • Automated testing tools, automated user interface production tools, ...

Plan-driven and Agile development

[Plan-driven approach]

• Iteration occurs within activities.
• Formal documents are used to communicate between stages of the process.
  

[Agile approach]

• Iteration occurs across activities.
• The requirements and the design (implementation) are developed together.

Agile methods

What is Agile methods

[Plan-driven approach vs Agile approach]

• Motivation
  • Dissatisfaction with this heavyweight, plan-driven development approach.
  • Time: documentation and design > SW development and testing.
• Agile methods (in the late 1990s)
  • Focus on the software itself rather than on its documentation.
  • Deliver working SW quickly.
  • Evolve SW quickly to meet changing requirements.

Manifesto (선언서) for Agile Software Development

• 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

[All agile methods share a set of principles.]

• Customer involvement !

  • customer are closely involved throughout the development process.
    (Providing and prioritizing new system requirments and evaluating the iterations of the system.)

• Incremental delivery

  • The SW is developed in increments.

• Embrace change

  • Expect the system requirements to change and design the system to accommodate these changes.

• Maintain simplicity

  • Focus on simplicity in the SW and in the development process.
  • Eliminate the complexity from the system actively.

• People, not process

  • Team members should be left to develop their own ways of working without prescriptive processes.

Agile development techniques ("Extream Programming (XP)")

[Extreme Programming (XP)]

• Push an iterative development to "extreme" levels.
  • Several versions of a system are developed, integrated, and tested in a day.
    

[Extreme Programming Practices]

1. Collective ownership

   • The pairs of developers work on all areas of the system.

   • All the developers take responsibility for all of the code.

2. Continuous integration (CI)

   • As soon as the work is complete, it is integrated into the whole system.

   • After the integration, all the unit tests in the system must pass.

3. Incremental planning

   • Requirements (e.g., story cards) are determined by the time available and their relative priority.

4. On-site customer

   • The customer, a member of the development team, brings system requirements to the implementation team.

5. Pair programming

   • Developers work in pairs and check each other's work.

6. Refactoring

   • Refactor the code continuously for keeping the code simple.

7. Simple design

   • For the design, it is enough to meet the current requirements only.

8. Small releases

   • The minimal useful set of functionality is developed first.
   • Releases of the system incrementally add functionality to the first release.

9. Sustainable pace

   • Large amounts of overtime are not considered acceptable.

10. Test first development

    • Write tests for a new piece of functionality before its implementation.

In practice, companies choose the XP practices selectively.

[User Stories]

• A scenario of use that might be experienced by a system user.
  1) Develop a "story card" that briefly describes a story that encapsulates the customer needs.
  2) Break the story and down into tasks.
  3) Estimate the effort and resources required for implementing each task.
  4) Prioritize the stories for implementation that can be used to deliver useful business support.

• Pros and Cons
  • (+) Easy understanding of the story.
  • (-) Incompleteness of the story.

Test-first development

• Key features of testing in XP
  • Test-first development
  • Incremental test development from scenarios.
  • User involvement in the test development and validation.
  • The use of automated testing frameworks. ex) J unit
• Assume that user stories have been developed, and these have been broken down into a set of task cards.
  
  

[Problems in test-first development]

• Programmers sometimes take shor cuts when writing test?
• Some tests can be very difficult to write incrementally.
• It is difficult to judge the completeness of a set of tests.
  • Complete coverage?

Pair programming

[What is pair programming?]

• Programmers work in pairs to develop the software.
• Pairs are created dynamically so that all team members work with each other during the development process.

[Advatages]

• Support collective ownership and responsibility for the system.
• Act as an informal review process because each line of code is looked at by at least two people.
• Encourage refactoring to improve the software structure.

Agile project management ("Scrum")

[Motivation]

• The informal planning and project control clashed(충돌하다) with this business requirement for visibility.
• Agile development teams should manage the time and resources available to the team effectively.

[Scrum]

• A framework for oraganizing agile projects and providing external visibility of what is going on at least.
• Using new terminologies to differentiate if from conventional project management. (e.g., ScrumMaster, Sprint, Product backlog)

[Scrum termiology]

• Development team

  • A self-organizing group of software developers. (<7 people)
  • Developing the software and other essential project documents.

• Sprint

  • A development iteration. (2~4 weeks)

• Scrum

  • A daily meeting that reviews progress and prioritizes work to do that day.
  • A short face-to-face meeting that includes the whole team. (Ideal case)

• Scrum Master (= Project manager와 비슷)

  • Checking that the Scrum process is followed.
  • Guiding the team in the effective use of Scrum.
  • Interfacing with the rest of the company.

• Product backlog

  • A list of "to do" items which the Scrum team must tackle(다루다).
  • ex) User stories, SW feature definitions, SW requirements, ...

• Product owner

  • Identifying product features or requirements.
  • Reviewing the product backlog to ensure that the project continues to meet critical business needs.
  • ex) A customer, product manager, other stakeholder representative.

• Velocity

  • Estimating how much backlog can be covered by a team in a single sprint.

[The Scrum process or sprint cycle]

• Sprint are never extended to take account of unfinished work. Items are returned to the product backlog. (스프린트 기간 연장은 허용되지 않고, 완료되지 않은 작업 항목은 backlog로 들어감)

• A Scrum board is used for the daily interactions among the teams.

[The benefits of Scrum]

• The product is broken down into a set of manageable and understandable chunks that stakeholders can relate to.

• Unstable requirements do not hinder progress.

• The whole team has visibility of everything. (team communication 상승)

• Customers see on-time delivery of increments and gain feedback.

• Trust between customers and developers is established. (모든 sprint 마다 sippable sw가 있음!)

Scaling agile methods

[Practical problems with agile methods]

• Contractual issues(계약상의 issue) can be a major problem when agile methods are used.

• Agile methods are most appropriate for new SW development rather than for SW maintenance.

• SW development now involves worldwide distributed teams rather than small co-located teams.

[Problems when using agile methods for SW maintenance]

• Lack of product documentation

  • There is no formal documentation, which tells the software engineer what the system is supposed to do.

• Development team continuity(연속성)

  • If an agile development team is broken up, the implicit knowledge is lost.
  • It is difficult for new team members to build up the same understanding of the system and its components.

• Keeping customers involved (maintenance에서는 쉽지 않음)

[Agile methods for large systems]

• Agile methods have to evolve to be used for large-scale SW development.
• 6 principal factors contribute to the complexity of large-scale SW systems.
  

1. System of systems

   • Separate teams develop each system in different places and time zones.
   • It is impossible for each team to have a view of the whole system.

2. Brownfield development(새로운 건물이나 인프라를 기존에 개발되어 사용 중인 지역 또는 건물의 근처에 짓는 것을 의미)

   • Include and interact with a number of existing systems.

3. System configuration

   • A significant fraction of the development is concerned with system configuration rather than original code development.

4. Regulatory constraints

   • Large systems are constrained by external rules and regulations limiting the way that they can be developed.

5. Prolonged procurement(제품 또는 서비스를 확보하기 위한 구매나 계약 절차가 시간이 오래 걸리는 경우)

   • It is difficult to maintain coherent teams who know about the system.

6. Diverse stakeholders

   • It is infeasible to involve all of the different stakeholders in the development process.

Large system development

[Common features of approaches to scaling agile methods]

• A completely incremental approach to requirements engineering is impossible.

• There cannot be a single product owner or customer representative.

• It is not possible to focus only on the code of the system.

• Cross-team communication mechanisms have to be designed and used.

• Continuous integration, where the whole system is built every time any developer checks in a change, is practically impossible.

[Agile for large system: Multi-team Scrum]

• Role replication: Each team has a Product Owner and ScrumMaster.

• Product architects: Each team chooses a product architect and these architects collaborate to design the overall system architecture.

• Release alignment(조정): The dates of product releases from each team are aligned so that a demonstrable and complete system is produced.

• Scrum of Scrums: There is a daily Scrum of Scrums where representatives from each team meet to discuss progres and plan work to be done.

Summary