敏捷团队的规范与准则

敏捷团队的规范与准则

 
回到顶部

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)创建、分配等,如下所示:
敏捷团队的规范与准则_第1张图片

敏捷白板作为Worktile的补充,可以实时的跟踪任务,绘制燃尽图等,如下所示:
敏捷团队的规范与准则_第2张图片

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 注释

  • 类型(类、结构、接口)、属性、事件、委托、方法、方法参数,根据需要添加注释。

  • 如果类型、属性、事件、方法、方法参数的名称已经是自解释了,不需要加注释;否则需要添加注释。

当添加注释时,添加方式如下图所示:

敏捷团队的规范与准则_第3张图片

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

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

6.3 不使用缩写

  • 一般情况下,所有类型、方法、参数、变量的命名不得使用缩写,包括熟知的缩写,例如Msg。

  • 一些游戏开发中常见的变量可以缩写,如:HP,ATK,DEF,MATK,MDEF等。

6.4 代码不使用半展开

  • 第一步,打开Visual Studio,进入“工具”,“选项...”,如下图所示:
    敏捷团队的规范与准则_第4张图片

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

敏捷团队的规范与准则_第5张图片

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

6.5 使用Unix 换行符

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

敏捷团队的规范与准则_第6张图片

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

敏捷团队的规范与准则_第7张图片

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

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

敏捷团队的规范与准则_第8张图片

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

敏捷团队的规范与准则_第9张图片

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

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

  • 如果两个类型的关系是紧密相关的,比如 产品、产品类型,此时Product类,和ProductType枚举可以定义在同一个Product.cs文件中。

  • 但不能在一个.cs文件中出现两个不相关的类型定义,例如将 Product类和Reseller类(分销商)定义在一个BasicInfo.cs文件中。

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

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

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

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

敏捷团队的规范与准则_第10张图片

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

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

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

敏捷团队的规范与准则_第11张图片

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

  • 示例代码如下:

敏捷团队的规范与准则_第12张图片

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

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

  • 示例代码如下:

敏捷团队的规范与准则_第13张图片

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

  • 代码示例如下:

敏捷团队的规范与准则_第14张图片

6.15 不能出现公有字段

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

6.16 类型成员的排列顺序

  • 类型成员的排列顺序自上而下依次为:

  • 字段:私有字段、受保护字段

  • 属性:私有属性、受保护属性、公有属性

  • 事件:私有事件、受保护事件、公有事件

  • 构造函数:参数数量最多的构造函数,参数数量中等的构造函数,参数数量最少的构造函数

  • 方法:重载方法的排列顺序与构造函数相同,从参数数量最多往下至参数最少。

敏捷团队的规范与准则_第15张图片

6.17 委托和事件的命名

  • 委托以EventHandler作为后缀命名,例如 SalesOutEventHandler。

  • 事件以其对应的委托类型,去掉EventHandler后缀,并加上On前缀构成。

  • 例如,对于SalesOutEventHandler委托类型的事件,其事件名称为:OnSalesOut。

  • 示例代码如下:

敏捷团队的规范与准则_第16张图片

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

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

敏捷团队的规范与准则_第17张图片

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 简单原则

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

 
 
转自:http://www.cnblogs.com/OceanEyes/p/Cronoworks-Scrum-Specification.html

你可能感兴趣的:(敏捷团队的规范与准则)