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

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

说到敏捷开发，相信大家都多少有了解。目前大部分互联网公司的开发模式肯定不是传统的瀑布式开发，更多的应该是偏向于敏捷开发。最近一段时间参与的项目，项目组采用的是敏捷开发迭代制度，虽然可能和严格意义上的敏捷开发有所区别，但是适合的才是最好的。在实践中，通过项目的反思总结，制定适合自己团队的敏捷模式是最好的。
首先简单来介绍一下敏捷开发：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态——来自百度百科。 简单来讲，在快速发展的互联网时代，开发周期不宜太长，采取小步迭代，更能适应当今这个时代。
网上的敏捷开发的流程图是这样的：

我们项目组的流程，实际是这样的：

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

需求整理阶段

时间： 此环节的时间往往不计入迭代周期，一方面是需求和设计经常会发生变动，而功能设计确定后，进入开发阶段的变动比较少；另一方面是开发在进入当前迭代的时候，此时产品就应该进入到下一个迭代的设计周期了。
参与人员： 产品人员、技术负责人、项目经理
工作任务： 此环节任务其实不少，包括了产品人员对迭代的需求进行梳理，对需求完成设计。产品在完成产品方案后，小范围召集产品经理、技术负责人、进行评审。在交互稿、设计稿都完成后，进行召开迭代会议。
产品关注： 此阶段产品的主要工作是在需求池中进行筛选，整理出高优先级的任务，作为此次迭代的功能列表。因笔者都是在小公司，所以产品文档、交互稿都是由产品人员通过原型来展现。
踩过的坑： 某次该会议叫了过多的人，导致会议时间过长，会议效果也不好（由于此环节主要是对总体功能列表进行讨论，只需叫上产品小队、技术负责人就够了）；还有就是设计的原型在此阶段就做的太细，导致部分需求其实并不需要（此环节设计以大的框架及流程为主，细节的交互、规则等可以在之后再根据需要进行完善）；

迭代会议阶段

时间： 此环节为迭代周期正式开始
参与人员： 项目组所有人员
工作任务： 此阶段为任务讲解、计划。主要为产品经理对此次迭代的主要任务进行讲解，包括需求来源、产品设计，技术人员对此次迭代的时间进行排期。
产品关注： 该会议就是传说中的评审会议。产品要多做准备工作，因为会有很多人来怼你，主要还是以业务流程、规则、交互等具体实现的东西，因为技术要进行开发，很多东西需要问清楚。
踩过的坑： 这个环节坑就是看被怼的惨不惨

关键字：产品经理, 敏捷开发, 项目总结

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！