01 5月

我们需要计划,但需要评估吗?

文 / Johanna Rothman:帮助管理人员和团队解决问题并交付产品。她最近的一本著作是Manage your Project Portfolio: Increase Your Capacity and Finish More Projects。你还可以在jrothman.com阅读博文及她的著作。

原文链接:http://java.dzone.com/articles/we-need-planning-do-we-need?mz=123873-agile

我在撰写项目管理著作的过程中,领教了对大量的工作进行评估的难处。

Essays on EstimationManage It这两本书中,我推荐了几种评估方法,每种方法都表明,对于一个工程或项目,不存在一个绝对的计划日期。

你能做些什么呢?有下面几种选择:

  1. 计划和再计划。要决定对当前的工程或项目投资多少。请参见(图示中)工程/项目进展。还要决定你打算对工程/项目投资多久。
  2. 按照预定日期工作。如果你以迭代的方式或增量的方式进行开发,预定日期就最合适不过了。如果经常有内部版本发布的话,你可以看到工程/项目的进展和重新制定的计划(如果使用瀑布模型进行开发的话,就不太可能满足你想要的所有功能,也无法避免不想看到的缺陷。而如果你以迭代或增量的方式开发的话,就可以按照要达到的目标去完善计划。注意,我说的是完善计划,而不是评估计划)。
  3. 对三种不同情况的评估:任何事情都顺利的情况,正常情况和最不利的情况。这是著名的PERT(计划评审技术,Program Evaluation an Review Technique)估计。
  4. 用百分比给所做的评估一个信心值。你认为在某个特定日期前后能够发布,那么对这个评估有几分把握?这种情况再计划一下最好不过了,那样你可以更新信心值了。

这里的每一项表明所做的计划带有不确定性。工程或项目规模越大,表现出的不确定性明显。

如果你使用敏捷(agile)方法的话,可能根本就不需要进行评估。这些年来,我管理了许多工程和项目。从来没有人过问项目的成本和对进度的评估。有时候只是告诉我那些预期目标,那些目标是如此地乐观,以至于我不得不对其进行总体的评估(gross estimate),用来解释为什么不能满足这个日期要求。

然而,除了总体的评估外,我并不相信其他方式。我相信敏捷方法的路线图(roadmap)。建立项目迭代增量,观察项目进度,并且可以决定下一步做什么,这都是不错的点子。

RoadMapForProduct

当你看到这幅路线图的时候,就会了解每个月如何为内部版本做计划了。

对于内部版本,每一个人都可以看到工程或项目的进度。

另外,我们按季度发布的外部版本。此时你的工程或项目也许无法按季度向客户发布。但这应该是商务上的决定,而不是由你决定的,因为此时工程或项目未达到预期标准而不能发布。如果你没有采用敏捷方法推进项目的话,可能就无法按季度发布。但我姑且认为你会用敏捷方法进行开发的。

AgileRoadmapForProduct
在单季度的视图中,你可以看到“最简可行产品”(Minimum Viable Product, MVP)。

在这里,特别是在项目的开端。你可能需要将MVP换成MIFS(Minimum Indispensable Feature Set)。

如果总是出现这么小的“Story”的话,那就可以统计他们的数量,而不是评估这些“Story”,这样做会更加接近事实。特别是在项目初期,你就不用花时间去评估,也就不用开发相应的产品。

在工程或项目的初期,你对于存在的风险和陷阱了解得最少,甚至连MVP和MIFS都不了解。但是,如果肯向用户发布一些东西,你就可以得到自己所需的反馈。

反馈会告诉你什么:

  • 这些“Story”是否数量太多而无法统计?如果是这样的话,你创建的任何评估就都是错误的。
  • 是否提交了有价值的工作?如果是这样的话,公司将会对此继续进行投资。
  • 是否正在为最具价值的任务工作成果?在工程/项目进行的过程中,其价值所在会发生变化。有时你实现此功能可能在价值上逊色于彼功能。有的时候,你会意识到你正在实现的功能其实已经被实现了。
  • 是否要停下来?如果我们提前完成了项目发布的要求,那很棒!如果还没有做好发布的准备,我们要做些什么呢?

这都是我做评估的心得体会。如果你只拿出一套评估方案,那些经理是不会相信你的。他们会向你施压,说些“少花钱多办事”那样不合常理的话。他们会这样讲:“如果我们裁掉测试的话,你可以进度更快,对吗”?(对此类言论的回应是:“NO!在技术层面所亏欠或产生的债务越少,我们才能进行得越快”。)

但是你确实需要对项目的路线图做规划,包括所积压的工作。如果没有一个路线图,展示人们所期待的东西,这些人就不会相信你,觉得你很假。由于团队所提交的内容并不是每一项都是产品负责人期待的东西,因此你要重新计划路线图。不过没关系的,尽早从反馈中得知团队力所能及之事就很赞。

向要求做评估的人提出的两个问题:

  1. 在团队停下来之前,你愿意为这个工程/计划投入多少资金?
  2. 这个工程/项目对你有多大价值?

如果你为最有价值的工程/项目工作,那还做什么评估呢?你需要了解的是在项目进行中公司打算在这个项目上投多少资金。如果所做的不是最有价值的工程/项目,你也要知道公司打算对其投资多少。或者你要有一个预定日期,有了这个日期,你可以用迭代法或增量法逐步发布版本,直到完成目标。

这就是对评估的风险管理,还有再计划。没错儿,我就是一位“0评估”粉丝,因为我们划分的粒度越小,就越容易明白如何进行计划和再计划。

我们需要计划和再计划。如果使用迭代法和增量法的话,我认为不需要事无巨细的评估。

29 3月

敏捷已死,敏捷性万岁

文 / Dave Thomas:敏捷软件开发宣言创始人之一,《程序员修炼之道》与《Programming Ruby》的作者。

译 / 白云鹏

原文链接:http://pragdave.me/blog/2014/03/04/time-to-kill-agile/

十三年前,为了分享共同的软件开发理念,我们十七位中年人聚集在犹他州的滑雪胜地雪鸟(Snowbird)雪场。我们想知道是否能把这些理念描述出来。

用了不到一天的时间,我们将这些理念简单罗列,作为敏捷软件开发宣言(Manifesto for Agile Software Development)将其公布:

个体与交互胜于流程和工具

可用的软件胜于详尽的文档

客户合作胜于合同谈判

响应变化胜于遵循计划

我为我们的所作所为感到自豪。我想这个宣言可以帮助开发者摆脱一些八九十年代出现的不良做法。

这次会议以后,我就再也没参加过任何关于敏捷的活动,也不是敏捷联盟的成员,也不做任何“敏捷”咨询业务。也没有参加宣言发表10周年庆祝活动。

这是为什么呢?因为我觉得任何这些事情都不符合我们所发表宣言的精神,有关敏捷的会议与芭蕾舞会没什么两样,并且让我吃惊的是,围绕宣言的四点形成了一个产业群。

遗憾的是,事实证明了我是对的。“敏捷”这个词已经到了被颠覆的地步,敏捷社区看起来像是顾问和商家兜售服务和产品的大舞台。

所以“敏捷”这个词该下课了。

“敏捷”不应该是名词,而应该是一个形容词,它有其相应的含义。

一旦宣言走红,就像环保和天然一样,敏捷这个词就会变成营销术语。因为它变成了一种品牌,会被滥用而失去原有的含义。

这伤害的是每个人,我则对开发者的伤害尤其敏感。敏捷不是简单地编写代码,而是开发者本能地寻求可以帮助他们更有效创造价值的方法。我则仍然坚信,信守这个宣言会有意于开发者。

而一旦敏捷这个词变了味儿,开发者就不会再用它作为实践中的有效指南了。

转向右边

我们再来看看宣言中的四项理念:

个体与交互胜于流程和工具

可用的软件胜于详尽的文档

客户合作胜于合同谈判

响应变化胜于遵循计划

左边的短语代表理想,左右之间选择,敏捷软件开发者则偏爱左边。

从顾问和商家那里看到的则是“敏捷”这个词的贬值和滥用。当然,对于一些顾问,事实可能也不尽然。

回归根本

下面是敏捷方法应该做的事情:

做什么?

  • 找到问题
  • 朝着自己的目标迈出一小步
  • 基于获取的信息,调整自己的认识
  • 重复上述步骤

如何做?

当面对两个类似的选项时,选择容易修改的那个。

上面的四条准则和一项实践原则概括了高效的软件开发方法。

这些准则和原则都是动词短语,它们告诉了我们做什么,如何做。

我也要说两句。让我们摒弃没有敏捷精神的说法,换成一个描述我们应该做哪些事情的词语。

让开发带有敏捷性

你不是一位敏捷程序员,而你是一位具有敏捷性的程序员。 你所在的团队不是敏捷团队,而你的团队显露出敏捷性。 你不使用敏捷工具,而你使用工具增强自己的敏捷性

敏捷这个词很容易联系任何事物,而敏捷性则不容易被挪用。

你不能购买经验,只能自己去实践。

让付出得到保护

总之,行胜于言,但好的称谓有助于高效沟通。

我们已经失去了敏捷。让我们守住敏捷性,让它保持原本的含义。