今天继续为大家更新《启示录-如何打造用户喜爱的产品》
第26章 合理运用敏捷方法
Succeeding with Agile Methods
十大秘诀
不少软件产品团队已经采纳了敏捷方法，有些正在尝试。尽管敏捷方法(包括Scrum和极限编程)有许多优点， 但这类方法源自定制软件(custom software) 领域，不完全适用于开发产品软件(product software)。许多产品团队历经磨难，才明白如何将敏捷方法应用到产品软件领域。
本章介绍在产品软件领域使用敏捷方法的诀窍。不了解敏捷方法的读者，请参考
注意这些诀窍只适用于产品软件团队，不适用于定制软件团队。
1.产品经理即是产品负责人(product owner)，他代表了客户的需求， 因而需要与产品开发团队保持密切的联系，协助督促开发进程，及时解决出现的问题。有些产品经理以为敏捷方法可以让工作变得轻松，这是大错特错的。如果产品经理和产品负责人不是由一个人担任，通常会埋下隐患(参见第2章)。
2. 使用敏捷方法绝不等于省略产品规划。产品经理仍然要明白产品的方向和目标，设定衡量产品成功与否的标准。只不过在敏捷环境里，规划周期应该适度缩短，反复迭代，采用轻量级的机会评估方法替代冗长的市场需求文档(参见第11章)。
3.产品经理和设计师的工作进度应该比开发团队领先一两个迭代周期，确保你们有足够的时间攻克难题。让交互设计师和视觉设计师提前设计产品，充分发挥他们主导设计的作用，不能一边设计一边开发(参见第19章)。另外，始终让开发人员参与评估产品设计和产品原型，及时反馈关于可行性、成本、解决方案的建议。
4.尽量把产品设计工作拆分成独立的部分，分而治之，但也不能拆得太细——好比设计建筑不能一次只设计一个房间。目标是设计出符合基本要求的产品(参见第20章)。值得注意的是，在敏捷环境里，设计师必须加快工作速度，采用迅速制作原型的方法更能适应敏捷环境。
5.产品经理的主要任务是定义有价值、可用的产品原型和用户故事(user story)，作为开发的基础。用产品原型和用户故事替代厚厚的产品需求文档和功能说明文档有三个优势：①可以请用户测试；②强迫产品经理全面认真地思考问题；③向开发团队明确地描述每次迭代周期需要完成的任务。请用户测试原型，根据反馈意见反复迭代修改原型设计，确保交给开发团队的是有价值的结果，避免任何浪费，哪怕只是一个迭代周期。
6. 让开发人员自主划分迭代周期。有的产品功能可以在一个迭代周期完成，有的却需要好几次迭代才能完成。好的原型可以提高估算工作量和开发时间的精度。 别忘了，开发团队必须考虑产品的质量、性能、扩展性，应该让他们自行决定如何划分迭代周期。
7.产品经理和交互设计师必须出席每天的晨会。晨会是一天沟通过程的开始，而不是结束，关于产品的讨论会持续一整天。设计师向开发人员和测试人员展示产品功能；开发人员互相展示完成的代码，让测试人员测试，请设计师和产品经理过目；测试人员和开发人员在制作原型的阶段识别潜在的问题，协助产品经理制定更合理的决策，解决产品设计、开发的问题。
8.除非达到了产品经理的要求，否则不要轻易发布新版本。产品经理必须确保交给用户的产品能正常运行。过度频繁更新版本会让用户感到不安(参见第24章)。
9. 在每次迭代完成后，产品经理应该向团队展示产品现状，以及下次迭代的产品原型，让大家看到工作成果，同时加深大家对产品的理解，增强团队对这种开发方式的信心。
10.在团队内展开敏捷培训。聘请敏捷顾问协助你们完成向敏捷团队转型的目标，但是要确保敏捷顾问有过类似的工作经验，理解产品软件与定制软件的差别。只有每位团队成员都真正理解敏捷方法，你才能把工作重心放在执行.上，否则敏捷方法就只能停留在教条式的理论层面。
问答解疑：迭代初期开发的产品能用做原型吗?
有些敏捷方法的倡导者和实践者认为开发团队可以把迭代初期开发的产品当做产品原型用。这种做法也许适用于定制软件，毕竟定制软件不需要我所说的产品管理，也少有用户体验设计，然而，这种做法对产品软件是行不通的，原因如下。
第一，用一个迭代周期来验证产品创意(通常存在缺陷)时间太长。花几个月时间验证生产中的产品与用几天时间验证可更改的产品原型相比，后者效率显然更高。
第二，在探索(定义)产品的阶段，开发团队还有许多重要的工作要完成。如果这时占用开发团队的时间开发产品原型，会消耗他们开发正式产品的精力。
第三，尽管敏捷方法鼓励开发团队不断学习，快速反应，可一旦进入开发阶段，设计出软件架构后，再想改变产品设计思路，对开发团队来说，无论是成本还是难度都太高了。
问答解疑：敏捷方法可以用来开发产品软件吗？
像Scrum这样的敏捷方法的确解决了许多困扰软件团队多年的问题， 但是多数产品经理、用户体验设计师、测试人员，对敏捷方法持怀疑态度，不确定自己应该扮演什么角色。毫无疑问，实施敏捷方法绝对离不开这些人，出现这种情况是因为“原始”的敏捷方法并不适用于研发产品软件。我发现解释敏捷方法的起源可以帮助人们理解它的适用范围。
敏捷方法的起源
Scrum于1986年诞生于日本，距今已有二十多年的历史，许多人对此感到惊讶不已(这又一次证明了，新观念要经过很长时间才能被人们广泛接受)。值得注意的是，这些方法起源于定制软件领域，而不是产品软件领域。
长久以来，开发定制软件困难重重原因之一是，虽然需求确实存在，但客户通常不知道自己想要什么。他们与软件公司签订合约，把自己的需求告诉开发人员，由开发人员自行开发。等到交付软件时，客户往往发现到手的软件和想象中的相差十万八千里，于是又要求开发人员修改，如此恶性循环，客户屡屡失望而归。但是由于刚性需求一直存在，所以开发人员、软件供应商、相关专业服务机构不必担心没有生意做。
另外，定制软件领域长期以来很难招聘/留住顶级的程序员。部分原因是顶级的程序员更喜欢为成千上万的用户开发产品软件，因而选择在产品软件公司工作。而且产品软件公司能提供更具竞争力的薪资待遇。产品软件公司必须开发出满足大众需求的产品，否则就得关门大吉，他们懂得只有用高薪吸引顶尖人才，推出优质的产品，才能获得高额利润。所以，多数资质普通的程序员留在了定制软件领域。
定制软件的客户认为自己了解自己的需求，所以不需要什么产品经理。他们也不需要用户体验设计师，这个原因更复杂，主要是客户不理解什么是用户体验(在定制软件领域几乎没人认识到用户体验的重要性)，以及对成本过于敏感(让开发人员设计产品可以节约成本)。另外，用户体验设计人才极度短缺也是不能忽视的原因，即便定制软件公司意识到用户体验的重要性，也很难招聘到合适的用户体验设计师，因为他们早就被当成“香饽饽”被少数几家大公司抢去了。同样，定制软件项目里也鲜见测试人员，本该由他们完成的测试工作都被开发人员包揽了。
定制软件的另一特点是大多数项目规模较小，一般用来支持公司内部运营，比如人力资源、财务、 生产系统，有限的用户数量使得可扩展性和性能表现通常不受重视。
以前，定制软件领域常使用瀑布式开发方法，这样做是为了便于客户监督漫长的开发过程。实际上，瀑布式开发方法也同样源于定制软件领域。
产品软件必须在各方面都尽量做到完美，才能贏得市场。所以必须由产品经理负责收集广大用户的需求；由用户体验设计师创造完美的用户体验；由测试人员测试产品，保证软件可以像广告里说的那样正常运行。
敏捷方法极大地提高了开发定制软件的效率：增进了客户和开发人员之间的交流；通过更频繁的迭代来大幅度降低风险(客户可以更早看到阶段性的产品，再不必等到整个开发过程结束)；引进了现代软件测试的理念；省去了撰写连篇累牍的产品说明文档的麻烦(这些文档实际上少有人阅读，很快就会被束之高阁) 。
我认为敏捷方法同样适用于产品软件的开发，但应用时应该做出相应的调整。我曾经写过相关文章(如何在开发过程中加入用户体验设计，如何管理产品的发布和部署)。敏捷方法唯一不适合产品软件开发的地方是在架构设计方面。敏捷方法鼓励开发人员不要拘泥于传统的开发流程，要相信简单重构和快速重新设计架构的优势。这对多数定制软件来说是可行的，但对产品软件系统(比如针对成千上万用户的大众网络服务)而言，这个想法就太天真了。
所以，产品软件团队使用敏捷方法时遇到问题不足为奇，主要是因为他们照搬了定制软件的敏捷模式。至今多数介绍敏捷方法的图书、文章、培训课程依然不涉及产品经理和用户体验设计师(交互设计师和视觉设计师)的作用， 因为它们针对的读者群还是定制软件团队。
要想成功转型成为敏捷开发团队，选一位合格的敏捷教练相当重要，他必须理解产品软件与定制软件的差别，了解产品软件的特殊需求，而这正是多数人不明白的。
更多资料可扫码关注“产品经理读书营”，百人产品经理手把手带你实现进阶。进群即可领取产品大礼包。
