敏捷宣言

Scrum

EPIC

User Story

1. 作为内容运营人员，可以在运营CRM设置搜索条件，查询到匹配条件的词汇列表

2. 作为内容运营人员，可以在运营CRM通过Excel导入新词汇

3. 作为用户，在C端产品点击词汇详情后，可以按照ID查询到词汇详细信息。

Task / Sub-Task

Story Points

Backlog

Sprint

其他

敏捷流程和技术质量

敏捷/scrum 是不是和设计技术方案相冲突？在流程中加入技术设计和技术评审，会不会导致不够敏捷？

1. 敏捷强调的是快速迭代和适应性，这并不意味着忽视了技术设计。相反，良好的技术设计是支持敏捷的关键因素。敏捷原则中有一条“坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强”。

2. 流程中加入技术设计和技术评审有助于确保设计质量，并且可以避免未来的返工。你有可能会觉得技术方案评审需要挺长时间甚至研发会等评审完再开始开发，而导致流程本身的不敏捷。关键在于将这些活动与敏捷流程融合，使其快速且高效。

3. 在敏捷流程中，如何在保证敏捷的基础上，加入技术评审，同时保障技术质量？两个关键节点，一是技术设计评审，二是code review
1. 技术评审：不是所有的需求都需要写技术设计文档，超过8分(3pd)的持续开发，需要写技术设计文档。
1. 如果8分(3pd)的开发，需要额外多3分来写技术设计文档和技术评审，是不是就得不偿失了？技术设计文档是为了讲明白我要怎么设计，而不是需要花很多时间去写一个详细的文档。8分的开发，如果多2分来写文档和拆解task，是合理的。甚至说，技术设计写完之后，开发效率理论上是提高的，总体时间可能还是8分。
2. 技术评审，按需直接文档评审，或者线下约会议室评审。
3. 技术评审不block开发进程。在做技术设计时，把握“至少两种方法”这一关键点，就可以保障技术设计大概率没有问题。
2. code review 是保障质量非常重要的一环
1. 对于没有技术方案评审的代码，需要通过code review来保障质量
2. 敏捷流程 强调代码的共享所有权(Collective Code Ownership)，代码属于整个团队，质量是所有人的共同责任。不能有的心态是“这块儿不是我开发的，我就不需要去关注了”。
3. 代码是共享的，就意味着，A提交的代码，其他人是很有可能以后会去改的。敏捷中是要求研发之间互相code review，除了保证设计质量，同时也会促进知识共享、增强协作，提高敏捷和灵活性。
4. Code Review，参考 一张图解Code review怎么做。一言总结：by design & by code

各个方向需求的重要紧急程度不同，需求大小不同，如何避免出现 有些人很忙，有些人很闲的情况？

1. 缩小协作单位，以用户故事为研发单位。用户故事帮助团队聚焦于最终用户的需求，使得开发过程更加目标明确。敏捷team通常在迭代开始时就确定一组用户故事，以此为基础进行开发工作。

2. 代码共享。在敏捷流程中，研发领走的是User Story，而不是Requirement/Epic，协作上依赖抽象不依赖实现。

3. 代码共享也不意味着哪里有砖搬哪里，而是在一个相对稳定的敏捷team中相互补位。理想中的状态是：每个人专注在自己的做的事情上，同时又对其他的需求有一定的了解。

互相改代码的情况下，如何保证代码整体质量 和 系统的架构演进？

1. 代码共享，也是俗称的“互相改代码”，一定程度上会导致owner意识问题(流程导致的而不是个人问题)

2. 重构。《重构：改善既有代码的设计》说的是，渐进式重构(小步前进、逐步改进、重构和新功能开发分离)，不是定期重构更不是重写。需求总是会变化的，代码语义也是需要变化的，如果每个人在看到历史代码的bad smell时，都fix smell，那质量就能得到保障

3. 定期的架构review和技术债务管理
1. 对于大的需求、新的theme需要走技术设计评审。
2. 定期review系统架构优化的必要性，特别是需求多 迭代快 issue多的系统。
3. 对于技术债务，遵循“识别和记录 → 评估影响和优先级排序 → 大债务立项偿还 & 小债务持续偿还”的流程。技术债务的分类记录 是改进的前置环节，只有先记录下来优化点，并真切地安排时间去做优化，才能偿还技术债务。没有计划到日程中的任务，就不可能得到执行。

如何做到“每个人专注在自己的做的事情上，同时又对其他的需求有一定的了解”？

1. 如果团队小，比如4-7人，大概率大家是一起协作来完成一个需求。这种情况下，需求评审一起参与即可。

2. 如果团队大了，比如超过8人，可能需要拆分成多个敏捷team。在拆分敏捷team的情况下，可能的方法：
1. 同一个scrum team，需求评审一起参与。不同scrum team定期组织分享，需求问答和技术讨论会
2. 用好需求管理工具，比如Jira board,所有的需求、研发进展都在上面可见，保证信息的易得性
3. 鼓励自主了解。每个prd都会提前发出来，供所有人查阅。鼓励团队成员主动查阅文档和会议记录，并在有疑问时主动寻求答案
4. 团队知识库建设。文档分门别类，分类整理，所有需求、技术设计、分享等资料 都放在团队知识库中，方便查阅和索引

在研发流程中，有新的任务/bug fix等任务插入 怎么办

1. Scrum工作流，有固定的迭代周期，强调了每个sprint交付一个可增量的、可交付的产品。在sprint的规划中，默认需要预留足够的时间，来应对插入任务/bug fix等。如果你本周onCall，就需要多预留时间，否则一般预留20%时间不排。

2. Scrum更适合于大型项目，按周/两周 规划拆解里程碑sprint，更保障承诺和交付。Kanban更适合于中小型需求和迭代，Kanban更强调弹性，可以灵活添加和改变任务。

3. 不论什么研发流程，周计划都需要预留20%的时间 来应对突发事件/会议等。

敏捷开发是不是等于Scrum？

1. 不是的。Scrum只是敏捷落地的框架之一，除此之外还有Kanban、极限编程、精益等等思想和框架。所有的框架和流程都是为了实现落地敏捷宣言。

2. 按照我的经验，敏捷落地过程中，不要限制自己只使用scrum和sprint，特别是当团队大了之后，一个scrum board是不能解决所有问题的，可能需要拆分敏捷team，有的team适合scrum、有的适合kanban，同一团队的不同阶段甚至同一阶段的不同Epic都可以选择使用不同的工具和流程。如果你只有4-7个人，使用同一个scrum或者kanban board是比较合适的。如果人更多，可能需要拆敏捷team。可以只用Scrum board或者Kanban board，也可以都用，甚至可以使用文档来管理story和task，取决于团队自己的文化、协作方式、自驱力自主性等。我的经验，Scrum因为有sprint这种承诺的阶段性交付，可能敏捷性不如kanban，但是交付的承诺性会更好。

怎么在团队中成功落地敏捷文化？

1. 需要整个团队一致努力，达成小规模、快速向用户交付价值的思维理念。统一认知，用好工具(推荐jira)，积极主动，小步快跑，持续优化。

2. 以好处换动机。研发同学大部分是不太乐意去在jira上拆解一个又一个的task，然后还要按照流程和规则去拖动的。但是如果通过拆解和敏捷流程，能够让大家更好的协作、更少的加班、更有成就感，这件事就会更容易落地。亦或者，用board上的task状态，来换取每天晨会的无聊陈述，可能研发也会更乐意。B=MAP，只有可以简单做到的、快乐的、可以得到正向激励的群体行为 才能顺利执行下去。

3. 工具和流程 重要 也不重要。无论是Scrum还是Kanban或者其他框架，都是为了落地敏捷理念，切不能因为流程和工具本身而导致不敏捷，一切的基准都是敏捷宣言。