1、轻量级敏捷项目入门

a. 了解轻量敏捷

使用Tapd进行敏捷实践

从创建需求、建立版本迭代、迭代进度跟踪和缺陷管理、到迭代评审回归,到最终交付发布,代表一个轻量的敏捷流程。

b. 创建需求Backlog

b. 1.什么是需求Backlog
需求Backlog是产品待实现的需求列表,Backlog中的需求按照对用户的价值排序

b. 2.为Backlog创建需求
需求是敏捷中的User Story,从用户角度描述的独立的功能点。

需求描述包括:
As a…作为…角色或岗位)
I want…(我想…希望做什么)
So that…(以便达到什么目的或商业价值)

b. 3.划分优先级
为每个需求按照用户价值划分优先级

b. 4.拆分需求
将需求进行拆分,拆分到以用户角度可接受的最小颗粒度功能作为子需求,子需求是可以规划到迭代中的需求

创建需求Backlog->划分优先级->拆分需求。

c. 规划迭代

c. 1.什么是迭代
迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

c. 2.创建迭代
为造代制定明确的目标,确定迭代的开始和结束时间。

c. 3.规划迭代
从需求Backlog中挑选优先级最高的需求放入迭代。为迭代中每个需求评估规模,确定迭代的需求范围。

c. 4.工作分配
团队成员认领选代中的工作。

无迭代,不产品。规划迭代,一定是产品研发流程中的一个重中之重的工作。

d. 跟踪迭代进度

d.1.故事墙
直观展现迭代下的需求状态,支持拖动

d.2.迭代燃尽圈
迭代燃尽圈,展现迭代中所有需求的剩余规模总和随日期的变化而迷日递减的燃尽过程。实际燃烧线(蓝线)与基准线(红线)越贴合,迭代的进度越健康。

实时燃尽图展示,可以很明确的看到所有需求的剩余规模综合随日期的变化而逐日递减的燃尽过程。

e. 质量回顾

其实就是Bug缺陷管理,这块对缺陷的管理也还是很人性化的。

f. 迭代回顾

f.1.回顾会议
迭代结束后,团队一起进行迭代回顾,总结Well和LessWell,发现改进点,提出解决措施。使团队在接下来的迭代中更高效。

f.2.知识沉淀

通过上面的几个简单步骤,基本就能了解轻敏捷的流程。
用Wik沉淀团队智慧。

2、需求管理

使用Tapd进行敏捷实践

产品研发过程中,需求管理是个大难题。作为产品负责人或产品经理,会收到来自老板、开发、用户、运营、市场、销售等方面的反馈需求,如果不能很好的管理这些需求,一定会给自己带来很多不必要的麻烦。TAPD平台对需求管理主要有一下几方面的优点:

a. 统一需求池: 拿到各个需求后将所有的需求都先扔进需求池,而不是埋头开干;
b. 需求细化:对需求进行分析,是否合理,是否必要,优先级是否高、处理人是谁、有什么商业价值,可能需要多久等等问题进行细化;
c. 版本迭代:将分析后的需求,结合版本规划,安排进入到适当的版本中,进行中的版本迭代功能和需求一定是清晰的、优先级高的,研发过程中,产品经理再对下面迭代版本的需求进行细化分析和设计;

3、迭代管理

使用Tapd进行敏捷实践

能结合需求,建立很好的迭代版本管理,让迭代管理可视觉化,现在究竟处理哪个迭代版本?完成的进度如何?有哪些工作还没完成?后续迭代计划是怎么样的?通过迭代管理,可以很方便直接的看出来。

4、故事墙

使用Tapd进行敏捷实践

就是白板story wall,平时工作中很多团队都会使用,这些团队会把每天开发的一些产品特性采用story的方式每天都在白板里面展示出来,整个团队每天都会围绕这个白板能够清晰的看到整个产品或者整个项目的一个过程,包括整个产品特性的过程。

故事墙了解敏捷的都知道,传统是用一块白班,划分为各个区域,不同的人采用不同的颜色纸条,分别标识出自己计划中什么(规划中)、正在做什么(实现中)、已完成哪些(已实现)和已经拒绝哪些(已拒绝),已拒绝的可能是需要协助的,也可能是无法完成的或不合理的。
这样通过故事墙,就能实时清晰的看到没有人的做事进度和所做的事情,非常直观明了。

5、缺陷管理

使用Tapd进行敏捷实践

所有Bug缺陷的状态跟踪和管理,能定位到版本、严重程度、优先级、当前状态、处理人和创建人等信息。

6、统计分析

使用Tapd进行敏捷实践

采用统一平台的好处,就是方便进行统计分析和绩效考核,一个项目执行完后再去收集这些信息其实是很难的一件事,采用平台,自动进行统计分析,完成了哪些需求,每天分别做的什么事情?发布了多少个迭代版本?产出了多少个Bug?输出了多少文档?通过平台都能一目了然。

迭代总结

在每一个产品发布的时候都会有一个总结。具体的做法是,把做得好的、不好的总结出来,做得好的在下一次迭代发扬光大,做得不好的在下一次迭代就要注意改进。这样的总结是要求项目的所有成员都必须参加,包括项目的开发人员、测试人员、QA、项目经理、产品经理等,每个人都要去去总结他在上一个迭代中碰到了什么问题,通过便签纸的方式贴出来,项目经理实际上可以看成是SCRUM Master,包括站起来总结这样一些东西,包括我们下一次迭代继续发扬什么,必须要注意什么东西,最后就会得出一个Excel的文档,包括上一个迭代中出的问题,具体的解决办法,都会有。

一个完整的迭代过程

包括概念、设计、开发、测试和发布五个过程。在概念阶段,会采用FDD里面提到的一些好的最佳实践来支撑到我们怎么样去敏捷的做需求开发,会制定一些产品发布的计划,比如产品在未来,某个迭代什么时候发布,要发布哪些产品特性,都是在这个阶段做的。在设计阶段,会做产品原型上的设计。对于互联网产品说更多的是通过快速原型法快速的让产品在不同范围内去做一些体验,比方产品在某个迭代的一个小迭代里面,可能会在一个团队里面先去体验,可能就会采取发布到公司某一个部门去体验,或者发布到整个公司范围去体验,它会是一个不断放大的一个过程。在开发和测试阶段,更多的采取XP的一些实践,包括编码规范,代码走读,比如1周一次代码走读,构建持续集成的环境,包括自动化构建,自动化测试等,会有一些好的测试上的实践,如全员测试,就是将测试看成不仅仅是测试人员的工作,更多的是整个团队的工作,当然也包括这个产品的其他同事的工作,通过全员测试来激发大家对产品质量负责。在发布阶段,腾讯采用的是灰度发布,同传统的软件发布不一样。项目中整个迭代过程就通过类似SCRUM模式去管理,如有每日晨会,如何建设团队氛围,统一的管理平台,每次迭代完成时的总结回顾等等,这属于项目管理的工作。还有一些基础的工作,如代码管理,版本管理,文档管理,异地开发管理,这些在腾讯的整个管理体系里面都包含的,还有会制定一些相关的规范,不过规范不是很强硬的要求每一个项目必须执行,更多的由团队自己选择,让他们根据自己团队的特点、规模去选择应该采取哪些实践。

7.灰度发布

这是互联网的一个特点,说白了,就是对用户一个逐步放量的一个过程,而且不要求团队要尽早的将产品包发布出来,也就是不要求马上发布给所有用户,而是会分批的去发布,比如按号段发布,比如在公司内部先体验。发布的时候也有策略,比如发布时如何放量,对用户有些什么样的实验,技术上怎样做一些后台开关,运营上怎样跟进,怎样保证4小时人员的留守,发布完后怎样收集用户反馈等等都会有一些统一的规则。比方实验室某WEB 产品的发布,可以同时有多个版本,1.1版可能会有100% 的用户在用,1.2版可能只有1% 的用户在用,它们是一个交叉升级的过程。

8.用户研究

如何加强用户的参与度,这是一种成本比较低的用户研究方法。通过抓取一些用户数据做分析,分析用户在这个产品上整个体验的过程是怎样的,通过后台的数据可以看到整个活动的曲线,同时CE也可以通过一些科学的手段去保证,包括市场调研、用户研究、数据挖掘、产品体会等,这就是通过一些对用户反馈、用户观察的工具去配合去对用户做研究。比如我们可以到现场去做的一个调研,经常会由产品经理和用户研究人员到用户的实际办公地点进行调研,做一天的反馈,通过观察用户一天是如何使用你的产品,配合一些相关的工具去科学的分析。因为互联网是非常强调同用户的这种反馈的,腾讯有自己内部的一个CE反馈平台,在这个平台上可以收集到所有用户的反馈,产品经理可以每天都会看到他所负责的产品有哪些反馈,包括内部的、外部的,然后他就可以根据这些反馈对产品进行一些快速的调整,包括开发一些什么样的产品特性,内部同事也可以踊跃的在平台上反馈