CPT203 W3
This week we will focus on two topics:
- Scrum Framework
- Agile Methods - Background
Scrum Framework
Scrum isn’t a standard process.
Scrum is a framework for organizing and managing work.
Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。
The Scrum values, principles, and practices would be the key structural components. You can customize inside the structure of Scrum, adding fixtures and features until you have a process that works for you. Scrum is a simple, people-centric framework based on the values of honesty, openness, courage, respect, focus, trust, empowerment, and collaboration. The Scrum practices themselves are embodied in specific roles, activities, artifacts, and their associated rules.
Scrum Roles
Scrum development efforts consist of one or more Scrum teams. Each made up of three Scrum roles: product owner, ScrumMaster and the development team.
- The product owner is responsible for what will be developed and in what order. 产品负责人负责开发什么以及以什么顺序开发。
- The Scrum Master is responsible for guiding the team in creating and following its own process based on the broader Scrum framework. Scrum Master负责指导团队基于更广泛的Scrum框架创建并遵循自己的流程。
- The development team is responsible for determining how to deliver what the product owner has asked for. 开发团队负责确定如何交付产品所有者所要求的内容。
Product Owner
The single authority responsible for deciding which features and functionality to build and the order in which to build them. The product owner maintains and communicates to all other participants a clear vision of what the Scrum team is trying to achieve. The product owner is responsible for the overall success of the solution being developed or maintained.
负责决定构建哪些特性和功能以及构建它们的顺序的单一权威。产品负责人维护Scrum团队想要实现的目标，并与其他所有参与者进行沟通。产品负责人负责开发或维护的解决方案的整体成功。
说到底Product Owner就是老板，只负责提供所有的要求和开发顺序。 不完全是老板，他需要和老板沟通。基于增量开发。
- To make sure that the most valuable work is always performed. 确保最有价值的工作总是被完成
- The product owner actively collaborates with the ScrumMaster and development team. 产品负责人积极与ScrumMaster和开发团队合作
- Must be available to answer questions soon after they are posed. 必须能在问题被提出后马上回答
ScrumMaster
Helps everyone involved understand and embrace the Scrum values, principles, and practices. Acts as a coach, providing process leadership and helping the Scrum team and the rest of the organization develop their own high performance, organization-specific Scrum approach. The ScrumMaster helps the organization through the challenging change management process that can occur during a Scrum adoption.
帮助参与的每个人理解并接受Scrum价值观、原则和实践。作为教练，提供过程领导，帮助Scrum团队和组织的其他成员开发他们自己的高效的、针对组织的Scrum方法。ScrumMaster帮助组织完成在采用Scrum过程中可能发生的具有挑战性的变更管理过程。
ScrumMaster有工头那味了
- As a facilitator, the ScrumMaster helps the team resolve issues and make improvements to its use of Scrum. 作为一个推动者，ScrumMaster帮助团队解决问题并改进Scrum的使用。
- Also responsible for protecting the team from outside interference and takes a leadership role in removing impediments that inhibit team productivity. 还负责保护团队不受外界干扰，并在消除阻碍团队生产力的障碍方面发挥领导作用。
- The ScrumMaster has no authority to exert control over the team, so this role is not the same as the traditional role of project manager or development manager. ScrumMaster没有权力对团队施加控制，所以这个角色与传统的项目经理或开发经理的角色不同。
- The ScrumMaster functions as a leader, not a manager. ScrumMaster是一个领导者，而不是管理者。
Development Team
- Scrum defines the role of a development team, which is simply a diverse, cross-functional collection of people who are responsible for designing, building, and testing the desired product.
- The development team self-organizes to determine the best way to accomplish the goal set out by the product owner.
- The development team is typically five to nine people in size.
- Its members must collectively have all of the skills needed to produce good quality, working software.
- For development efforts that require much larger team size, team members can be organized into several teams with each team nine or fewer team members.
Scrum定义了开发团队的角色，开发团队是一个多元化的、跨职能的团队，负责设计、构建和测试所需的产品。开发团队自组织以确定实现产品所有者设定的目标的最佳方法。开发团队的规模通常是5到9人。它的成员必须集体拥有生产高质量、可工作的软件所需的所有技能。对于需要更大团队规模的开发工作，可以将团队成员组织成几个团队，每个团队有9个或更少的团队成员。
Development Team低端码农了属于是
Scrum Activities and Artifacts
基于增量开发，整个大圈就是一个scrum
Forecast? Commitment?
It is a forecast because the estimate might change as more information becomes known during the course of the sprint. Some also believe that a commitment on the part of the team will cause the team to sacrifice quality to meet the commitment. Or will cause the team to “under-commit” to guarantee that the commitment is met.
它是一种预测，因为在sprint过程中，随着更多的信息被了解，估计可能会发生变化。有些人还认为，团队的承诺将导致团队牺牲质量来满足承诺。或者会导致团队“承诺不足”，以保证承诺得到满足。
Using the forecast to derive a commitment. Commitments support mutual trust between the product owner and the development team as well as among the development team. Commitments support reasonable short-term planning and decision making within an organization. When performing multiteam product development, commitments support synchronized planning.
利用预测得出一个承诺。承诺支持产品所有者和开发团队之间以及开发团队之间的相互信任。承诺支持组织内合理的短期计划和决策。当执行多团队产品开发时，承诺支持同步计划。
Product Backlog 产品待办事项列表
The product owner, with input from the rest of the Scrum team and stakeholders, is ultimately respnsible for determining and managing the sequence of works (product backlog items) and communicating it in the form of a prioritized (or ordered) list known as the product backlog.
产品负责人根据Scrum团队其他成员和涉众的意见，最终负责确定和管理产品待定项的顺序，并以优先级列表的形式(即产品待定项列表)进行沟通。
- High-value items appear at the top of the product backlog and the lower-value items appear toward the bottom.
- The product backlog is constantly evolving artifact. Items can be added, deleted, and revised by the product owner as business conditions change, or as the Scrum team’s understanding of the product grows.
- In pratice, many teams use a relative size measure such as story points or ideal days to express the item size.
PBI Example
- User Story: online user registration
- Description: as a user, I want to be able to register online, so that I can perform online shopping.
- Acceptance Criteria:
- User can register only if the user fills in all required fields
- The email used in the registration must not be a free email
- User will receive a notification email after successful registration
Product Backlog Grooming 梳理产品待办事项列表
The activity of creating and refining product backlog items, estimating them, and priortizing them is known as grooming. 创建和细化产品待办事项列表项、评估它们并对它们进行优先级排序的活动称为梳理。
优先级从Feature A–>Feature C逐渐降低。
Sprint 冲刺
In Scrum, work is performed in iterations or cycles of up to a calendar month called sprints. 每个sprint的周期时间都是相同的。
The work completed in each sprint should create something of tangible value to the customer or user. Sprints are timeboxed so they always have a fixed start and end date, and generally they should all be of the same duration. A new sprint immediately follows the completion of the previous sprint.
在每个“冲刺”中完成的工作应该为客户或用户创造一些有形的价值。sprint是有时间框的，所以它们总是有一个固定的开始和结束日期，通常它们都应该具有相同的持续时间。在前一个冲刺完成之后，马上会有一个新的冲刺。
- 召开Sprint Plan Meeting，确定这个Sprint的目标、演示日期、要完成的Backlog、Backlog的优先级等；
- 进入冲刺开发周期，在这个周期内，每天要召开Daily Stand-up Meeting；
- 整个冲刺周期结束，召开Sprint Review Meeting，将成果演示给Product Owner；
- 团队成员最后召开Sprint Retrospective Meeting，总结问题和经验.
Sprint Planning
A product backlog may represent many weeks or months of work. To complete all the items in the product backlog, a series of sprints are to be carried out. To determine the most important subset of product backlog items to build in the next sprint, the product owner, development team, and ScrumMaster perform sprint planning.
一个产品待办事项列表可能代表数周或数月的工作。为了完成产品待办事项列表中的所有项目，需要进行一系列的“冲刺”。为了确定下一个sprint中要构建的产品待定项的最重要子集，产品所有者、开发团队和ScrumMaster执行sprint计划。
During sprint planning, the product owner and development team agree on a sprint goal that defines what the upcoming sprint is supposed to achieve. Based on the sprint goal, the development team reviews the product backlog and determines the high priority items that the team can realistically accomplish in the upcoming sprint while working at a sustainable pace.
在“冲刺”计划中，产品负责人和开发团队就“冲刺”目标达成一致，该目标定义了即将到来的“冲刺”应该实现什么。基于“冲刺”目标，开发团队审查产品待办事项列表，并确定在即将到来的“冲刺”中团队可以实际完成的高优先级项目，同时以“可持续的速度”工作。
Many development teams break down each targeted feature into a set of tasks. The collection of these tasks, along with their associated product backlog items, forms a second backlog called the sprint backlog.
The team provides an estimate (typically in hours) of the effort required to complete each task.
总的来说，选择一个产品待办事项列表项(最重要项)，将该项分解为任务，并确定所选的项是否合理地适合sprint(与同一sprint的其他目标项相结合)。如果它确实适合，并且有更多的能力来完成工作，那么重复这个循环，直到团队没有能力做更多的工作。
Sprint Execution
Once the Scrum team finishes sprint planning and agrees on the content of the next sprint, the development team performs all of the task-level work necessary to get the features done. 一旦Scrum团队完成了“冲刺”计划，并就下一个“冲刺”的内容达成一致，开发团队就会执行完成特性所需的所有任务级工作。
“done” means there is a high degree of confidence that all of the work necessary for producing good-quality features has been completed. “完成”意味着有高度的信心，生产高质量功能所需的所有工作已经完成。
Team members define their own task-level work and then self organize in any manner they feel is best for achieving the sprint goal. 团队成员定义他们自己的任务级工作，然后以他们认为最适合实现sprint目标的方式进行自我组织。
Daily Scrum
Not a problem-solving activity. Talk about problems after the daily scrum and do so with a small group of interested member. Not a traditional status meeting. Communicate the status of sprint backlog items among the development team members. It is an inspection, synchronization, and adaptive daily planning activity that helps a self-organizing team do its job better. 在日常的scrum之后和一小群感兴趣的成员讨论问题。不是传统的地位会议。在开发团队成员之间沟通sprint待定项的状态。它是一种检查、同步和自适应的日常计划活动，帮助自组织团队更好地完成工作。
Definition of Done
Sprint results as a potentially shippable product increment, meaning that whatever the Scrum team agreed to do is really done according to its agreed upon definition of done. This definition specifies the degree of confidence that the work completed is of good quality and is potentially shippalbe. A bare-minimum definition of done should yield a complete slice of product functionally that is designed, built, integrated, tested and documented. Sprint的结果是一个潜在的可交付产品增量。“完成”的最小定义应该产生设计、构建、集成、测试和文档化的产品功能的完整部分。
“pontentially shippable” does not mean that what got built must actually be shipped. 潜在的交付并不代表项目必须交付，交付的决定属于商业决定(business decision)会因此各种决定而改变。例如:
- Do we have enough features or enough of a customer workflow to justify a customer deployment? 我们是否有足够的特性或足够的客户工作流来证明客户部署的合理性?
- Can our customers absorb another change given that we just gave them a release two weeks ago? 我们两周前刚刚发布了一个版本，我们的客户能接受另一个变化吗?
Sprint Review
At the end of sprint there are two additional inspect-and-adapt activities, sprint review (sprint评审) and sprint retrospective (sprint回顾). Sprint review is to inspect and adapt the product that is being built. Sprint评审是检查和调整正在构建的产品。 演示，获得feedback。
Critical to this activity is the conversation that takes place among its participants, which include the Scrum team, stakeholders, sponsors, customers and interested members of other teams. Focused on reviewing the just-completed features in the context of the overall development effort. Everyone in attendance gets clear visibility into what is occurring and has an opportunity to help guide the forthcoming development to ensure that the most business-appropriate solution is created.
这个活动的关键是参与者之间的对话，参与者包括Scrum团队、利益相关者、赞助者、客户和其他团队感兴趣的成员。着重于在整个开发工作的上下文中回顾刚刚完成的特性。参加会议的每个人都能清楚地了解正在发生的事情，并有机会帮助指导即将进行的开发，以确保创建最适合业务的解决方案。
Sprint Retrospective
This is the second inspect-and-adapt activity at the end of the sprint. 第二个总结活动在sprint结束时。
Frequently occurs after the sprint review and before the next sprint planning. 经常发生在“冲刺”评审之后和下一个“冲刺”计划之前。
Sprint retrospective is an opportunity to inspect and adapt the process. Sprint回顾是一个检查和调整过程的机会。
The development team, ScrumMaster, and product owner discuss what is and is not working with Scrum and associated technical practices. 开发团队、ScrumMaster和产品负责人讨论什么是Scrum，什么不是Scrum，以及相关的技术实践。
The focus is on the continuous process improvement. 重点是持续的过程改进。
At the end of a sprint retrospective the Scrum team should have identified and committed to a practical number of process improvement actions. 在sprint回顾的最后，Scrum团队应该确定并承诺一些实际的过程改进行动。
Sprint Review和Sprint Retrospective都是在每一个sprint结束后发生的，他俩应该是紧挨在一起进行的，只是会议的内容和参会人员有所不同。每天的任务结束一直会进行的是daily scrum。
Agile Methods 敏捷方法
- Agile methods
- Plan-driven and agile development
其实这部分和Scrum Framework的位置我放反了，但是就先这么看着吧。
Background
大公司需要产品的时候，愿意权衡软件质量和需求，以更快地部署他们需要的软件。因为不可能推导出一套完整的稳定的软件需求。最初的需求不可避免地会发生变化。最后为了尽快交付系统，让用户获得经验，发现更清晰的真实需求由于外部因素，需求可能会迅速和不可预测地变化。
Content
- Some of the agile methods
- Extreme programming (Beck, 1999; Beck, 2000)
- Scrum (Cohn, 2009; Schwaber, 2004; Schwaber and Beedle, 2001)
- Crystal (Cockburn, 2001; Cockburn, 2004)
- Adaptive Software Development (Highsmith, 2000)
- DSDM (Stapleton, 1997; Stapleton, 2003)
- Feature Driven Development (Palmer and Felsing, 2002)
- These agile methods are all based around the notion of incremental development and delivery with different processes 这些敏捷方法都是基于增量开发和不同过程交付的概念
- However, they share a set of principles, based on the agile manifesto, and so have much in common. 基于敏捷宣言共享了一套原则，因此有很多共同点。
The software is not developed as a single unit but as a series of increments, with each increment including new system functionality.
Fundamental characteristics: scrum是基于敏捷开发
- The processes are interleaved.
- Minimum documentation 文件减到最小 只有需求文档，剩下的文档用可读易懂的代码代替
- Developed in a series of versions, or increments, with system stakeholders involvement.
- System user interfaces are often developed using an interactive development system that allows the interface design to be quickly created
The philosophy behind agile methods is reflected in the agile manifesto that was agreed on by many of the leading developers of these methods.
- Individuals and interactions over processes and tools 个人和互动高于过程和工具
- Working software over comprehensive documentation 工作软件胜过全面的文档
- Customer collaboration over contract negotiation 客户合作高于合同谈判
- Responding to change over following a plan 响应计划的变更
Most software projects include practices from plan-driven and agile approaches. 大多数软件项目包括来自计划驱动和敏捷方法的实践。
Tutorial
Explain why the rapid delivery and deployment of new systems is often more important to businesses than the detailed functionality of these systems. 为什么快速交付和部署新系统往往比这些系统的详细功能更重要
A: A conventional waterfall or specification-based process is usually prolonged and the final software is delivered to the customer long after it was originally specified. In a fast-moving business environment, this can cause real problems. By the time the software is available for use, the original requirements may have changed so radically that the software is effectively useless. Therefore, for business systems in particular, development processes that focus on rapid software development and delivery are essential. 传统的瀑布式或基于规格说明的过程通常会延长，最终的软件在最初指定之后很长时间才交付给客户。在快速变化的商业环境中，这可能会导致真正的问题。当软件可以使用时，原始的需求可能已经发生了根本的变化，以至于软件实际上是无用的。因此，特别是对于业务系统，专注于快速软件开发和交付的开发过程是必不可少的。Explain how the principles underlying agile methods lead to the accelerated development and deployment of software. 敏捷开发的原则
- Individual and interactions over processes and tools. 流程和工具之上的个人和交互
- Working software over comprehensive documentation. 工作软件胜过全面的文档
- Customer collaboration over contract negotiation. 客户合作高于合同谈判
- Responding to change over following a plan. 响应计划的变更
- When would you recommend against the use of an agile method for developing a software system? 什么时候你会建议不要使用敏捷方法来开发软件系统
- Agile methods should probably not be used when the software is being developed by teams who are not co-located. If any of the individual teams use agile methods, it is very difficult to coordinate their work with other teams. Furthermore, the informal communication which is an essential part of agile methods is practically impossible to maintain unless they are being supported by collaboration tools such as online meeting. 当软件由不在同一地点的团队开发时，可能不应该使用敏捷方法。如果任何一个团队使用敏捷方法，那么就很难与其他团队协调工作。此外，非正式交流是敏捷方法的重要组成部分，除非得到在线会议等协作工具的支持，否则实际上是不可能维护的。
- Agile methods should probably also be avoided for critical systems where the consequences of a specification error are serious. In those circumstances, a system specification that is available before development starts makes a detailed specification analysis possible. 对于规范错误后果严重的关键系统，可能也应该避免使用敏捷方法。在这些情况下，在开发开始之前可用的系统规范使详细的规范分析成为可能。
- However, some ideas from agile approaches such as test first development are certainly applicable to critical systems. 然而，敏捷方法中的一些想法，如测试优先开发，肯定适用于关键系统。
- To reduce costs and the environmental impact of commuting,your company decides to close a number of offices and to provide support for staff to work from home. However, the senior management who introduce the policy are unaware that software is developed using agile methods, which rely on close team working and pair programming. Discuss the difficulties that this new policy might cause and how you might get around these problems. 引入这一策略的高级管理人员并不知道软件是使用敏捷方法开发的，这种方法依赖紧密的团队合作和结对编程。讨论这个新政策可能导致的困难，以及如何解决这些问题。
A: When a company is driven by a close team and is divided they will be unable to have daily meetings, which can cause issues with communication, programming in pairs would not be possible, a communication gab would be created, productivity will slow down due to communication issues, and detecting errors would be quite difficult. These problems can be avoided by creating merging offices together so pair programming and daily communication can be established. If that is not possible, a communication platform consisting of webcams, desktop viewing software, and microphones should be created to allow better communication. 当一个公司是由亲密的团队,他们将无法日常会议,这可能会导致问题沟通、成对编程不可能,一个通信唠叨会被创建,生产力将减缓由于沟通问题,和检测错误是相当困难的。这些问题可以通过在一起创建合并办公室来避免，这样就可以建立结对编程和日常通信。如果这是不可能的，应该创建一个由网络摄像头、桌面查看软件和麦克风组成的通信平台，以便更好地进行通信。
References
- XJTLU slides CPT203 Week3
- 什么是敏捷开发之Scrum框架，如何入门？ - 项目管理进阶的回答 - 知乎
- Sprint Review vs Sprint Retrospective