敏捷团队的规范与准则
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 常见集合类型后缀命名
- 凡符合下表所列的集合类型，应添加相应的后缀。
| 说明 | 后缀 | 示例 |
|---|---|---|
| 数组 | Array | int[] productArray |
| 列表 | List | List productList |
| DataTable/HashTable | Table | HashTable productTable |
| 字典 | Dictionary | Dictionay productDictionary |
| EF中的DbSet /DataSet | Set | DbSet productSet |
7.设计原则与规范
7.1 遵守测试规则
尽可能的编写单元测试，任务完成时先自我测试一遍。
7.2 签入代码后注意查看持续集成的生成结果
如果生成失败或者存在警告和错误，请及时解决，并作为优先级最高的任务来处理。
7.3 简单原则
简单设计，简单架构，简单编码还有简单评估，注重规范与重构。