天机不可泄漏 » Project Management

敏捷就不能山寨吗

Allen — Fri, 20 Feb 2009 16:17:44 +0000

最近关于敏捷的的讨论很是热闹(1,2)，要是各位专家不常常出来讨论一下，我都快忘记敏捷这个词了。

看了各位大牛和专家的讨论，特别赞同Martin Fowler说的：……it isn’t methodologies that succeed or fail, it’s teams that succeed or fail. 所谓事在人为（见《伟大的软件要靠伟大的团队》，《敏捷团队建设》），就是看你做不做，当然要挑符合实际情况的最佳实践来做。

所以，接下去我要把敏捷“山寨”一下，找到适合自己的敏捷方法，然后不断改进（这点上很符合迭代的要求嘛），用敏捷的理念来指导敏捷实践。

比如：一个团队刚刚接触敏捷开发，结对编程的门槛可能有些高，但每天的立会、程序员参与对需求的估计相对来讲要求低一些，也能达到敏捷的目的，就可以先实施。甚至我觉得结对编程不是很适合“中国国情”，因为中国的程序员相对比较内敛，不善于表达，习惯得到任务后直接完成，不会像国外的员工喜欢问为什么，要把整个流程问清楚。这也是我欣赏敏捷的原因之一，程序员（人）在敏捷实践的过程中需要更多的交流，更加符合人性。（人之所以有丰富的表情，就是表达用的，我认为表达欲是人性）

好，哪些实践是敏捷的呢？我们先来看《检验团队是否敏捷的四个标准》

是否执行了单元测试？如果你不是以回归的方式执行单元测试，你就不是敏捷的。
是否将项目客户引入开发团队？你是否建立一种交流机制，要求每天或者一周几次的与你的客户进行交流？
你正在开发的软件是否是可工作的（working software）？我希望看到可工作的软件演示，它的配置版本。是否有团队之外的人员在每周都看到你所开发的软件？
开发团队是否是自组织（self-organization）的？也就是说，团队对于项目是否具有控制权。自组织并不意味着毫无限制，但对于项目的一些重要事情应该具有决定的权利。

太好了！我先自我检查一下：单元测试我倒是用，但没有迭代的用，以后望改进。其余的3项，不折不扣可以帮助到项目顺利进行，在项目遇到困难（block）的时候，更是很让客户理解项目遇到的问题，说到底还是“沟通”。

我们再看一下去年VersionOne发布的一份报告。报告中显示，在调查的团队中，实践敏捷方法的，迭代计划86%，单元测试77%，每日立会75%，持续集成72%，……结对编程31%。

好极了，我们的“山寨”敏捷就从迭代计划、单元测试、每日立会、持续集成开始吧！当然我们需要一些特别的工具来帮助我们做迭代计划（我觉得Story Card太浪费纸张了）；用*Unit来做单元测试；大白板做每日立会；*Ant做持续集成，等等……内容很多，每个人的选择不一样。

最后，我没搞明白Scrum、XP啥关系，只知道两者的共同点就是迭代，Scrum大方向上要迭代计划、迭代开发；XP在技术层面上要小规模签入、单元测试、每日集成。我只知道它们都叫“敏捷”，以区别传统的瀑布。如果理解有不对的地方，还请您赐教。

也许你还会喜欢

进度计划风险的完整列表

Allen — Fri, 18 Jul 2008 01:40:28 +0000

计划编制风险
1. 计划、资源和产品定义全凭客户或上层领导口头指令，并且不完全一致。
2. 计划是优化的，是“最佳状态”（但不现实，只能算是“期望状态”）。
3. 计划忽略了必要的任务。
4. 计划基于使用特定的小组成员，而那个小组成员其实指望不上。
5. 在限定的时间内无法建成已定规模大小的产品。
6. 产品规模比估计的要大（代码行数、功能点、与前一产品规模的百分比）。
7. 工作量大与估算数（按代码行数、功能点、模块等）。
8. 进度已经拖延的项目在重新估计时过于优化或忽视项目历史。
9. 过度的进度压力造成生产率下降。
10. 目标日期提前，但没有相应地调整产品范围或可用资源。
11. 一个任务的延迟导致相关任务的连锁反应。
12. 涉足不熟悉的产品领域，花费在设计和实现上的时间比预期的要多。
组织和管理
1. 项目缺乏一个有凝聚力的最高领导人。
2. 由于前期乏力，项目长时间被搁置。
3. 解雇和削减开支导致项目小组能力下降。
4. 仅有管理层或市场人员进行技术决策，导致计划进度延长。
5. 低效的项目组织结构降低生产率。
6. 管理层审查、决策的周期比预期时间长。
7. 预算削减打乱项目计划。
8. 管理层做出了打击项目组织积极性的决定。
9. 非技术的第三方的工作比预期延长（预算批准，设备采购批准、法律方面的审查、安全保证等）。
10. 计划性太差，无法适应期望的开发速度。
11. 项目计划由于压力而放弃，导致开发混乱，低效。
12. 管理层强调英雄主义，而忽视客观确切的状态报告，这会降低发现和改正问题的能力。
开发环境
1. 设施没有及时到位。
2. 设施到位，但不配套（如没有电话、网线、家具、办公用品等）。
3. 设施拥挤、杂乱或者破损。
4. 开发工具未能及时到位。
5. 开发工具不能期望地那样有效，开发人员需要时间创建工作环境或者切换新的工具。
6. 开发工具的选择不是基于技术需求，不能提供计划要求的性能。
7. 新开发工具的学习期比预期的长，内容繁多。
最终用户
1. 最终用户坚持新的需求。
2. 最终用户对于最后交付的产品不满意，要求重新设计和重做。
3. 最终用户不买进项目产品，无法提供后续支持。
4. 最终用户的意见未被采纳，造成产品最终无法满足用户期望，而必须重做。
客户
1. 客户坚持新的需求。
2. 客户对规划、原型和规格的审核/决策周期要比预期的要厂。
3. 客户没有或不能参与规划、原型和规格阶段的审核，导致需求不稳定和耗时的变更。
4. 客户答复的时间比预期长（如回答或澄清需求相关问题的时间）。
5. 客户坚持技术决策而导致进度计划延长。
6. 客户对开发进度管理过细，导致实际进展变慢。
7. 客户提供的组件无法与开发的产品匹配，导致额外的设计和集成工作。
8. 客户提供的组件质量欠佳，导致额外的测试、设计和集成工作，以及额外的客户关系管理工作。
9. 客户要求的支持工具和环境不兼容、性能差或者功能不完善，导致生产率降低。
承包商
1. 承包商没有按承诺交付组件。
2. 承包商递交的组件质量低下无法接收，必须花时间改进质量。
3. 承包商没有买进项目开发需要的工具，进而无法提供需要的性能水平。
需求
1. 需求已经成为项目基准，但变化还在继续。
2. 需求定义欠佳，而进一步的定义会扩展项目范畴。
3. 添加额外的需求。
4. 产品定义含混的部分比预期需要更多的时间。
产品
1. 错误发生率高的木偶快需要比预期更多的测试、设计和实现工作。
2. 校正质量低下不可接受的产品，需要比预期更多的测试、设计和实现工作。
3. 在一个或多个新兴领域推广计算机技术使得计划进度的延长不可预期。
4. 由于软件功能的错误，需要重新设计和实现。
5. 开发额外不需要的功能（镀金）延长了计划进度。
6. 要满足产品规模与速度要求，需要比预期更多的时间，包括重新设计和实现的时间。
7. 严格要求与现有系统兼容，需要进行比预期更多的测试、设计和实现工作。
8. 要求与其他系统、其他复杂系统或不受本项目组控制的系统相连，导致无法预料的设计、实现和测试工作。
9. 要求在不同操作系统下运行将花费比预期更长的时间。
10. 在不熟悉或未经检验的软件、硬件环境中运行产生未预料到的问题。
11. 开发一种对组织全新的模块将比预期花费更长时间。
12. 依赖正在开发中的技术将延长计划进度。
外部环境
1. 产品依赖政府规章，而规章的改变将是不可预期的。
2. 产品依赖草拟中的技术标准，而最后的标准将是不可预期的。
人员
1. 招聘人员所花时间比预期的长。
2. 最为先决条件的任务不能按时完成（如培训、其他项目的完成、工作许可证）。
3. 开发人员和管理层之间关系不佳导致决策缓慢，影响全局。
4. 项目组成员没有全身心投入项目，进而无法达到需要的产品性能水平。
5. 缺乏激励措施，士气低下，降低了生产能力。
6. 缺乏必要的规范，增加了工作失误与重复工作。
7. 某些人需要更多时间适应不熟悉的软件工具和环境、硬件环境、编程语言。
8. 项目结束前，人员离开团队。
9. 项目后期加入新的开发人员，额外的培训和沟通降低现有成员的效率
10. 项目组成员不能有效地一起工作。
11. 由于项目组成员间的冲突，导致沟通不畅、设计不佳、接口错误和额外的重复工作。
12. 有问题的成员没有调离项目组，损害了项目组其他成员的积极性。
13. 项目的最佳人选未能加入项目组。
14. 项目的最佳人员已加入项目组，但因政治或其他原因未能合理使用。
15. 没有找到项目急需的具有特定技能的人。
16. 关键任务只能兼职参与。
17. 项目人员不足。
18. 任务的分配与人员技能不匹配。
19. 人员工作的进展比预期的慢。
20. 项目管理人员怠工导致计划和进度失效。
21. 技术人员怠工导致工作遗漏或质量低下，工作需要重做。
设计和实现
1. 设计过于简单，无法确定主要事件，并导致重新设计和实现。
2. 设计过于复杂，导致一些不必要工作，影响实现效率。
3. 设计质量低下，导致重复设计和实现。
4. 使用不熟悉的方法，导致额外的培训时间，并重犯前期使用这种方法时导致的错误。
5. 产品采用低级语言来实施（如汇编），导致生产率比预期的低。
6. 一些必要的功能无法使用现有的代码和库实现，开发人员必须使用新的库或者自行开发所要的功能。
7. 代码和库质量低下，导致需要额外的测试、错误修正或重做。
8. 过高估计了增强型工具对计划进度的节省量。
9. 分别开发的模块无法有效集成，需要重新设计或重做。
过程

大量的纸面给偶工作导致进程比预期的慢。
进程跟踪不准确，导致无法预知项目是否已落后于计划进度。
前期的质量保证行为不真实，导致后期的重复工作。
质量跟踪不准确，导致无法得知影响进度的质量问题。
太不正规（缺乏对软件开发策略的标准的遵循），导致沟通不足，质量问题和工作重做。
过于正规（教条地坚持软件开发策略和标准），导致过多耗时无用的工作。
向管理层撰写进程报告占用开发人员的时间比预期的多。
风险管理粗心，导致没有发现重大的项目风险。
软件项目风险管理花费的时间比预期的多。

也许你还会喜欢

敏捷生命周期跟踪工具

Allen — Sat, 26 Apr 2008 11:51:58 +0000

工欲善其事，必先利其器。孔子告诉子贡，一个做手艺或工艺的人，要想把工作完成，做得完善，应该先把工具准备好。

自认为，敏捷开发对参与的人员要求都太高，如果对敏捷没有一点概念，其实实施会遇到很大的难度。我们大都不是布道者，也许也不善于布道。我们需要的只是一些工具，能够帮助我们对软件开发的生命周期进行管理，让团队的参与者有据可循。

Mingle 2.0

排在第一个介绍的是Mingle，因为个人对ThoughtWorks的关注，或者说是她的首席科学家是Martin Fowler，让我感到那是能够胜任“布道”的公司，自然对她提供的工具投入更加多的关注。

Mingle是一个项目协作和管理的工具，为整个团队提供了一个共享的工作台。它能帮助你收集Story, Bug等，并且将他们组织起来，同时还提供你需要的Wiki，图表等等功能。

我曾经使用过Mingle的上一个版本，不知道是不是运行在jRuby上的原因，它在效率上的表现影响到我继续使用它，当时机器的配置情况是：Celeron D 3G，2GB RAM，Windows XP SP2。

你可以免费使用30天，30天以后，5人以下团队免费。

更多信息请关注Mingle2.0官网｜注册下载Mingle2.0

XPlanner

同样的，XPlanner也是一个基于web的极限编程的团队计划和跟踪工具。XPlanner的特点非常的明显：简单的模型、开源、免费、图表输出，简单甚至说粗糙的界面下是强大的功能，它能提供图表的输出、SOAP接口、多语言支持。

XPlanner虽然是JSP的程序，但配置在windows的平台上一点都不麻烦，我曾经就发出这样的感叹：“这样就可以运行了吗？”。它所有的数据都是存储在脚本中。每一次系统重新运行，都会需要一点时间，将历史数据Insert到MySQL中。

更多信息请关注XPlanner官网｜下载XPlanner页面。

VersionOne

曾经３次获得Jolt大奖。VersionOne提供了4种敏捷模型的支持：XP, Scrum, DSDM, Agile UP. 相比前面介绍的2款工具，VersionOne提供了更加强大的功能，它能够导出N多种的报表和图表，在用户体验方面做的也很出色，它提供了很多快捷键，方便使用者能够快速的进行项目内容的调整，它还使用了AJAX技术，让使用者感到好像在使用桌面应用程序一般。

另外VersionOne在不同敏捷模型间切换也非常的方便，只要重新运行一下安装程序，选择你需要切换到的模型即可，不会造成任何数据的丢失。不过在我看来，不同模型的切换在VersionOne中只是名词的改变罢了，比如在Story和Issue就是一样东西；Iteration和Sprint是一个玩意儿。

VersionOne基于ASP.NET，可以使用SQL SERVER 2005 Expression作为数据库。VersionOne在5人以下的团队是免费的。

更多信息请关注VersionOne官网｜下载VersionOne页面

Trichord

Trichord是我在InfoQ上，看到的一篇关于“看板图”介绍的文章中提到的一个工具，是一个日本人开发的敏捷工具，基于Eclipse的界面，很多人应该不会陌生。它的特点是很有趣，在使用的过程当中就像真正在使用看板一样。它的名字很有趣TRI指的是三种视角（时间、任务和团队），CHORD则是和谐的意思。

我在使用Trichord的过程中发现，看板固然有趣，但是如果你屏幕不是很大的话，还是比较痛苦的，至少一个列表能显示更加多的内容。

另外，它还提供了一个很有趣的功能：表情日历。

Trichord提供2种授权模式：一个是evaluation，你可以免费使用evaluation license 30天。另外一个是免费版本，但是免费版本只提供一个用户帐号并且只能有50张故事卡片，是不是很不爽？

更多Trichord信息请关注Trichord官网 | 下载Trichord

也许你还会喜欢

Flash Application开发手记

Allen — Sat, 19 Apr 2008 03:10:21 +0000

最近的一个Flash项目，很累很痛苦。

Flash Application和Web Application的人员差别

差别最大的地方在于，Flash Application中，美工人员的参与度要比Web Application中的美工人员参与度要大很多。原因在于，美工人员能比较容易的在Flash中制作出一个特效，比如淡进淡出的效果，而在Web中利用Javascript制作一个淡进淡出的效果并没有想象当中那么容易。

就是这个小差别，就会给项目管理上带来不同的体验。好比，你的部队中拥有不同特性的兵种，有的是血牛，有的是远程部队，有的是魔法部队，这么一个团队，在指挥上一定比全是血牛的部队相比费劲很多。

做好版本管理

fla不是文本文件，所以最好不要多人签出编辑，因为这样不能合并(Merge)。
充分利用Action Script 3种面对对象的特性，组织好你的Action Script文件。

使用Action Script 3

下面有几个理由去使用Action Script 3

Action Script 3提供了完好的面对对象方案，有了命名空间。
支持了ECMAScript for XML (E4X)，使用XML更加方便。
更加统一的事件处理模型。
更加纯正的时间类。

善用工具

Flash CS3，Flash美工方面没的挑。
就算不开发Flex，也推荐使用Flex Builder。

欢迎有同样经验的同志补充。

也许你还会喜欢

《最后期限》整理

Allen — Wed, 16 Apr 2008 10:00:36 +0000

作者：汤姆·迪马可 (Tom DeMarco)，同作者作品有《人件》、《与熊共舞》。

译者: UML / China翻译组

页数: 306

出版社: 清华大学出版社

出版年: 2003-1-1

《最后期限》用一个虚构的故事阐述了项目管理中的一些原则。汤普金斯先生是书中一位资深的项目经理，书中以第三人称的角度描述汤普金斯先生这一段特殊的经历，让你在阅读项目管理书籍的同时，如同阅读轻松的小说一样。每一章的最后以汤普金斯先生的日记作为结尾。以下是我在阅读过程当中的一些摘录，并不包含书中的所有章节。

也许你还会喜欢

汤普金斯先生的日记——精兵简政

Allen — Tue, 15 Apr 2008 12:00:59 +0000

对于汤普金斯先生来说，今天是个好日子，不仅项目组成功交付了产品，而且他所在的国家上市了（他的国家就是一个专门制造软件的国家，第一个上市交易的国家-。-），汤普金斯先生拥有5万股，股票的发行价会是14美元，而且一天之后会涨到20甚至是25美元，而且汤普金斯先生决定离开这个国家，去享受这笔飞来横财。

但是这个时候汤普金斯先生收到一同国际长途，电话的另外一头是这个国家的国际事务部的部长，一个专横的人物，他告诉汤普金斯先生，他要实行裁员减薪，而汤普金斯先生的想法正好相反。总之，汤普金斯先生没有功夫与这位令人讨厌的国际事务部部长周旋了。他挂掉了电话，拿起日记本。

精兵简政：

精兵简政是失败的公司使用的办法。它让员工负担失败的责任。
公司的目标应该正好相反：兴旺而人性化。
当你听到“精兵简政”这个词的时候，请记住它的弦外之音：失败
和恐吓。

也许你还会喜欢

汤普金斯先生的日记——项目社会学

Allen — Mon, 14 Apr 2008 13:00:52 +0000

还记得上次的那份成绩单吗？汤普金斯先生打算亲自去看看A团队。正巧，A团队正在举行一个会议，出席会议的人数总共有31人，当汤普金斯先生旁观会议的时候，整个会议已经举行6天了。

汤普金斯先生最后做出一个决定：让会议尽量短，精简参与的人数，缩短会议的时间，并且所有人都知道会议的议程。

最后，汤普金斯先生决定休会，并且为下一次的会议精心准备议程。

项目社会学：

让不必与会的人可以放心离开，从而保证会议的精简。有一份公开
的议程，并严格执行，这是最简单的办法。
项目需要仪式。
用小小的仪式来使人们注意项目的目标和理想状态：小规模会议、
零缺陷工作等等。
采取行动，防止人们随便发怒
记住：愤怒=恐惧。随便对下级发怒的经理一定是因为恐惧才会这样
做的。
意见：如果所有人都懂得“愤怒=恐惧”这个道理，就能明显地看出
发怒的人是在害怕。由于无法再隐瞒自己的恐惧，他也就不会再生
气了。（这不能解决这些生气的人的问题，但是肯定可以让其他人
好受一些。）

也许你还会喜欢

汤普金斯先生的日记——人员安排

Allen — Sat, 05 Apr 2008 10:00:17 +0000

今天汤普金斯先生收到了一张成绩单，如下

产品	A团队	B团队	C团队
Notate	F	A	A
PMill	F	A	A
Paint.It	F	A	B
PShov	F	A	A
Quirk	F	B	A
QuiekerStill	C	A	A

如同常规的，A表示最佳，说明已有设计方案。F表示最次，说明只有行政文档。

如果你还记得在“汤普金斯先生的日记——前传”中记载的，对3个团队的描述的：

A团队——人员过量

B团队——人员不足

C团队——人数最合适

汤普金斯先生面对着一份成绩表陷入了思考，沉思过后，他在他的日记中写下如下文字。

人员安排

在早期，人员超编会迫使项目跨过关键的设计阶段（这是为了让
所有的人有事可做）。
如果在设计完成之前，工作先被分给了很多人，那么人与人之间、
工作组之间的接口就会很乱套。
这会使团队内部耦合度提高，会议时间、重复劳动和无效工作都
会增加。
理想的人员安排是这样：在项目的的大部分时间里由小型核心团
队来做设计工作，在开发的最后阶段（时间安排的最后1/6）加入
大量的人手。
可怕的猜想：时间安排紧迫的项目，与时间安排比较合理的项目
比起来，完成的时间发而会更长。

也许你还会喜欢

汤普金斯先生的日记——人类的错误

Allen — Fri, 04 Apr 2008 10:00:40 +0000

今天，汤普金斯先生不再周旋于他的项目中，决定在周末轻松地享受这难得的休息。汤普金斯先生驾车在公路上行驶，决定走“5号公路”去郊游。不久看到一块黑红各半的标记牌，上面写着“4号公路”。汤普金斯想，接下去的一块黑红各半的标记就可以转向了，但是一直没有找到。

当汤普金斯先生发现自己走错路的时候，回头再找那错过的路口时，发现原来那个标识“5号公路”的路牌不像标识“4号公路”的路牌一样，是黑红各半的标记，而是白底黑字的路牌，上面写着“5号公路”。

汤普金斯先生飞快地记下自己的想法：

人类的错误

将你置于死地的，不是你不知道的的东西…而正是你“知道”绝不会置你于死地的东西。

也许你还会喜欢

汤普金斯先生的日记——催化剂的角色

Allen — Thu, 03 Apr 2008 10:00:50 +0000

汤普金斯先生今天碰到一个问题，他没有成功调解他手下两个程序员的冲突，幸好有麦斯特罗·迪耶尼亚尔先生，他告诉了汤普金斯先生很多有趣的故事，并且帮助汤普金斯先生了解到如何化解冲突。

催化剂的角色

有这样一种催化剂式的人物，这样的人能帮助团队成型并凝聚，保
持团队的健康和生产力，从而对项目做出贡献。就算“催化剂”别
的什么事情都不干（其实，通常他们还会干很多别的事），这种催
化剂的角色也是重要而有价值的。
调解是“催化剂”的一项特殊工作。调解是可以学的，而且只需要
很小的投资就能学会。
调解应该从一个小小的仪式开始。“我能帮你们调解一下吗？”在解决冲突的
时候，这是必要的第一个步骤。