敏捷团队的规范与准则

1.序言

打造一个金诚所至的敏捷团队，需要大家自发的来遵守以及完善相应的规范。大家在自我约束的前提下，彼此之间互相影响，由下而上推动团队的建设。所以规矩、准则应该是越少越好，通过良好的自我约束驱动团队的成长。 在阅读本文档之前，假设你已经了解了敏捷开发(Scrum)的相关知识，若从未接触过敏捷开发，请先查阅 《敏捷开发解决方案》。

2. 敏捷团队的共识

2.1 精诚合作

• 产品不只属于我个人，整个开发团队都必须对其负责。那么在需求评估、迭代计划、需求评审、开发、设计交流的时候，大家都应该积极参与，献计献策
• 必须达成共识，必须明确每次迭代的内容，而且知晓自己的和整个产品的进度
• 积极沟通，当然文档不是必须的，但是有准备的沟通是必须的
• 及时沟通，不过于依赖文档和工具，比如任务在Worktile上分配完毕，也给他们打个招呼。

2.2 按时参加每日站立会议

• 目的
  • 团队成员间工作进度的沟通和协调；
  • 帮助团队聚焦于每日活动，并且便于更新任务板和燃尽图；
  • 细化任务，尽可能的将任务具体到天，让大家都明确知道今天应该做什么！
  • 时间：每日下午5点，时长控制在15分钟左右
• 内容
  • 从上次站立会议到现在，你完成了什么?
  • 从现在到下次站立会议，你将要做什么?
  • 你遇到什么阻碍，需要其它人如何帮你?
• 注意
  • 不要迟到，延时，或者坐下
  • 不要在会议中讨论技术细节以及沟通需求。
• 提示
  • 团队成员在聆听他人发言时，都应该想这个问题：“我该怎么帮他做得更快？”

2.3 如果有必要，准备反思会议

根据项目需要举行。其目的不是为了找到治愈方案，而是要发现哪些方面需要改进。项目成员均可召开与推进。

• 要求
  • 从过去中学习，指导将来
  • 改进团队的生产力
  • 轮流发言。每个人都有机会在不被人打断的情况下讲出自己的想法，他认为什么是好的，哪些可以做的更好，哪些需要改变
• 注意
  • 不要在团队之外讨论找到的东西。
• 会议内容
  • 过去哪些做的不错？哪些应该改进？
  • 我们能做什么？哪些不在我们掌控之内？
  • 意见交流

2.4 保持可持续的开发速度/精力充沛的工作

• 尽可能避免加班（几乎所有的敏捷开发模式都反对加班，因为加班工作在软件开发中会降低生产率，而且会降低产品质量。我们目前还无法保障不加班，但是我们要尽可能的避免加班——将当天的事情在工作时间内完成）。
• 上班时间保持充沛的精力（比如早睡早起，喝点咖啡等等）
• 集中精力

2.5 参加每周讲座

这是一个自我锻炼和学习的机会，愿景是人人上台分享知识。

• 目的：鼓励大家交流、分享、学习甚至是反思。
• 讲座内容：技术、经验、心得、建议、产品与团队思考均可，亦可召开反思会议。
• 机制：每周一次，一次仅限一人，轮流讲座，次序可以根据需要调整。
• 时间：每周五下午评审会议之后，时间和日期可以更改，但是需要提前通知。如非客观原因，否则不能取消。
• 要求：必须准备PPT以及演讲素材。
• 时长：半小时左右。
• 讲师：敏捷团队成员。
• 参与人：无限制，自愿参加 
• 注意：讲座完成，需要将PPT和相关资料附加到Worktile任务列表，后续统一归档。

3.Worktile的使用规范

Worktile在敏捷开发中主要扮演了任务归档角色，因为Worktile 提供了非常灵活的任务列表以及任务（User Story、Task）创建、分配等，如下所示：

敏捷白板作为Worktile的补充，可以实时的跟踪任务，绘制燃尽图等，如下所示：

3.1 要求

• User Story 尽量使用作为…想…以便于…这样的语法描述
• 每次Sprint必须指定开始日期与结束日期
• 使用真人头像、真实姓名
• 在岗时间务必要查看Worktile 工作内容并及时更新任务状态，确保Worktile 与敏捷白板之间双向信息的同步
• 开发任务描述尽量具体化，如有标题（User Story）、标签、正文内容、计划完成日期（Product Backlog 内的除外），若需要正文内容，必须要有清晰的描述，同时务必设置检查项（Task）。多人任务@相关人。如果是多人任务，第一个人为任务负责人
• 任务必须设置相关人关注，一般是Product Owner
• 开发任务的颗粒度务必适中，以一个人为执行单位计算，单个任务的最大执行周期不能超过1周，建议在1-3天左右。执行周期超过1周的必须拆分
• 执行中任务的计划日期如果到了且还没做完，必须在过期前及时联系相关负责人且必须填写变更具体原因（相关负责人可以在评审会议时并变更为新的计划日期）
• 列表中最上面的任务优先级最高，请自上而下顺序执行

3.2 责任/纠纷仲裁

• 以Worktile中的沟通记录为参考依据仲裁，责任视情况而定
• 如Worktile无沟通的，任务负责人（分配人）全责

4. 计划会议的规范

迭代计划会议是指在每轮迭代开始时进行的计划会议，定义本轮迭代的目标，承诺本轮迭代中要完成的工作，提前识别和评估可能出现的风险，并通过合理的估算调整项目的迭代范围。

4.1 目标

• 制定合理的迭代范围和目标
• 明确迭代的开发任务

4.2 要求

• 如无特殊原因，敏捷团队相关者均需参加
• 会议召开的时间，若无特殊情况，即固定时间:周一上午10点。若有特殊情况，必须及时通知所有相关者具体开会时间

4.3 内容

• 这里只讨论这次迭代内容和上次Sprint反馈
• 需要确定任务的优先级和相关负责人

5.评审会议的规范

在每次Sprint冲刺结束，我们都需要进行一次评审会议，让团队向负责人展示已完成的功能。

如无特殊原因，敏捷团队相关者均需参加。

会议召开的时间，若无特殊情况，即固定时间:周五下午16点。若有特殊情况，必须及时通知所有相关者具体开会时间

5.1 目标

• 加强团队的自我认可。
• 展示功能、回答疑问并记录所期望的更改与反馈。
• 评审会议可以吸引整个团队的关注，让其他人了解团队在做些什么，并得到重要反馈。
• 做演示也会迫使开发团队真正完成一些工作（比如那些完成了99%的功能）。 

5.2 要求

• 由Scrum Master主持并记录。
• 确保所有人员都清晰目标，如果有人对产品不知道，则花几分钟来进行描述。
• 团队根据本次迭代内容，逐个地介绍这次 Sprint 的结果，和演示新功能。
• 会议过程中，Scrum Master需要记录需求变更、新想法、新需求、Bug或问题以及障碍，并且会后以评论的方式记录到Worktile上，提供给下一次计划会议作参考
• 如果功能无法演示，则以报表或者报告甚至其他任意形式证明。
• 如果问题优先级特别高，需要以加班的形式在本次迭代开发完成，添加任务后请立即找相关人的讨论并做后续安排

5.3 会议结果

• 对这次 Sprint 的结果和整个产品的开发状态的共识
• 注意：让演示关注业务层次，不要关注技术细节。注意力放在“我们做了什么”，而不是“我们怎么做的”
• 有的Sprint可能会包含很多Bug修复等功能，在评审会议中不要演示太多一大堆细碎的Bug修复，除非这个很重要。

6.代码规范

6.1 注释

• 类型（类、结构、接口）、属性、事件、委托、方法、方法参数，根据需要添加注释。
• 如果类型、属性、事件、方法、方法参数的名称已经是自解释了，不需要加注释；否则需要添加注释。

当添加注释时，添加方式如下图所示：

6.2 类型、字段、属性、方法、事件的命名

• 优先考虑英文，如果英文没有合适的单词描述，可以使用拼音，使用中文是不符合要求的。

6.3 不使用缩写

• 一般情况下，所有类型、方法、参数、变量的命名不得使用缩写，包括熟知的缩写，例如Msg。
• 一些游戏开发中常见的变量可以缩写，如：HP，ATK，DEF，MATK，MDEF等。

6.4 代码不使用半展开

• 第一步，打开Visual Studio，进入“工具”，“选项...”，如下图所示：

• 第二步，进入“文本编辑器” “C#” “格式设置” “新行”，确保左侧所有复选框中的被选择，如下图所示：

• 第三步，点击“确定”，完成设置。

6.5 使用Unix 换行符

• 第一步，打开Visual Studio 文件 高级保存选项

• 第二步，在行结束选择使用Unix(LF)最为换行符

6.6 使用Tab作为缩进，并设置缩进大小为4

• 第一步，打开Visual Studio，进入“工具”，“选项...”，如下图所示：

• 第二步，进入“文本编辑器”，“C#”，“制表符”，如下图所示，设置制表符。

• 第三步，点击“确定”，完成设置。

6.7 一个.cs源文件至多定义两个类型

• 如果两个类型的关系是紧密相关的，比如 产品、产品类型，此时Product类，和ProductType枚举可以定义在同一个Product.cs文件中。
• 但不能在一个.cs文件中出现两个不相关的类型定义，例如将 Product类和Reseller类（分销商）定义在一个BasicInfo.cs文件中。

6.8 类型名称和源文件名称必须一致

• 当类型命名为Product时，其源文件命名只能是Product.cs。

6.9 所有命名空间、类型名称使用Pascal风格（单词首字母大写）

• 如下图所示，红色标记的为使用Pascal风格的类型：

• 注意ProductType是私有类型，不管类型是公有的还是私有的，其命名总是采用Pascal风格。

6.10 本地变量、方法参数名称使用Camel风格（首字母小写，其后每个单词的首字母大写）

• 红色标记的为使用Camel风格的变量或者方法参数：

6.11 私有方法、受保护方法，仍使用Pascal风格命名

• 示例代码如下：

6.12 如果if语句内容只有一行，可以不加花括号，但是必须和if语句位于同一行

6.13 调用类型内部其他成员，需加this；调用父类成员，需加base

• 示例代码如下：

6.14 类型内部的私有和受保护字段，使用Camel风格命名，但加“_”前缀

• 代码示例如下：

6.15 不能出现公有字段

• 如果需要公有字段，使用属性进行包装。

6.16 类型成员的排列顺序

• 类型成员的排列顺序自上而下依次为：
• 字段：私有字段、受保护字段
• 属性：私有属性、受保护属性、公有属性
• 事件：私有事件、受保护事件、公有事件
• 构造函数：参数数量最多的构造函数，参数数量中等的构造函数，参数数量最少的构造函数
• 方法：重载方法的排列顺序与构造函数相同，从参数数量最多往下至参数最少。

6.17 委托和事件的命名

• 委托以EventHandler作为后缀命名，例如 SalesOutEventHandler。
• 事件以其对应的委托类型，去掉EventHandler后缀，并加上On前缀构成。
• 例如，对于SalesOutEventHandler委托类型的事件，其事件名称为：OnSalesOut。
• 示例代码如下：

6.18 返回bool类型的方法、属性的命名

• 如果方法返回的类型为bool类型，则其前缀为Is、Can或者 Try，例如：

6.19 常见集合类型后缀命名

• 凡符合下表所列的集合类型，应添加相应的后缀。

7.设计原则与规范

7.1 遵守测试规则

尽可能的编写单元测试，任务完成时先自我测试一遍。

7.2 签入代码后注意查看持续集成的生成结果

如果生成失败或者存在警告和错误，请及时解决，并作为优先级最高的任务来处理。

7.3 简单原则

简单设计，简单架构，简单编码还有简单评估，注重规范与重构。