使用TeamBition进行敏捷开发
最近开始新的项目,由于人数也不多,需求也比较模糊,因此觉得可以试一试采用敏捷开发的模式来进行过程管理.于是研究了一下如何方便的进行这方面的管理.
SCRUM
基本概念
Scrum就是敏捷开发中的一种模型.它主要有三个基本的概念:
- 角色
- 工件
- 活动
1. 角色
- Product Owner(产品负责人):负责维护产品订单的人，代表利益相关者的利益。
- Scrum Master(Scrum管理者):为Scrum过程负责的人，确保scrum的正确使用并使得Scrum的收益最大化。
- Team(研发团队):由负责自我管理开发产品的人组成的跨职能团队。
他们的职责分别是:
Product Owner
- 建立愿景:确认产品的项目愿景
- 定义产品路标:确定大得功能以及客户的期望
- 确定需求:生成故事描述
- 维护Product Backlog:确定功能优先级,确保对即将开始的迭代故事进行了足够的细化
- 客户验收:能让客户使用产品提供反馈
- 计划:确定交付时间,跟踪进度
- 协调:协调团队需要的资源
Scrum Master
- 确保流程的贯彻执行:对如何执行上达成一致,保证团队一致的执行流程
- 找到并去除障碍:找到任何妨碍目标达成的障碍,并设法调动资源去除障碍
- 保证内部沟通的顺畅:保证团队沟通顺利,高效
- 维持工作环境:确保整个项目中团队的工作节奏和工作进度.
- 团队提高:确保团队的人员是合适的,在团队中组织技能培训,通过激发创造性与推动授权来提升团队成员
Team
- 协作:具有不同特长的团队成员,形成高度的自我管理能力,保持节奏的实现每一次Sprint目标
- 维护架构:保证架构的稳定性和持续性
- 掌握需求:团队有这人明白具体需求是什么,如何实现.
- 保证质量:通过代码标准,持续集成,配置管理,内外测试等保证产品的质量
- 设计方案:决定如何编写代码实现需求,包括单元测试和自动化测试
2. 工件
Product Backlog (产品订单):
- 面向客户的需求
- 需求可评估,可实现,可测试
- 待完成的工作列表
- Product Owner需要对列表进行优先级排序
- 每个迭代开始前需要持续修正
Sprint Backlog(冲刺订单,迭代周期)
- 细化需求
- 可执行的任务
- 团队中任何人都可以增加删除更改
- 对于面对困难不清楚的,可以逐步细化
- 每日更新
燃尽图
迭代中任务的总体完成情况
3. 活动
Sprint Planning Meeting(计划会)
- 分析和评估产品Backlog各项目
- 选择一些作为迭代的目标
- 决定如何实现迭代目标
- 以小时为单位评估迭代任务工作量
Daily Standup Meeting(每日立会)
- 每天都要开
- 15分钟左右
- 早上或晚上都可
- 不是为了解决问题
- 所有相关人员都被邀请
- 每个人都要发言
- 只说三个东西:1.已经做了什么 2.将要做什么 3.遇到的困难
Review Meeting(评审会)
- 演示所完成的迭代工作
- 非正式的,不需要正式演示文档等
- 整个团队都要邀请
- 讨论有问题的地方
Retrospective Meeting(回顾会)
- 周期性的
- 总结工作中的经验和教训
- 讨论本次迭代中的不足
- 整个团队都要参加
开发过程
- 首先明确产品的功能确定Product Backlog,由Product Owner负责.这个允许持续变化和增加
- Product Owner对产品订单进行筛选,提炼最核心的需求.
- Scrum Team根据Product Backlog列表,做工作量的预估以及业务逻辑,功能流程的梳理
- 通过Sprint Planning Metting会议,从中挑选一个Story作为本次迭代完成的目标,一般迭代的周期是2-4周.
- 然后把这个Story进行细化,形成一个Sprint Backlog.
- 每一个团队成员根据Sprint Backlog再细化成更小的任务(尽量每个任务的工作量在2天内能完成).(每一个任务至少需要两人来评工作量,扑克游戏方法评估)
- 每天需要进行 Daily Stand Meeting,每次会议控制在15分钟左右,每个人必须发言,并且向所有成员当面汇报1.你完成了什么,2.承诺将要完成什么,3.遇到不能解决的问题也可以提出.
- 做到能随时集成,使用GIT+MAVEN+Jenkin持续化集成.
- 当一个Sprint Backlog完成,也就表示一次迭代完成,需要进行Srpint Review Metting,产品负责人和客户都要参加.用于演示完成迭代的软件产品.然后客户提出意见和建议,收集起来作为后续迭代的需求.
- 最后进行Sprint Retrospective Meeting,总结并讨论本次迭代中的问题和还需要改进的地方,放入后续迭代的需求中.
TeamBition
Teambition 强大、简洁的任务版功能，快速提升整个团队的工作效率。
经过试用觉得还可以,能方便我们完成整个敏捷的流程.
界面
这个是他的主界面,上面有各种项目
这个是它用户的主页,上面记录了整个团队的各种变动,以及今天的任务等等
这个就是它最核心的任务看板了,对应了Scrum中的白板功能,能把某一个迭代周期的任务按照阶段分出来.
这个是分享墙的功能,也就是可以作为一个在线的WIKI来使用的.他支持普通的文档以及markdown文档.我们可以把自己的各种API文档,开发文档等等都放到这里共享出来.
这个是文件库功能,也就是一个在线的网盘,单个文件最大200MB,不限制文件个数.因此可以把各种原型,素材,资料,工具等等都放入到这个里面.
接下来就是日程功能了,这个就和iCal outlook里面的日程是一样的.同样可以增加参与者等等,然后到时间后可以通知大家
回顾功能用于查看大家一个周期内做了什么事还是比较有用的.但是我觉得还缺少了周报的功能,这点的话 team.oschina.net 做的就要好些.毕竟有些时候公司上面是要看周报说话的,没有这东西不得行啊…
标签功能是提供了一种把任务分组的方式.我个人是比较喜欢标签的方式来整理任务的.因此这也是我选择teambition而没有选择worklite等等的原因.它对Tags的支持是最完整的.可以自定任意个标签,一个任务可以绑定任意个标签.
Scrum过程
这里开始介绍下如何套用teambition来实行Scrum
产品的需求收集
首先,我们会增加一个任务分组,名字叫:Product Backlog
它有五栏:
- 收集需求:就是原始的客户需求,需要我们完成的
- 确认需求:经过一定整理有优先级的确认必须要实现的需求拖入这里.Scrum Planning Metting需要关注这里的需求.然后在备注或者标签上指明状态,以及迭代的版本
- 开始研发:当这个需求进入开发的时候,拖入到这里.
- 进入测试:开发完成,拖入需求到进入测试.这里的测试只的不是QA的测试,应该是用户或产品人员的DC
- 完成:如果需求开发并完成测试,能发布了,就拖入到这里
Sprint Planning Meeting
有了产品需求之后,接下来的就是开迭代计划会议了,这里可以使用日程表的功能来安排会议.然后通过会议的结果来制定迭代的开发排期:
这里面就安排了几个迭代的周期,每一个周期的时间是什么.并且也是燃尽图的功能.蓝色表示近期的任务,绿色表示完成的任务,红色表示逾期的任务.通过这个就能很直观的看到整个迭代周期任务的完成情况.
Sprint Backlog
通过计划会议把Product Backlog中的东西拆分了放入到迭代周期中.对于最近的迭代周期,进行详细的任务拆分和工作量的评估:
有五栏:
- 需要做:本次迭代需要完成的需求,与产品不同,这里更关心的是技术层面,需要标号
- 如何做:细分到两天以内的任务.需要标上子号
- 正在做:正在完成的任务拖入到这里,并且允许再次细化
- 做测试:完成开发的拖入到这里,这里指的就是软件的测试,如果是子号,由开发自己测试.如果是大号,由测试人员测试.
- 完成:如果需求开发并完成测试,能发布了,就拖入到这里.如果是子号,由开发拖入,如果是大号,由测试人员拖入
当任务需要进行到下一个阶段的时候,相关人员通过拖动任务卡片,将其移动到下一阶段.同时可以通过修改执行者来告知对方进行下一步的工作了.同时会给每一个任务设置截止时间,这样当时间到的时候会在我的今日视图中非常明了的看到需要做什么,而且如果超过时间了,会以红色标识.但是这里我认为最好在加上一个开始时间,因为一个任务有可能会有两天的时间,那么当在开始做的时候,可能并不是截止日期当天.这样他就不能很直观的提醒我今天需要做什么了.按照GTD的方式其实都有个日程和今日代办两类的,都是可以设置任务的开始时间的.
问题支持
是软件都是有问题的.那么缺陷的管理也是非常重要的.因此我增加了一个任务分组名叫问题支持,这个其实是在scrum中是没有的.
有四栏:
- 系统问题:发现的BUG或Issue放入这里,打上标签
- 解决中:开发认领问题后,把问题拖入到这里,然后在子任务中可以增加一些开发的Task.并完成
- 验证中:问题修复后,拖入到这里.测试关注其中的问题,然后一一进行验证.如果有问题,打回到解决中.并修改Tag.如果没有问题,拖入问题解决
- 问题解决:解决了的问题放入到这里.
由于teambition是由任务为导向的,目前还不知道到底用来管理缺陷靠谱不.只有试一试再说了.如果不得行,可能还是会换成redmine来进行管理.但是这就又多了一套体系.
其他
整个teambition中到处都是可以增加评论和收藏的.我觉得这个也是比较有用的东西.一个任务发布出来,团队成员可以针对这个任务做一些讨论或意见,然后全部保存下来,真正做这个任务的人可能就会得到很多的帮助.
但是目前整个teambition中创建讨论还是比较麻烦.没找到直接创建讨论的地方,只能先建立一个任务当做一个话题.然后在里面发表评论作为讨论的发言.teambition这个团队的另外一个产品简聊到是是完成这个功能的东西,但是又需要开一个另外的工具,都觉得比较麻烦.于是也就罢了.
总结
这个算是我们团队的一个新的尝试,使用新的工具,使用新的过程模型来完成新的目标.目前试用了一周,感觉还是可以的.具体的成效就等到这个项目完了以后再来补充吧.
PS:TeamBition的界面我个人觉得单调了点,随便比Tower.im好看些.但是我觉得比不上WorkLite.还有就是所谓的桌面客户端,简直是太偷懒了!!直接就是一个node-webkit浏览器,这个和我直接打开safari有啥区别….而且在接收通知的时候有可能CPU还要狂飙.. 你看人家doit.im 客户端就是客户端,网页就是网页,多好~
