敏捷开发被越来越多的创业者奉为最适合初创公司的开发方法，可是在实际运用中，敏捷开发给我带来的是一个又一个的坑，如果没有对这种开发方法更深层的掌控，可能会打乱你的产品工作，得不偿失。
经过一段时间的沉淀，我认为敏捷开发的要求是：
方向准！
速度快！
过程在一定程度上可控！
先聊聊被坑的问题：
使用敏捷开发后，我们的产品工作似乎更贴近需求了，每个功能都有不同的改进方向。用户带来的反馈也非常好。开始我们非常开心，努力让子功能更加贴合市场需求，一个个最小可行产品（MVP）逐渐变成了一个个有需求产品。
看似非常美好的未来破灭了。在做产品架构时，经验不足的我们被各种奇奇怪怪的逻辑征服了。各种找竞品分析学习，陷入了一种两难的纠结中。究竟是砍掉有需求、但难以融入产品的子功能，还是构造一个合理的产品逻辑，将各种功能融入进去？有些功能的需求爆发很快，但有些功能需求需要粘性，单单看产品的新增、日活、留存数据难以准确判断。到底砍不砍，怎么砍，实际上是敏捷开发的核心问题。
我们怎么躲避这些坑？
我认为这就需要我们提出的这三条原则：
1、方向准。
在实现一个个MVP前，一定要做子功能构架的规划。
做好子功能构架的规划，有助于你了解子功能在整体产品中充当的角色。每个子功能可能只是为了支撑产品的某一种数据，从而达到一种1+1>2的效果。
2、速度快。
为什么要速度快呢？不是因为竞争，而是因为需求。当你的产品迭代不够快，被用户推着走的时候，你会发现产品离开了你原本在做的方向，在这个方向我的意见是不要过多地考虑用户对产品方向上面的建议，尽快地迭代出你认为好玩的功能和产品，不要投放在细节上过多的精力耽误了你对方向的思考与把控。
3、过程在一定程度上可控。
过程必须相对可控。虽然是敏捷开发，你也要对每一项功能的进度有掌控。在此基础上，对开发过程时的优先级判定上面却不可以用“可控”衡量。随着用户量级的增加，产品在优先级的判定上面会有变化。通常来说，经验丰富的产品经理会预见这种变化并提前提出更加有益处的优先级概念，所以在优先级分析时，可以依赖数据分析做现实的需求分析，同时也要划拨资源尝试满足未来的产品方向。在确定了一个迭代周期的需求后，不可控的需求就要变成确定的需求，不然容易有生命危险，望珍重。
“敏捷开发就像走钢丝，四面八方都是用户需求，但只有产品逻辑才是那根钢丝，一个不小心，可能就掉进坑里。“ 做最好的产品，就一定要每一步都踩得准，走得快，过程可控。 欢迎各位关注，收藏，有关敏捷开发的内容我会持续更新，谢谢大家！
2015年10月28日
第二次更新，实操类技巧丨冲精品
敏捷更新阶段中产品应该怎么做？注意什么？
1、梳理产品需求（Product Backlog）
我们有提过，方向准这个原则。其中有一句话是：“在实现一个个最小可行产品前，一定要做子功能构架的规划。”
我们称这个规划为需求列表，通过需求列表定义出产品接下来要具备的特性和功能后，由一个产品负责人（Product Owner，简称PO）来定义这个产品需求，这时候需要遵循INVEST原则：
Independent 独立性
Negotiable 可协商
Valuable 有价值
Estimable 可预估
Small 足够小
Testable 被测试
定义优先级：价值/实现难度
这些都是制作需求列表时候应该注意的原则，在开展需求研讨会前，需要研讨的功能必须满足以上原则。接下来，为大家提供一种需求梳理办法，欢迎探讨。
注意：需求研讨会时，最有效的需求梳理方法！
在这一过程的实际操作中，我们可以使用斐波那契数列的纸牌游戏来完成评估。斐波那契数列又称黄金分割数列，其中每一项数字都等于前两项之和。0、1、1、2、3、5、8、13、21...
纸牌游戏操作过程：
需求研讨会前，罗列好要讨论的需求，买一套斐波那契数列纸牌。
1、发给每个人一副手牌。
2、提出一项功能需求。
3、拿出相应的数据资料。（可略）
4、每个人出牌，数值越大代表认可的优先级越高。
5、由分数最高的人阐述为什么需求这项功能，依次补充。（做好记录）
6、由分数最低的人阐述为什么不需求这项功能，依次补充。（做好记录）
7、再次出牌，记录总分。
8、提出下一项需求。
通过这个游戏，我们可以量化团队内成员对功能需求优先级的判断，对于需求研讨会而言，这样可以很好地吸纳他人对需求的判断。（是不是有点像狼人？）
大家有好的梳理方法可以回复讨论，欢迎建议。
2015年11月04日
第三次更新，有关敏捷核心方法论丨冲精品
感谢@方雅刚 的参与，在这期更新时，我将内容整理后，陈列如下：
1、个体与交互 重于 过程和工具
2、可用的软件 重于 完备的文档
3、客户协作 重于 合同谈判
4、响应变化 重于 遵循计划
《敏捷宣言》背后的12准则
我们遵循以下准则：
1、我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
2、欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
3、要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
4、项目过程中，业务人员与开发人员必须在一起工作。
5、要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
6、无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
7、可用的软件是衡量进度的主要指标。
8、敏捷过程提倡可持续的开发。项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
9、对技术的精益求精以及对设计的不断完善将提升敏捷性。
10、要做到简洁，即尽最大可能减少不必要的工作。这是一门艺术。
11、最佳的架构、需求和设计出自于自组织的团队。
12、团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
针对提出的运用方法的不同意见：敏捷项目管理非常注重人的管理和需求管理。
1、方向需要通过迭代慢慢摸清楚，这就特别强调个人和互动，需要互动频繁的精英团队。
2、敏捷是指可以给客户更早的带来价值，是价值驱动，快速迭代出来的无价值产品无效益。
3、敏捷项目的过程是相对可控的：
（1）不可控的地方在于不再像传统瀑布项目那样追求计划和文档，拥抱变化响应。
（2）可控的地方在于在每一个迭代中，项目的工作和交付物的“Done”都是可控的，在一个迭代中是不涉及随便改需求的。
我认为，在敏捷开发中，团队应该在满足敏捷宣言和准则的同时兼顾后者。
很多需要过渡期跟上市场变化的团队，应该在确定自己做什么、不做什么的基础上，深度挖掘一个或者几个方向相近、用户群相近的子项目，在资源有限的情况下找到一个点做透，验证用户需求，拥有较好的易用性，再做架构。敏捷开发就是深度挖掘、找到这个点的过程，找到这几个点后怎么运用，还是需要一定的方法与技巧的。
有关敏捷宣言和12准则可探讨的点，希望大家参与进来，回复讨论！感谢支持！?
如何更好地组合敏捷开发中拥有需求的子项目？
说到这里，我只能呵呵呵了。。。
一个好的功能就是用最小最轻的方式开发出来，比如语音功能最好就是一段字配个语音，不要管什么UI（架构、UE还是要管一管的），不要管什么识别精度、内容。前一阵我们工程师说，你这个功能我们根本做不到要求的那个精准度，我说那也做，收集数据就行，结果这个功能启用的频次很高，我们就通过一些手段（想辙+花钱）解决了精准度的问题，效果很好。做敏捷时候一定要知道啥最重要，你要的东西在未经过验证时候整个团队都会觉得然并卵，验证之后又觉得很有必要，这就是敏捷开发的作用所在，也就是为啥数据反馈这么重要的原因。
2392
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
