1、 团队优先
个人觉得,不管做啥,应该把“团队合作”放在第一位。如果团队本身没有凝聚力,没有向心力,那团队就是一盘散沙,有力无处使。“敏捷”也不例外,敏捷宣言中第一句就是“个体和交互 胜过 过程和工具”,充分强调了团队合作的重要性。
如果把“敏捷团队”比作一个木桶,那么团队中的每个角色就是组成木桶的木板,团队的效率就是桶里的水。根据木桶原理,团队中只要有任何一个角色不够效率,不够敏捷,那么整体的效率也就受到影响。
所以,我的观点是,“敏捷”的前提是“团队优先”,重视团队,重视团队中的每个角色,无差别的对待每个合作成员,让每个角色、成员有动力,有激情的弥补自己的短板,让自己更敏捷,从而促进整个团队的敏捷。
所以,应该跳出旧的思维,看看到底是自身不敏捷,还是其他成员、团队、组织的不敏捷影响了整体的“敏捷”。
问题:
产品经理、策划人员、设计人员(UE、UI),开发人员,测试人员、运营人员……都做到敏捷了么?
2、 需求为主
所有的一切源于需求。由需求而生,随需求而灭。
所以,我的观点是,“敏捷”从“需求”开始。
自然而然,从产品经理、策划人员的“短板”抓起。从需求说起,书上说,他们需要做的第一件事情就是整理需求 --- 编写用户故事
3、 编写故事
书上说用户故事代表对用户、客户有价值的功能,即用户(客户)需求,不含过多的需求细节。
不过个人觉得产品经理、策划等“产品人士”,其专业性一般强于非专业人事,通常有他们自己的想法,所以可以预先以非故事的方式,比如注释、要点的方式进行简单记录。
关于用户故事的编写要求,可网上搜索相关资料,这里暂时不提供。当然,也不必要完全参照网上说的一定要是某种格式,关键是怎么方便,有效。怎么样写一份好的需求,是合格的产品人士必备的技能
4、 讨论细节
书上说,需求的细节要在“对话”中获得,并在确认部分得以记录。
这里,团队成员在聚在一起,头脑风暴,针对3中的每个用户故事,逐个展开关于需求细节,并记录讨论结果
特别说明:
很多事情,唯有参与,才有认同.....。
5、 版本规划
确定当前迭代的版本包含的需求及优先级安排
6、 任务量评估
开发人员评估大致大致的工作量。
7、 原型设计
将讨论结果以以实际的原型、界面展现出来,是构建一个真正产品很好的方法,同时把重心从“需求文档评审”转移到“原型(Demo)评审” ,以原型评审为中心,辅以必要的文档说明,作为原型的补充,也是去掉无用的功能定义文档、需求文档可行方法。
原型设计好了,共享给相关人员查阅,以便及时获得反馈,及时更正,如果时间来得及,最好是评审下原型
8、 项目开发与用例设计
开发人员根据原型进行项目、产品开发,测试人员根据用户故事、原型(假定原型已经被认可的情况下)来测试设计用例。
说明:
这里为了方便,建议用类似xmind工具或excel等来写编写需要评审的测试用例,方便评审,同时,建议编写一份按功能模块汇总的用例。
这里有些人可能会觉得写两份用例,麻烦,耗费时间,但我认为实际花不了多少时间,因为执行中可在“复制黏贴”的基础上完成,而且用例某种程度上也代表了产品整体,有一份按模块展开的用例,让你很容易看到“大局”,不仅在测试时起到很好的提醒作用,而且还方便优化用例。 再进一步,要是把汇总的用例,写在管理系统,比如禅道上,是不是容易分配任务、跟踪任务、统计任务执行等情况呢?
备注:用例是需要维护的,需要不断优化的,试问,做测试的亲们,你们能一次性就写出很完美的用例么,特别是在很时间短,项目赶的情况?不能吧,,,所以如果每次都在前一次基础上修改,迭代,效果是否会好点呢?
例子
汇总的用例:
提交评审用例: