Bài giảng Introduction to Software Engineering - Week 10: Agile software development - Nguyễn Thị Minh Tuyền

is followed and guides the team in the effective use of 
 Scrum. He or she is responsible for interfacing with the rest of the 
 ScrumMaster company and for ensuring that the Scrum team is not diverted by 
 outside interference. The Scrum developers are adamant that the 
 ScrumMaster should not be thought of as a project manager. 
 Others, however, may not always find it easy to see the difference.
 Sprint A development iteration. Sprints are usually 2-4 weeks long.
 An estimate of how much product backlog effort that a team can 
 cover in a single sprint. Understanding a team’s velocity helps 
 Velocity
 them estimate what can be covered in a sprint and provides a 
 basis for measuring improving performance. 38
 Scrum process
 Assess Select
 Outline planning
 and architectural Project closure
 design
 Review Develop
 Sprint cycle
 39
NGUYỄN Thị Minh Tuyền
 Scrum sprint cycle
 Scrum
Review work Select Plan Review
 Sprint
 to be done items sprint sprint
 Potentially
 Product Sprint
 shippable
 backlog backlog
 software
 40
 Sprint cycle
£ Fixed length, normally 2–4 weeks. They
 correspond to the development of a release of the
 system in XP.
£ The starting point for planning is the product
 backlog, which is the list of work to be done on the
 project.
£ The selection phase involves all of the project
 team who work with the customer to select the
 features and functionality to be developed during
 the sprint.
 41
 Sprint cycle
£ Once these are agreed, the team organize
 themselves to develop the software.
 p During this stage the team is isolated from the customer
 and the organization, with all communications
 channelled through the so-called ‘Scrum master’.
£ The role of the Scrum master is to protect the
 development team from external distractions.
£ At the end of the sprint, the work done is reviewed
 and presented to stakeholders. The next sprint
 cycle then begins.
 42
 Teamwork in Scrum
£ The ‘Scrum master’ is a facilitator who arranges daily
 meetings, tracks the backlog of work to be done,
 records decisions, measures progress against the
 backlog and communicates with customers and
 management outside of the team.
£ The whole team attends short daily meetings where
 all team members share information, describe their
 progress since the last meeting, problems that have
 arisen and what is planned for the following day.
 p This means that everyone on the team knows what is
 going on and, if problems arise, can re-plan short-term
 work to cope with them.
 43
 Scrum benefits
£ The product is broken down into a set of
 manageable and understandable chunks.
£ Unstable requirements do not hold up progress.
£ The whole team have visibility of everything and
 consequently team communication is improved.
£ Customers see on-time delivery of increments and
 gain feedback on how the product works.
£ Trust between customers and developers is
 established and a positive culture is created in
 which everyone expects the project to succeed.
 44
 Distributed Scrum
 The ScrumMaster 
 should be located with 
 the development team 
 so that he or she is The product owner 
 aware of everyday should visit the 
 Videoconferencing 
 problems. developers and try to 
 between the product 
 establish a good 
 owner and the 
 relationship with them. 
 development team
 It is essential that they 
 trust each other.
 Distributed Scrum
 Real-time communica-
A common development tions between team 
environment for all teams members for informal 
 communication, 
 Continuous integration, particularly instant 
 so that all team messaging and video 
 members can be aware calls.
 of the state of the 
 product at any time.
 45
 Topics covered
1. Agile methods
2. Extreme programming
3. Agile project management
4. Scaling agile methods
 46
 Scaling agile methods
£ Agile methods have proved to be successful for small and
 medium sized projects that can be developed by a small
 co-located team.
£ It is sometimes argued that the success of these methods
 comes because of improved communications which is
 possible when everyone is working together.
£ Scaling up agile methods involves changing these to
 cope with larger, longer projects where there are multiple
 development teams, perhaps working in different
 locations.
 47
 Scaling out and scaling up
£ ‘Scaling up’ is concerned with using agile methods
 for developing large software systems that cannot
 be developed by a small team.
£ ‘Scaling out’ is concerned with how agile methods
 can be introduced across a large organization with
 many years of software development experience.
£ When scaling agile methods it is important to
 maintain agile fundamentals
 p Flexible planning, frequent system releases, continuous
 integration, test-driven development and good team
 communications.
 48
 Practical problems with agile 
 methods
£ The informality of agile development is incompatible with the legal
 approach to contract definition that is commonly used in large
 companies.
£ Agile methods are most appropriate for new software development
 rather than software maintenance. Yet the majority of software costs
 in large companies come from maintaining their existing software
 systems.
£ Agile methods are designed for small co-located teams yet much
 software development now involves worldwide distributed teams.
 49
 Contractual issues
£ Most software contracts for custom systems are based
 around a specification, which sets out what has to be
 implemented by the system developer for the system
 customer.
£ However, this precludes interleaving specification and
 development as is the norm in agile development.
£ A contract that pays for developer time rather than
 functionality is required.
 p However, this is seen as a high risk my many legal departments
 because what has to be delivered cannot be guaranteed.
 50
 Agile methods and software 
 maintenance
£ Most organizations spend more on maintaining existing
 software than they do on new software development. So, if
 agile methods are to be successful, they have to support
 maintenance as well as original development.
£ Two key issues:
 p Are systems that are developed using an agile approach
 maintainable, given the emphasis in the development process of
 minimizing formal documentation?
 p Can agile methods be used effectively for evolving a system in
 response to customer change requests?
£ Problems may arise if original development team cannot be
 maintained.
 51
 Agile maintenance
£ Key problems are:
 p Lack of product documentation
 p Keeping customers involved in the development process
 p Maintaining the continuity of the development team
£ Agile development relies on the development team
 knowing and understanding what has to be done.
£ For long-lifetime systems, this is a real problem as the
 original developers will not always work on the system.
 52
 Agile and plan-driven methods
£ Most projects include elements of plan-driven and agile
 processes. Deciding on the balance depends on:
 p Is it important to have a very detailed specification and design
 before moving to implementation? If so, you probably need to use
 a plan-driven approach.
 p Is an incremental delivery strategy, where you deliver the
 software to customers and get rapid feedback from them,
 realistic? If so, consider using agile methods.
 p How large is the system that is being developed? Agile methods
 are most effective when the system can be developed with a
 small co-located team who can communicate informally. This may
 not be possible for large systems that require larger development
 teams so a plan-driven approach may have to be used.
 53
 Agile principles and organizational practice
 Principle Practice
Customer This depends on having a customer who is willing and able to 
involvement spend time with the development team and who can represent all 
 system stakeholders. Often, customer representatives have other 
 demands on their time and cannot play a full part in the software 
 development. 
 Where there are external stakeholders, such as regulators, it is 
 difficult to represent their views to the agile team.
Embrace change Prioritizing changes can be extremely difficult, especially in 
 systems for which there are many stakeholders. Typically, each 
 stakeholder gives different priorities to different changes.
Incremental delivery Rapid iterations and short-term planning for development does not 
 always fit in with the longer-term planning cycles of business 
 planning and marketing. Marketing managers may need to know 
 what product features several months in advance to prepare an 
 effective marketing campaign.
 54
 Agile principles and organizational practice
 Principle Practice
Maintain simplicity Under pressure from delivery schedules, team members may not have 
 time to carry out desirable system simplifications.
People not process Individual team members may not have suitable personalities for the 
 intense involvement that is typical of agile methods, and therefore may 
 not interact well with other team members.
 55
 Agile and plan-based factors
 System Team Organization
Type Lifetime Technology Distribution Contracts Delivery
Scale Regulation Competence Culture
 56
 System issues
£ How large is the system being developed?
 p Agile methods are most effective a relatively small co-located
 team who can communicate informally.
£ What type of system is being developed?
 p Systems that require a lot of analysis before implementation need
 a fairly detailed design to carry out this analysis.
£ What is the expected system lifetime?
 p Long-lifetime systems require documentation to communicate the
 intentions of the system developers to the support team.
£ Is the system subject to external regulation?
 p If a system is regulated you will probably be required to produce
 detailed documentation as part of the system safety case.
 57
 People and teams
£ How good are the designers and programmers in the
 development team?
 p It is sometimes argued that agile methods require higher skill
 levels than plan-based approaches in which programmers simply
 translate a detailed design into code.
£ How is the development team organized?
 p Design documents may be required if the team is dsitributed.
£ What support technologies are available?
 p IDE support for visualisation and program analysis is essential if
 design documentation is not available.
 58
 Organizational issues
£ Traditional engineering organizations have a culture of
 plan-based development, as this is the norm in
 engineering.
£ Is it standard organizational practice to develop a detailed
 system specification?
£ Will customer representatives be available to provide
 feedback of system increments?
£ Can informal agile development fit into the organizational
 culture of detailed documentation?
 59
 Agile methods for large systems
£ Large systems are usually collections of separate,
 communicating systems, where separate teams develop each
 system.
 p Frequently, these teams are working in different places, sometimes in
 different time zones.
£ Large systems are ‘brownfield systems’, that is they include and
 interact with a number of existing systems.
 p Many of the system requirements are concerned with this interaction and
 so don’t really lend themselves to flexibility and incremental development.
£ Where several systems are integrated to create a system, a
 significant fraction of the development is concerned with system
 configuration rather than original code development.
 60
 Large system development
£ Large systems and their development processes are often
 constrained by external rules and regulations limiting the
 way that they can be developed.
£ Large systems have a long procurement and development
 time. It is difficult to maintain coherent teams who know
 about the system over that period as, inevitably, people
 move on to other jobs and projects.
£ Large systems usually have a diverse set of stakeholders.
 It is practically impossible to involve all of these different
 stakeholders in the development process.
 61
 Factors in large systems
 Brownfield
 System of development Diverse
 systems stakeholders
 Large software system
 Prolonged Regulatory
procurement System constraints
 configuration
 62
 IBM’s agility at scale model
 Core agile development Disciplined agile delivery
 Value-driven life-cycle Risk+value driven lifecycle
 Self-organizing teams Self-organizing with appropriate
 Focus on construction governance framework
 Full delivery life-cycle
 Agility at
 scale
 Agility at scale Disciplined 
Disciplined agile delivery where agile delivery
 scaling factors apply:
 Large team size
 Geographic distribution
 Core agile 
 Regulatory compliance
 development
 Domain complexity
 Organization distribution
 Technical complexity
 Organizational complexity
 Enterprise discipline
 63
 Scaling up to large systems
£ A completely incremental approach to requirements
 engineering is impossible.
£ There cannot be a single product owner or customer
 representative.
£ For large systems development, 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 is practically impossible. However, it is
 essential to maintain frequent system builds and regular
 releases of the system.
 64
 Multi-team Scrum
£ Role replication
 p Each team has a Product Owner for their work component and
 ScrumMaster.
£ Product architects
 p Each team chooses a product architect and these architects
 collaborate to design and evolve the overall system architecture.
£ Release alignment
 p The dates of product releases from each team are aligned so that
 a demonstrable and complete system is produced.
£ Scrum of Scrums
 p There is a daily Scrum of Scrums where representatives from
 each team meet to discuss progressand plan work to be done.
 65
 Agile methods across organizations
£ Project managers who do not have experience of agile methods may
 be reluctant to accept the risk of a new approach.
£ Large organizations often have quality procedures and standards
 that all projects are expected to follow and, because of their
 bureaucratic nature, these are likely to be incompatible with agile
 methods.
£ Agile methods seem to work best when team members have a
 relatively high skill level. However, within large organizations, there
 are likely to be a wide range of skills and abilities.
£ There may be cultural resistance to agile methods, especially in
 those organizations that have a long history of using conventional
 systems engineering processes.
 66
Questions?
 67