Agile/Scrum

Agile
Agile与其说是一系列软件开发的方法论，不如说是一种观念，一种思想。有很多流程框架用于敏捷文化。Scrum是其中最出名，应用最广的一种。但是不管是哪一种都仅仅是一种参考，并不是一个绝对的方法。要实现敏捷，最关键的依然是团队，而不是方法。只有方法跟团队完美结合才能真正将敏捷的效果发挥出来。所以没有一成不变的Scrum流程，流程应该根据团队成员配置，团队文化，在敏捷过程中不断改进，流程与团队互相磨合、改进，最后确定一个适合团队的敏捷迭代方式。
鉴于个人经验，资历，我没法在这里讨论正确的Scrum流程应该是怎么样，只是讨论什么是我觉得不对的方法。不断意识到错误，在错误中不停修正，震荡中趋向稳定，也是一种不错的方法。照着教科书照搬Scrum流程，都是对产品和团队不负责的行为。

1. 职责
   1） Project Owner。 PO是团队与外部的接口，与客户合作确定产品需求。负责拟定每一个Sprint需要交付的需求，向团队输出待办事项，并确定优先级。在Sprint中要确保待办事项及其进度对所有项目成员可见。PO还需要确定开发团队下一步做什么，delay什么来权衡范围、进度以确保有最好的产品交付。
   2）Scrum Master。SM是团队的教练，帮助团队遵守流程，协助PO创建维护待办事项列表。和开发团队一起发现并实施技术实践，为团队清除外部障碍。
   3）开发团队（“猪”）。项目具体实施者，负责对产品的增量实现。开发团队采用自组织的方式完成工作，对于项目而言，开发团队应该是全职的，具有完成每个产品增量所需的所有技能。开发团队成语与产品负责人共同预测在一个Sprint里面能完成的工作，并决定如何实现。
   在传统的计划式开发中，命令自顶向下，一级一级传达，每一层都有相应的责任人。为了明确责任，做任何事情前都需要详尽的文档，提供足够充分的理由，证据，一级级申请，批准，然后立项才能开始实施。创新和敏捷就在这个冗长的过程中被扼杀了。
   在Scrum中，所有的执行都是基于客户需求，每一个Sprint持续迭代，交互。开发成员直接作用于backlog，并承诺每个sprint都完成相应待办事项，目标明确，责任清晰。
   但是在实际实施过程，Manager引入Scrum，又对传统的方式依依不舍，管理层不想放权，不想向服务型管理转变就会是什么一种情况呢。PO依然用瀑布式方式管理，在Sprint过程中随意更改待办事项，打乱开发计划，最终导致开发效率低下。按照Scrum的方式对一个Sprint能完成的工作做plan，但是执行过程中，每一个实现方法都需要PO或者团队外的Manager审阅，批准，导致项目进展缓慢，临近期限，为了赶进度又不得不作出妥协，delay交互或提交一些低质量代码。最终导致Scrum流离于形式，相比于传统的计划是模式，又增加了更多的流程，会议。这种混杂模式更加的混乱，低效。
2. 文化
   团队成员应该有足够的自信，以“我能做到”的心态去迎接，支撑敏捷。敏捷中强调的更多的是实践，通过实践去发现问题，解决问题，论证问题。但是传统的方式中，由于流程的限制，责任的明确划分。没有人拍板，所有人都不敢做决定，总是强掉问题，但是少有主动提出解决问题。
   敏捷中，团队成员之间是相互信任的，相信别人能完成工作。所有团队成员的工作进度是透明的，但是完成方式并不需要每一个人都明了。所有团队成员都相信别人会在规定时间内用最好的方式完成并交付任务。团队成员也被赋予足够的信任和自由，可以自主的设计、解决问题，而不用得到实现许可。
   团队成员被赋予了足够的决定权可以独立完成自己的工作，又与团队其他成员相互紧密协助，共同解决完成相关的工作，确保不会因为自己的工作阻塞别人的工作。
   实际执行中，如果团队成员之间没有足够信任，往往会造成过多的干涉别人工作，剥夺别人开发工作中的自主权，导致别人进展缓慢，同时自己也因为精力分散，而效率低下。比如PO不信任团队，觉得只有自己参与其中才能把控产品质量，进度，但是其实对每一块的具体细节PO都是了解的最少的一个人，参与其中，只会占用开发成员过多的时间去帮助PO理解细节。同样，如果两个开发成员的工作相互依赖，一人怀疑另一个人的开发不能很好契合自己的部分，不是通过两个人很好的沟通，协商解决问题，而是以为自己能力更高一筹，直接指手画脚，干涉别人的工作，结果往往适得其反，久久不能达成一致，相互block。
3. 产品交付
   敏捷中产品以增量的形式的交付，每一个Sprint结束都向客户交付功能增加的产品。即使收集客户反馈，根据客户反馈信息，实时改变后面的产品开发策略，需求。敏捷中的变化应该是根据客户需求，调整产品功能，待办事项优先级。保证每一次都向客户交互拥有最重要增量的产品。
   传统开发模型中，产品在一个预定的期限完成几乎所有的功能后再交付给用户。交互后除进行bug修复外，基本不在进行大的改动。如果客户有其它的需求需要引入，则需要以release升级包的形式在原来产品基础上进行升级。甚至在原来产品基础上，进行大的重构，再经过一个漫长的开发周期后向客户交付升级换代的产品。
   敏捷中，需求的变化频率远高于传统开发模型。敏捷开发中，有些需求在开发的早期不明了，甚至根本不存在。所以在敏捷开发中，开发早期可能并不能确定一个能适用于整个项目生命周期的开发模型，架构。在开发过程中，需要实时的，快速的根据需求变化在不影响持续迭代进度的基础上对design进行改进。所以在敏捷中变化的是需求，随之而变的是适应需求变化的设计。
   传统开发模型中，由于在项目早期立项时就已经确定的项目的走向，目标。所以在项目立项是，架构，模型就已经确认。在执行过程中，更多的变化来自于PM的安排，PM可以指定每次release需要包含的feature，fix哪些bugs。甚至PM可以在一个release周期中，更改需要release的事项，只要确保项目能在最后的期限完成所有的预期就可以。
   在Scrum的执行过程中，如果PO／SM打着拥抱变化的旗号把传统开发模式的release方式带入了Scrum中，会是什么情况呢。就是可能在Sprint做到一半的时候，PO／SM出于某种不严谨的原因打断当前开发进程，把正开发的story挪出当前sprint，新加入一些其他待办事项，造成开发效率低下。
   当然在Scrum模型中，开发过程中完全有可能客户出现新的优先级更高需求，也有可能客户不在需要某个正在开发的需求。这样的话，就对PO／SM提出了更高的要求，要求PO／SM有更高的责任感，严格评估新的需求的优先级，确定只把特别重要的需求插入正在开发的待办事项中。PO／SM在开始筛选Sprint待办事项时，也确定只筛选backlog中最重要，优先级最高的事项。以确保尽可能少的影响开发中的待办事项，打乱开发进度。杜绝传统开发模式中权利在手，任我胡来的不负责任的方式。

Scrum中相关的角色：

1. 团队（负责把产品做出来，承担研发责任；其实所有的一切都是为了让团队更加高效的输出而存在的）

2. Scrum Master（整个团队的老保姆，大到会议的主持，需求的变更，Scrum流程的实践管理；小到团队的开发环境不舒适，成员的情绪问题，开发测试设备等杂七杂八的都由这位负责）

3. Product Owner（产品需求提出方，以Backlog的形式给出，并定义开发任务的优先级，与研发团队一起评估复杂度，对整个产品的业务成功与否承担责任即ROI）

4. 其他相关人员（QA，UIUX等）

Scrum中的一些术语：

1. Sprint（冲刺）就是团队的一个开发周期，就是常说的“迭代”

2. Product Backlog，PO梳理出的具有一定业务价值的工作任务，通常比较大，整个项目会被切分成许多Backlog并形成研发团队的原始工作任务池。它有一个非常重要的属性：优先级，这直接决定了哪些任务先做，哪些后做。

3. User Story（故事，我一直认为这个主流翻译非常low，但我也找不到比这个好的翻译了）与Backlog相比较，是团队从技术的角度对Backlog的一种细化与分解并确认需求细节可投入开发的产物。User Story详细定义了开发人员能够执行的需求细节，以及质量的标准，复杂度等信息。

4. Task 是比User Story粒度更小的任务，不是所有的User Story都要分解成Task，按照实际需求来处理。

5. Sprint Daily Standup Meeting 每日的工作会议，不是为了汇报任务，而是要清除昨天的开发过程中遇到的问题以及今天要做的任务中存在的问题。

6. Sprint Planning Meeting Sprint开始前的计划会议，决定下一个Sprint需要做的Backlog并进行分解形成User Story以及Task，形成可执行的任务

7. Sprint Retrospective Meeting每个Sprint结束后的会议用于总结上一个Sprint做的好的与不好的地方并给出改进调整措施。

8. Story Points由于开发工作分类不同（前端跟后端开发，Java与C++复杂度各不相同），造成同一个User Story的复杂度评估无法标准化（传统的做法是 人/日）这种评估方法不够客观。为了抽象出不同劳动的复杂度，方便评估任务复杂度，做好风险控制，使用point作为无差别的单位做任务复杂度评估。通常可以将 1point=1.5 人/日计算即可

9. Kanban就是一个可以写字的白板，用于在展会中管理当前Sprint的Backlog，User Story，Task的状态，进度等。大致如下图所示。
   

10. Burning Down Chart 燃烧曲线，用于管理任务的进度，工作的剩余量的一张图
    

11. Scrum软件，用于方便管理人员管理Backlog，User Story，Task等工具

Scrum的运作框架如下：

敏捷开发的路线：
Test-Driven Development，测试驱动型开发。
Continuous Integration，持续集成。
Refactoring，重构。
Pair-Programming，结对编程。
Stand up，站立会议。
Frequent Releases，小版本发布。
Minimal Documentation，较少的文档。
Collaborative Focus，以合作为中心，表现为代码共享。
Customer Engagement ，客户参与。
Automated Testing ，自动化测试。
Adaptive Planning，可调整计划。

很好的参考介绍：
https://blog.youkuaiyun.com/zhanghq009/article/details/79412537
https://blog.youkuaiyun.com/inny100_100/article/details/54633757