敏捷软件开发---Agile Software Development

overview

• 瀑布模型-开发软件的旧方法（The Waterfall Model — old way of developing software）
• 敏捷软件开发（Agile Software Development）
• 精益软件开发-支持敏捷软件开发的概念框架（Lean Software Development — a conceptual framework that support
  agile software development）

瀑布模型（The Waterfall Model）

Each step had to be completed before the next step started.
每个步骤都必须在下一步开始之前完成。
Each step produced a lot of documentation(to record all decisions made).
每个步骤都产生了大量的文档（记录所做的所有决定）。

瀑布模型问题

• Difficult to keep all documentation consistent & up to date
• Unrealistic to think that all decisions made at the start of the projects are correct - issues became apparent after they were worked on（认为在项目开始时所做的所有决定都是正确的是不现实的，这些问题在工作之后就变得明显了）
• Customer did not see the profit for a couple of years - and they realised that this is not what
  they actually want
• Projects took several years to finish

敏捷软件开发（Agile Software Development）

A new approach was needed that was:

• Quicker
• Easier to change as the project progressed
• Allowed effective monitoring of progress

精益软件开发的7个原则（7 Principles of Lean Software Development）

• Eliminate Waste
• Amplify Learning（加强学习）
• Decide Late
• Deliver Fast
• Empower the Team
• Build Integrity in
• See the Whole

Eliminate Waste

Waste is non-value-adding（非增值） work. Some examples of waste are:
software defects（软件缺陷）
excess documentation
hand-offs: transfer of software projects from one team to another extra features (e.g., “Air Gesture” feature of Samsung Galaxy S4)
throw away code experiments (some look like waste but they are not)
消除浪费是一个迭代过程

Amplify Learning（加强学习）

• Software development is a continuous learning process.
• Agile processes make sure that everyone shares in the learning process.
• Short iterations with reviews provide opportunities for reflection and learning.（每次迭代完都进行回顾）
• Developing prototypes（开发原型） and showing them to the customer early makes it easier to learn what is really required.

Decide Late

• Keep all options open by putting off decisions as late as possible
• This can be difficult to get right.
  • It is easy to never make a decision!
  • The iterative approach means that some decisions have to be made at the
  start of each iteration.
• Hence, plan meetings to consider all the different options

Deliver Fast

• Short iterations produce usable（能用的）code quickly.
  • It can be difficult to maintain quality as well.
• Use set-based design to explore several different options in parallel（平行的）.
  使用基于集合的设计并行探索几个不同的选项。
  • Several teams design solutions on the same requirements and the best one is chosen.
  • This may seem like waste as costs might be high.
  • However, not necessarily a waste since the benefits of finding the best
  solution can be high
• Beware（当心，堤防） that waste occurs when costs are high and benefits are low.

Team Empowerment（团队授权）

• The role of the manager is not to tell people how to do their jobs.
• The managers must help novices（新手） improve their skills.
• Self-organising teams: The teams should be able to organise themselves without the manager telling them what to do.
• Company procedures should reflect that employees are “individuals,” not interchangeable resources.

In-built Integrity

• Architectural integrity: The design is simple and complete at all times
• Conceptual integrity: All parts of the system fit well (i.e., not made of separate parts glued（胶合的） together).
• Small iterations so that requirements are refined together.
• Regular refactoring of the source code.
• Product integrity through testing.
• Perceived integrity: It is not enough to be good, we must also be seen good.

Code Refactoring
• The process of restructuring code to improve its internal structure and non-functional features (e.g., maintainability（可维护性）, performance, security).
• Code refactoring aims to make the code clean, neat, more efficient and maintainable.

User Stories

Overview

What a user story is
User roles, user proxies, non-user roles
Epics, constraints, backlogs
Cost estimation
Scheduling stories

What is a User Story?

• Most modern software development approaches, including agile（敏捷） are based on customer requirements.
• However, it is hard to get customers to say what they want in precise terms.
• Therefore, user interactions with the software system are broken down into small user actions, which we call user stories.
• Each user story does one thing, making it easy for the users to describe each part of the interaction separately.

• In agile, is a short, informal, plain（平原） language description of what a user wants to do within a software product to gain something they find valuable.
• User stories typically follow the “user role—feature—benefit” pattern:
• As a [description of user]
• I want to [functionality]
• so that [a benefit/value].

Guidance for Good User Stories

• A user story should be closed. At the end of a user story a meaningful goal should be accomplished.
• A user story should describe one interaction.
• Keep User Interface (UI) out of code.
• Typically, the user interface involves several user stories.
• Use a series of mockups (e.g., wireframes to design UIs).

Features of Good User Stories

• Independent of other stories to avoid confusion.
• Negotiable（面议）, a reminder to talk later.
• Valuable to users or customers but not developers.
• Estimable.
• Small but not too small
• A matter of judgement and experience.
• The right size to be able to make good estimates.
• Testable.
• If a story can’t be tested, how do we know when it is finished?
INVEST criteria for Good User Stories

User Roles

• The main purpose of a user role is to generate user stories.
• Many different users can have the same role, and so are treated the same.
• Example: an administrator.
• One user can have different roles.
• Example: administrator and customer relations manager.

• Each user role is recorded on an index card or its modern electronic equivalent.
• The name of the user role
• Frequency of use
• Domain expertise
• Computer expertise
• Software expertise
• Goals

Personas（人物角色）

• Inventing a single person, or several persons, to represent a user role.
• They are given names, dates of birth etc.
• Often makes it easier to guess some details when implementing a user story using role modelling.
• Extreme personas can also be interesting.
• Boundary cases are useful for testing and can reveal rare bugs.
• Example: A user who wants to break the software system.

Non-user Roles

• Sometimes it is useful to have non-human system role
• If another computer system will interact with our system.

Non-user Roles: Spikes（尖峰）

• It can be useful to have internal stories.
• Developers generate spikes.
• A spike is a story for gathering information (e.g., how much work will be required to work around a software issue?)
• Development team conducts a small experiment (e.g., a prototype) that is not part of the actual development but makes future development easier.

Epics

• An epic is a large user story with little detail.
• One aim of generating epics is to avoid making all analysis and design decisions at the start of the software development project
• Further study is needed to split an epic into more manageable stories.
• Some epics are compound:
• They are easy to split into smaller self-contained parts.
• Others are intrinsically（本质上） complex, hence splitting them into small pieces is not obvious.

Backlogs

• The collection of all stories, including user stories, epics, is called the project backlog（积压）.
• Originally all cards are pinned to a board in the development team office.
• Software tools can also be used, but having a board in the office can be useful.

Iteration Backlog

• Stories that have been assigned to an iteration form the iteration backlog.
• Cards on the board (physical or electronic) are either in an iteration or have yet to be assigned to an iteration.
• Completed stories are usually discarded at the end of the project.

Story Priorities

There are usually 4 levels, called MoSCoW.
• Must have. Not every story can be a must have!
• Should have. Include unless things go bad.
• Could have. Include if things go well.
• Would like to have. Ideas for a future release

Scrum

Scrum - Introduction

• Scrum is a framework for the management of iterative and incremental（增量） product development.
• Scrum was applied to software projects in the early 1990s.
• Scrum is one of the most popular ways to implement Agile Software Development.
• The Scrum approach is to divide the project into smaller logical chunks（大块） and execute those chunks in short iterations of ideally 1-4 weeks, which we call sprints（短跑冲刺） (i.e., iterations).

Sprints (Iterations)

• A sprint (i.e., iteration) is between 1- 4 weeks, typically 2 weeks.
• Sprints are time-boxed (i.e., must end on time).
• If a story can’t be finished it is returned to the product backlog.
• Problems that can’t be fixed during a sprint generate stories to be added to the product backlog.
• An entire sprint can be dedicated（专用） to fixing problems

The Scrum Team

1.Product Owner: responsible for the business value of the product(customer). Selects what gets done and when.
2.Scrum Master: ensures the team is motivated and productive.
• Removes obstacles.
• Ensures proper processes are followed
3.The Scrum Team: Between 3 and 9 people in total, including product owner and scrum master.
• Developers and Testers.
• User Experience analyst, if appropriate.
4.The Scrum Master
• Not a team leader! The team is self-organising!
• Works with the Product Owner
• Helps them define the product backlog(stories).
• Translates the customers’ and stakeholders’ language into words the team will understand.
• Works with the team members
• Facilitates the events
• Coaching and teaching.
• Removing impediments.
• Works with the rest of the organisation.
• Liases with other scrum masters.

The Scrum Meetings

Sprint (Iteration) Planning

• Sprint (iteration) planning at the start:
• The team and Product Owner agree on what to do in the sprint.
• The meeting is time-boxed for 4 hours(for a 2 week sprint).
• The stories to be included are chosen.
• The product owner then leaves and the work is divided up.

Daily Scrum

• Team stand up meeting at the start of each day.
• Time-boxed at 15 minutes. Only the team members speak.
• What did you do yesterday
• What will you do today.
• Are there any impediments standing in your way. The scrum master will try and remove them.

Sprint Review

• Sprint review is at end of the sprint.
• Time-boxed to 2 hours (for 2 week sprint)
• Product owner identifies what has been done.
• Team discuss what went well, what not so well.
• Team demonstrate the work they have done.
• Product owner discusses the remaining product backlog and likely completion date.
• Discussion on what to do for the next sprint.

Sprint Retrospective（回顾性）

• Sprint Retrospective: Look for possible improvements.
• Time-boxed to 1.5 hours ( for 2 week sprint)
• How the sprint went: people,relationships, processes and tools.
• What went well.
• Develop a plan to implement improvements.

Iteration Plan

• An iteration will consist of small number of user stories.
• The team discusses the stories in priority order.
• The customer (product owner) must be there to answer questions.

Planning an Iteration

• Each user story is split into individual tasks.
• The developers pick the tasks that they want to work on.
• They estimate the time needed for each of their tasks.
• Usually in ideal hours.
1 story point = 1 ideal day = 8 ideal hours.

Iteration Length and Velocity（速度）

• All iterations (i.e., sprints) are the same length (e.g., 2 weeks).
• The iteration velocity will then be the expected number of story points
(i.e., ideal days) that can be completed in each iteration.
• Velocity is the same for all iterations.
Estimated Project Length = (Total # of SPs) / velocity（Total number of SPs for
all user stories）

Iteration Hit Rate

Iteration Hit Rate is the fraction of story points completed in each iteration.
• It is expressed as percentage.
Iteration Hit Rate = (# of SPs completed)/(# of planned SPs) x 100

Release Planning

• Not every iteration results in a new release.
• Each release will consist of a number of iterations.

• We might fix the release date in advance.
• This will give us a limit on the number of story points that can be achieved.
• We can then decide what goes into a release, based on this constraint（约束）.
• We might want a given functionality for the release.
• Decide which user stories are needed to achieve this functionality.
• Add up the story points and decide how many iterations are needed.
The high priority user stories will be in an early release.
• Make sure that each iteration has roughly the same number of story points.
• SPs on the user story cards may not add up to the iteration velocity

4 Principles of Kanban

• Visualise Workflow
• Limit Work In Progress (WIP)
• Focus on the Flow
• Continuous Improvement

Focus on the Flow

• There are metrics（度量） to measure progress:
• Work In Progress or Process (WIP)
• Queues
• Blockers
• Lead Time and Cycle Time
• Throughput

Kanban Metric: Work In Progress/Process (WIP)

• WIP refers to both Work In Progress and Work In Process.
• Work In Progress is the total amount of work that is still to be done.
• Work In Process Is the total amount of work that is currently being
worked on.

Kanban Metric: Throughput

Throughput is the average number of items processed in a given time unit.
• Items per week.
• In software development it is the average number of story points completed per iteration.

Kanban Summary

• Kanban is a general purpose approach with less structure that Scrum.
• Many project teams are using hybrid development models that are influenced by both Kanban and Scrum.
• Kanban is often adapted as a way of visualising progress of user stories in Scrum.
• A Kanban board with story cards pinned to the board.
• Kanban can be modelled using Trello, a web-based application/tool.

Use Cases

Use Cases - Introduction

• A use case is equivalent to a user story.
• We find the use cases by looking at the actor and seeing what activity they initiate.
• Use cases should be short, doing one thing well to prevent ambiguity
• An actor is equivalent to a user role.

Use Case Diagram

• All actors and use cases are combined in a use case diagram to give the big picture.

Defining the System Boundary

• Once we have an idea about what the system will do, we need to identify the system boundary.
• We discover the system boundary by describing the actors and use cases.
• If something is inside the system boundary then we have to create it (e.g., develop that functionality).
• If something is outside the system boundary then it is already there,then what we create will just have to interact with it.
• Objects outside the system are called actors.

Actors

Each actor needs a short description defining their role in the system.
Some Examples:
• Class director: A person who requires part-time teachers for his class.
• Recruiter: Finds people to do teaching
• Payer: Organises payment for teachers
• Trainer: Trains part-time teaching staff.
• Besides people, actors can be other pieces of software,hardware or databases.
Actors
• Several different people may all perform the same role, hence be represented by a single actor.
• There will usually be several class directors, one for each class.
• There will be a single “Class Director” actor in the use case diagram since all class directors
interface with our system in the same way.
• One person might take on different roles and hence be represented by several actors.

Active actors will generate the use cases.
• If the actor is a person, think of him or her sitting down at a computer and using the software.
Passive actors are actors that are actors that respond to activities.
• Passive actor is contacted by the use case and does not initiate any activity.

Non-Functional Requirements

• Use cases（用例） are functional requirements and define system functionality.
• Use cases are not a good way of defining non-functional
requirements (e.g., system security, performance).
• Non-functional requirements can apply to a single use case or
the whole system.