产品视角|这是一次敏捷项目的总结

4 评论 11834 浏览 122 收藏 9 分钟

本文作者将结合自身经验,与大家一起来聊聊敏捷流程中每个环节的主要任务及内容。enjoy~

说到敏捷开发,相信大家都多少有了解。目前大部分互联网公司的开发模式肯定不是传统的瀑布式开发,更多的应该是偏向于敏捷开发。最近一段时间参与的项目,项目组采用的是敏捷开发迭代制度,虽然可能和严格意义上的敏捷开发有所区别,但是适合的才是最好的。在实践中,通过项目的反思总结,制定适合自己团队的敏捷模式是最好的。

首先简单来介绍一下敏捷开发:敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态——来自百度百科。简单来讲,在快速发展的互联网时代,开发周期不宜太长,采取小步迭代,更能适应当今这个时代。

网上的敏捷开发的流程图是这样的:

我们项目组的流程,实际是这样的:

虽然和许多标准的敏捷流程不完全一样,但其实我们的流程保留了核心的几个环节。接下去来聊聊每个环节的主要任务及内容。

需求整理阶段

时间:此环节的时间往往不计入迭代周期,一方面是需求和设计经常会发生变动,而功能设计确定后,进入开发阶段的变动比较少;另一方面是开发在进入当前迭代的时候,此时产品就应该进入到下一个迭代的设计周期了。

参与人员:产品人员、技术负责人、项目经理

工作任务:此环节任务其实不少,包括了产品人员对迭代的需求进行梳理,对需求完成设计。产品在完成产品方案后,小范围召集产品经理、技术负责人、进行评审。在交互稿、设计稿都完成后,进行召开迭代会议。

产品关注:此阶段产品的主要工作是在需求池中进行筛选,整理出高优先级的任务,作为此次迭代的功能列表。因笔者都是在小公司,所以产品文档、交互稿都是由产品人员通过原型来展现。

踩过的坑:某次该会议叫了过多的人,导致会议时间过长,会议效果也不好(由于此环节主要是对总体功能列表进行讨论,只需叫上产品小队、技术负责人就够了);还有就是设计的原型在此阶段就做的太细,导致部分需求其实并不需要(此环节设计以大的框架及流程为主,细节的交互、规则等可以在之后再根据需要进行完善);

迭代会议阶段

时间:此环节为迭代周期正式开始

参与人员:项目组所有人员

工作任务:此阶段为任务讲解、计划。主要为产品经理对此次迭代的主要任务进行讲解,包括需求来源、产品设计,技术人员对此次迭代的时间进行排期。

产品关注:该会议就是传说中的评审会议。产品要多做准备工作,因为会有很多人来怼你,主要还是以业务流程、规则、交互等具体实现的东西,因为技术要进行开发,很多东西需要问清楚。

踩过的坑:这个环节坑就是看被怼的惨不惨? 。主要有两方面的准备吧,一个是人,因为前期有准备过小范围的评审(需求整理会议),你要拉拢其他的人员认可你的东西,这样在会议中,这部分人会帮你回答(至少不会提问你);另一方面还是文档(原型),在设计的时候要多思考,把各种情况考虑全,这样在会议中被提问时,就能够很好的回答他人。

迭代计划阶段

时间:开发、测试阶段

参与人员:项目组所有人员

工作任务:此阶段为开发阶段,技术负责人对功能列表进行拆分、排期,开发人员开始进入编码阶段。测试人员根据需求书写测试用例,在开发完成提成后,进行产品测试。

产品关注:本阶段产品主要是和开发人员保持沟通,一些在开发过程中会发现的有疑问的地方,需要产品去决策,该如何做。产品提测后,产品人员也要及时去对开发好的功能进行验证,看是否符合预期。在这间隙,产品需要开始对下一个迭代的需求进行梳理。

每日例会:此会议初衷是对每天的工作进行回顾,主要是看当天的任务完成情况,是否有难处等,让大家对项目的进度有一个了解。但是实际应用中,我们的例会效果不是很好。建议通过一些协作工具,用图表来展示,这样更有直观性。

踩过的坑:迭代过程中最大的坑应该是需求变更了。原则上迭代会结束后,不能在此迭代里新增需求。但是需求变更常常就会有新增,这时候需要去评估。如果是改动大的需求,需要召集小分队人员进行讨论,看是否必要加入此次需求;如果是小的改动,则进行相关文档的更新,并通知到项目组成员。

发布演示阶段

时间:开发测试完成后,进行产品的发布更新

参与人员:项目组所有人员

工作任务:此阶段为迭代的尾声,在测试完成后,根据需要在不同的环境进行发布,发布后,可能需要去演示。

产品关注:到此阶段,就正式完成一个迭代的周期了。产品人员应该也梳理好了下一个迭代的需求,在本迭代发布且通过后,就需要开始新一轮的迭代工作了。

踩过的坑:更新经常到更凌晨。发布前一定要做好测试、发布前准备工作,要定好发布计划,不然很容易陷入到发布-测试-发现bug-修改bug-测试-发现新的bug….反正每次更新都不省心,经常到凌晨。

 

本文由 @pauly 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 作者说出的自身经历是有参考价值的

    回复
  2. 敏捷迭代很可能就是一遍一遍的抄翻重來。

    回复
    1. Md好有道理

      回复