敏捷团队章程

以下是我所在的敏捷团队实行的团队章程，未完待续，如有错误和建议，欢迎指出~

1 前言

《敏捷实践》《DevOps》

1.1 什么是团队章程

        敏捷中有多种说法，如团队契约、Working Agreement、团队公约等，都是指团队章程。团队章程是提供指导原则、规则并指导团队成员行为的方针政策，也可以理解为团队开展工作的规则，可以包括预期的行为、价值观、工作规则和做事的方式。

1.2 谁制定团队章程

        团队章程应由团队成员共同制定，一致认可，并为所有成员服务。

1.3 为什么需要团队章程

• 最大程度地降低歧义、误解和误会，减少团队内部冲突；
• 提高速度，打造高效团队；
• 提升决策质量；
• 树立共同价值观；
• 提升团队成员的满意度；

1.4 团队章程的目标

        团队章程的目标是创建一个敏捷的环境，在这个环境中，团队成员可以发挥他们作为团队的最大动力。

2 团队章程

2.1 敏捷团队实践

2.1.1 敏捷仪式

        一个敏捷迭代为期两周，从第一周的周二到第三周的周一。每个迭代第一天下午（即每两周的周二下午）召开评审会、回顾会和计划会，主持人是团队成员轮流担当，主要负责同一迭代内所有会议的主持工作，包括预定会议室等；若团队内有远程办公成员，开会时应在会议室启用视讯或钉钉会议；

Daily Meeting

• 每天10点团队在会议室过一下禅道看板上各自的任务，若没有更新进度和工时，host在会后跟进；
• 时间不超过15分钟；
• 回答三个问题：昨天做了什么、今天计划做什么、遇到什么困难；

Review Meeting

• 每个迭代第一天下午的第一个会议；
• 迭代第二周周五，host负责将代码commit到main，merge description写明当次迭代完成的需求；
• 会前，Scrum Master更新语雀文档项目进度表中本次迭代和下次迭代，如YS8803_2023_Q1_Schedule；
• 会中，团队review项目进度表和里程碑；

Retrospective Meeting

• 每个迭代第一天下午的第二个会议；
• 使用钉钉表单收集功能回答三个问题：你觉得本次迭代哪里做的好（Well）、哪里做的不好（Less Well）、应该怎么解决（Action）；
• 会前，host将数据整理到语雀文档上；
• 会上，团队回顾上个迭代挑选的改进点的改进情况；
• 会上，团队进行review，做得好的鼓励继续保持，对发现的问题整理归类，记录在语雀文档，选出来不超过3条进行改进；
• 会后，host将最终采纳的意见在下个迭代用钉钉助手定时提醒；

Planning Meeting

• 每个迭代第一天下午的第三个会议；
• 会前，Scrum Master将迭代要完成的任务分解在Backlog，写明任务描述和DOD；（此流程后续优化，理论上应由团队成员分解。）
• 会后，大家根据进度和优先级将任务移动到当次迭代。（此流程后续优化，理论上PO应注明优先级）
• 故事点估算

工作进展共享

        项目组成员每天更新禅道日志，记录工时和进展；每周五或周一上午发周报，抄送给其他团队成员；

2.1.2 估算措施

2.1.3 完成的定义DoD

        在敏捷软件开发中，存在多级的不同的完成定义Definition of Done，以下分别说明。

Release DoD

• RD内测表
• 语雀版本记录：修改点、
• 版本评审表
• 版本发布申请表

User Story DoD

Feature DoD

1. 模块学习（如有必要，新增语雀文档，禅道任务下附上语雀文档链接和Git branch path）
2. 设计和输出方案文档（和第1点输出到同一个文档，EMB 研发设计文档模板）
3. 语雀方案文档review和修改
4. 代码实现
5. 测试通过：SIM test or Jupiter test
6. 单元测试编写，输出测试报告（测试报告包括且不限于单元测试用例、覆盖率，报告附在上述文档的末尾）
7. 代码格式化，提交merge到develop branch，通过代码评审，成功merge。

2.2 工程实践

        工程实践是指与代码紧密相关的偏技术类实践。常见的工程实践有：架构设计、需求分析、持续集成、TDD、ATDD、自动化测试、探索性测试、用户故事分析等等。

2.2.1 CI/CD实践

《YS8803 Validation》

2.2.2 代码评审

《代码评审》

2.2.3 文档评审

        在收到审核请求时，设计类文档审核响应的最长期限是一个工作日，其它类型的文档则最晚在本周的最后一天做出响应。Review人员至少3个，包括但不限于模块负责人、验证人员、项目负责人等。

2.2.4 编码指南

《EMB 固件编码规范》

2.2.5 技术债务管理实践

2.3 文化

2.3.1 团队价值观

Scrum五大价值观：承诺、 专注、 开放、 尊重、 勇气、成长

敏捷宣言四大价值观：

个体及互动胜于过程和工具

可用的软件胜于完整的文档：避免编写含可疑细节、易过时、不易维护的文档

客户合作胜于合同谈判

应对变更胜于遵循计划

2.3.2 协作和知识共享

• 营造学习型氛围，不定期团队分享。

表单收集分享主题，周五下午按实际情况召开分享会，在钉钉群Embedded FW Team直播，并记录在The Yuque document of the Share meeting。分享课题不限，如提高效率的工具或软件、debug经验、协议feature或最近阅读的书籍等等。

• 《统一术语》

2.3.3 持续改进

        勒布朗法则：later equals never，如果当时发现了一些问题，若能想到解决办法就尽早解决。

        童子军军规：让营地比你来时更干净。如果每次签入时，代码都比签出时干净， 那么代码就不会腐坏。清理并不一定要花多少功夫， 也许只是改好一个变量名， 拆分一个有点过长的函数，消除一点点重复代码，清理一个嵌套if语句。你想要为一个代码随时间流逝而越变越好的项目工作吗？ 你还能相信有其他更专业的做法吗？难道持续改进不是专业性的内在组成部分吗？

2.4 工具

代码格式化工具 - Astyle - 《代码格式化工具》

项目管理工具 - 禅道

版本管理工具 - Git - 《嵌入式固件Git使用规范》

AI Assistance - ChatGPT - 写单元测试

3 总结

        敏捷团队章程是一份鲜活的章程，每次团队回顾都值得来把回顾所得加入或者修改到敏捷团队章程。这份章程不在于面面俱到，恰恰在于刚刚好并鲜活的指导团队，让团队成员觉得有帮助。

        在具体实践中有争议时应当首先考虑团队章程是否对此有说明，如果有，按说明办；如果原说明不合适，如何修改；如果没有，是否值得加入。最后强调，团队章程的权威性应当高于团队里面的任何角色。保持团队章程的鲜活和权限，是团队持续敏捷的好办法。