敏捷团队的规范与准则
敏捷团队的规范与准则
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<string,string> productDictionary |
| EF中的DbSet /DataSet | Set | DbSet productSet |
7.设计原则与规范
7.1 遵守测试规则
尽可能的编写单元测试，任务完成时先自我测试一遍。
7.2 签入代码后注意查看持续集成的生成结果
如果生成失败或者存在警告和错误，请及时解决，并作为优先级最高的任务来处理。
7.3 简单原则
简单设计，简单架构，简单编码还有简单评估，注重规范与重构。