【8044】敏捷开发方法

一句话评论:复习一下敏捷的12条原则,然后看看,Marty如何理解产品经理在“敏捷团队”里的角色定位。

Marty Cagan 发表于2009年6月1日,原文地址,译者:蒋彬 / 审校:周舜莉 徐定翔

许多产品开发机构都尝试过所谓的“敏捷软件开发”方法,其中最为流行的是“极限编程”(XP),此外还有其它一些敏捷方法,比如Crystal、Adaptive、Scrum和Pragmatic Programming等。
在使用这些敏捷方法时,产品经理常常弄不清自己的角色定位。有些产品经理甚至担心采用敏捷方法会影响产品质量。

我打算首先总结敏捷开发的核心原则,然后以极限编程(XP)​为例,指出极限编程的难点,以及如何更好地发挥它的作用。

敏捷方法一览

各种敏捷方法的要求千差万别,但是它们都遵循以下12条原则。​

1、最重要的是通过尽早地、频繁地交付有价值的软件来满足客户——尽早交付有价值的软件。

2、​频繁地交付可运行的软件,数周或者数月交付一次——频繁发布新版本。

3、可运行的软件是衡量进展的主要标准——软件比文档更重要

4、接受​需求变更,即便是在开发最后阶段——倾听,并快速学习

5、项目期间业务人员与开发者共同工作——紧密协作​

6、找积极主动的人来开发项目——为他们提供所需的环境和支持,相信他们能做好自己的工作

7、开发团队里最节省时间最有效的信息传递方式是面对面的交流

8、​自发组织的团队才能做出最好的架构、和设计——架构要敏捷,好主意无处不在

9、​持续关注先进的技术和优秀的设计能促进敏捷性——频繁地重构

10、​敏捷过程促进可持续的开发——此举应能维持相对稳健的节奏——而不是​导致失败

​11、简洁是一切的基础——少即是多

12、​团队定期反思如何提高效率,并调整​工作流程——事后反思​

极限编程概览​

要阐述​遵循敏捷方法到底意味着什么,​不妨看看敏捷方法中最为流行的极限编程的详细规范。该方法的发明者强调,极限编程并非万能,应该有选择性地加以使用。其主要原则如下。

-结对编程——两位程序员使用同一台电脑开发同一款软件

-简单设计——只设计和开发你现在就需要的东西,不考虑将来的潜在需求

-现场客户——客户代表入驻开发团队,他代表了所有产品的需求,在开发过程中不断的说明需求并帮助决策

-增量开发——频敏小规模发布产品​,快速推动产品​进入理想状态

-做好规划——工程师只做评估,客户决定​每次发布的功能和时间

-持续评审代码——基于结对编程的模式,两位开发者相互评审对方的工作

-持续测试——开发者在编码时就撰写单元测试,客户则撰写用例中规定的功能测试,​这些测试均是自动、持续地进行

-持续构建——持续开发和整合软件,这样能及早发现问题,系统也一直处于可构建的状态

-持续重构——软件开发人员不懈努力,通过重构代码来简化和改进工作,同时保证所有测试正常运行​

-代码共有——与每个开发人员“独享”​自己的代码这一模式不同的是,极限编辑模式中每个开发人员只要认为有机会有必要,就可以优化系统中任意处的任意代码​

-开放的工作场所——指整个团队都在一个在房间里共同工作,其中开发人员坐在中间

-每周工作40小时——限制加班以提高工作质量​

-代码即文档——最有用的文档就是软件本身,整个团队应该遵循编码规范

当然了,这种方法是从软件开发人员的角度提出来的。在他们看来,除了程序员和用户(客户),就不需要其他工作人员了。这正是让产品经理感受担忧的地方。​

产品经理的工作至少包含以下三个方面。​

定义产品

首先弄清楚要开发什么产品。极限编程方法是针对定制化软件项目提出来的,目的是满足特定客户的特定需求(比如内部员工薪资系统),它并不适用于通用产品。事实上,在描述极限编程方法的图书和文章里,几乎很少提及产品管理或是界面设计。

最让人担忧的通常产品经理能否代替现场客户的作用。只有在深入研究目标用户、理解用户需求、使用环境以及竞争格局,产品经理才能发挥最大的作用。

更让人担心的是产品设计(界面设计)角色的缺失。对于产品来说(不同于那些签署合同后开发的定制软件),用户界面和用户体验至关重要,需要专业设计师运用其专业技能进行设计,因此在工作流程中引入这一重要职位非常重要。

只要把最初的迭代作为持续演进的原型并不断检验,以确保开发团队能开发出正确的产品,然后再在接下来的迭代中实施产品执行,就能更好地利用极限编程方 法。关键是确保你开发的产品是客户想要购买的,而且客户能搞清楚该如何使用。只有一个客户或是产品经理理解这个产品并不足够,它应该为目标市场的广大群体 所检验。

开发产品

其次要考虑的是,​​这些用来开发可扩展、​高性能、可靠、易维护产品的技术会带来什么样的后果。这些担忧使人马上陷入一种近乎宗教狂热的争论,争论的重 点是,什么才是开发和测试软件的最佳方法,而这完全在产品管理职责之外。​产品经理​只需要清晰地确定需求,然后让技术团队按自己认为最合适的方式来控制 风险。​

极限编程过程依靠客户来定义用例(又被称为用户故事)​,以此作为功能测试的基础。这用在小型项目上或许还不错​,但如果是大型、通用产品的话,有必要请 专人来负责设计必要的测试用例,以确保可扩展性、功能、性能、容错性和本地化特性等。这些通常都是QA的职责,极限编程的方法完全也可以借鉴。关键是让开 发人员负责单元测试,QA人员负责其它测试(比如系统、集成和功能测试等)​。​

部署产品

最后一个为人们所关注的,是产品的发布。人们长期以来一直认为随着时间的推移,做出改变的成本也越来越高,但极限编程挑战了这一看法。换言之,只要遵循极 限编程实践,你可以降低开发中系统需要变更带来的影响。这对于定制化软件来说这没错,但对于许多商业软件产品来说,变更带来的影响仍然很大,尤其是对于拥 有大量活跃用户群体的互联网服务来说。

我曾经探讨过“平滑部署”的​策略,这些方法有助于降低极限编程项目所提倡的频繁发布和更新策略所带来的负面影响。

​总结

大到敏捷开发,小到极限编程方法,都是为了解决传统软件开发方法中的实际问题而创造的,尤其是致力于增强开发人员与客户的沟通,节省时间及早弄清楚你所开发的产品是否正是客户需要的,并减少增量开发过程中的风险,同时优先开发高优化级的功能。此外还有另外一些颇有价值的技术,尤其是结对编程、增量开发、持 续集成与自动化测试等。​

​然而,对于提供商用产品及服务的公司来说,更重要的是将这些方法与产品管理、产品设计、质量保证结合起来,确保你开发的产品能为广大用户和消费者使用。这样的话才能覆盖较广的消费者群体。

本文节选自《启示录:打造用户喜爱的产品》作者Marty Cagan的博客。该书从人员、流程、产品三个角度介绍了现代软件(互联网)产品管理的实践经验和理念。特此感谢Marty Cagan先生授权。

【8043】产品原则和产品评审团

本文选自《程序员》杂志2012年04期@七印部落 翻译。

文 / Marty Cagan  译 / 黄捷文,唐丰能

Marty Cagan是享有世界声誉的产品管理专家,曾经担任网景副总裁、eBay产品管理及设计高级副总裁。本文是他回顾自己二十多年来从事软件产品管理工作的总结和经验分享,描述了产品开发需要遵循的产品原则以及成立产品评审团的必要性。

产品原则

产品原则是对团队信仰和价值观的总结,用来指导产品团队作出正确的决策和取舍。它体现了产品团队的目标和愿景,是产品战略的重要组成部分。从形式上看,它是一系列明确的、体现团队特色的产品价值准则。

每次加入新团队,我要做的第一件事都是制定产品原则。这意味着要决定什么重要、什么不重要,哪些原则是根本的、战略性的,哪些是临时的、战术性的。

产品原则不是产品功能的清单,不依赖于任何单独的产品,而是整个产品线的战略指南和公司的价值宣言。好的产品原则还可以激发设计产品的灵感。制定产 品原则的过程也是学习的过程,可以从中了解新公司的企业文化,以及公司创始人设立的企业目标。产品原则是一套价值判断的框架,帮助公司作出正确的决策。

举例来说,某电影网站的产品原则是相信社区用户的影评比专业人士的影评更有价值。当某家制片厂想借网站发表评论时,产品团队就可以根据这条产品原则 决定是否采纳。产品原则是否公开因公司而异。它既可以用做团队内部的指导工具,如产品战略文档,也可以公开给客户、合作伙伴、投资人,用于向公众宣传公司 的理念。此外,产品原则还可以用来团结产品团队,让产品经理、产品设计师、开发团队和营销团队形成共同的价值观,在认识上保持一致。这是任何产品说明文档 都做不到的。注意,只罗列出产品原则还不够,还要按原则的重要性排序。所有产品都要既易于使用又安全可靠,但总有需要优先考虑的原则。最重要的究竟是易用 性,还是可靠性?

制定产品原则时,容易出现以下两类错误。

  • 原则过于空泛,失去了指导作用。
  • 把设计原则误当成产品原则。比如,为用户提供清晰的导航路径(方便用户完成下一步操作)属于常见的设计原则,不是产品原则。

如果你所在的团队还没有制定清晰的、有关产品理念的产品原则,那么应该把大家召集起来,花点时间来讨论分析,确定团队最看重的价值理念。

解决意见冲突

不少产品经理向我抱怨,他们受够了没完没了的会议(既无议程也无结果),以及会议中的那些争论和冲突。公司高管还时不时打断会议进程,扔下没头没脑的意见,拂袖而去,留下他们丈二和尚摸不着头脑。

这种情况在产品决策过程中经常发生,原因主要有以下几点。

  • 每位同事对产品都有自己的看法。
  • 大家都非常在乎产品,明白公司盈利得靠用户,只有产品才能吸引用户。
  • 许多人以为自己比其他人了解目标用户,事实上并非如此。

另外,产品团队大多不必向产品经理汇报工作,产品经理没有管理产品团队的实权。在需要产品团队的配合时,产品经理只能摆事实、讲道理,不能强制执行。所以产品经理总觉得施展不开拳脚,非常沮丧。

有时大家各持己见,僵持不下,只能请高管出面定夺。出现这种局面,说明沟通方式有问题。产品创意在辩论中可以得到完善,但前提是大家形成一致意见。请高管出面决策、解决冲突会激化团队内部矛盾,得不偿失。

制定产品决策的过程中存在的困难着实不少,且是不可避免的,因为建设性的辩论和论证是定义优秀产品的必由之路。不过即使认识到这一点,我也很难把争论当成一种享受。

为了鼓励创新,改善讨论效果,同时降低外界干扰,在作产品决策之前,应该先确定决策要解决什么问题,让大家在以下几个要点上达成共识。

  • 究竟要解决什么问题?
  • 要为哪类人物角色解决这个问题?
  • 产品要达到什么目标?
  • 每项目标的优先级是什么?

继续阅读【8043】产品原则和产品评审团