案例讨论：传统 vs 敏捷

张恂

如果我是这个项目的项目经理，我会怎么做。

1、我会向领导要2个程序员，全职，最好毕业后1-2年的人；
2、我自己做需求和详细设计；同时和程序员商量框架技术；由于我对技术并没有什么热情，所以我一般倾向于使用大家熟悉的技术；
3、做完需求后，和用户、程序员一起讨论；
4、做完详细设计，和程序员一起讨论，务必让程序员理解整体业务，和自己那块的业务；
5、安排项目进度，开始开发；

在这过程中，作为PM还需要应付领导：
1、根据部门要求写一个需求文档和设计文档（和前面的不一样，提供的程序员的文档，完全站在开发立场上写）；
2、每2周写项目进度汇报领导。

在过程中，和业务部门的沟通：所有需求变更或者增加都需要通过PM。必须要我经过思考，大家一起讨论后，才能决定是否能做；即使业务部门直接告诉程序员，程序员也不能自己答应下来，先要回报给我。

其他情况，就随机应变了。我估计，这个项目的时间范围是3个月。


---


这个方案仍然有明显的缺陷 ...

[ 本帖最后由 张恂 于 2009-8-5 17:02 编辑 ]

张恂

一个敏捷、迭代的开发团队大概会这么做。

如果是 3 个月的项目，会分成 3 个长度为 1 个月的迭代（根据该案的特点确定合适的迭代长度，一开始不宜过短）。每个迭代中都会包括需求、设计、编码、测试、演示和评审等工作，而不是一次性地完成所有的需求文档、设计文档然后再开发（避免浪费）。

重点是整个迭代开发是风险驱动的。显然开发人员对技术不熟悉是该项目最大的风险之一，那么应该从一开始就安排开发人员进行相应学习和探索的任务。在第 2 周就可以开始搭建开发框架，而不是等到完成全部的详细设计文档、通过领导审批、技术委员会审批之后再做，那么做太浪费时间，风险也大。

每个迭代都必须有测试和用户评审，以便提供反馈校正需求和设计。每个迭代的第 1 周进行需求分析和系统设计工作，第 4 周完成系统的测试，并向业务部门的用户进行功能演示，举行迭代评审会议，及时总结已取得的经验和教训并迅速作出调整。

详细设计文档没有通过实际程序的运行、测试，获得真实的验证、反馈，往往是不稳定、不符合实际的，存在很多臆测和错误。企图严格按照事先编制的、固化的详细设计文档来编写程序，往往是一种糟糕的做法，既低效也不现实，因为软件开发中根据变化的情况经常调整、改变设计和程序是一种常态。正如作者所说，“文档其实就是为了应付领导”。详细设计文档通常是一种浪费。我们建议大家在迭代开发中只编写少量关键的架构设计文档或概要设计文档。

张恂

说我手头一个项目，我做好一大块业务逻辑的需求、设计。但我觉得还不能开始开发，因为还有后面一小块的逻辑没有搞清楚。所以我要等所有的逻辑搞清楚了，需求、设计做好了，才开始开发。

我相信这是完全不符合敏捷的思想。但我必须这样做。为什么呢？

因为前后逻辑有很强的关系。我可以开始小阶段的开发；但是，到了一定程度后，如果整个逻辑没有分析清楚，到开发后期，就会产生问题需要回过头去修改前面的程序。

所以，我觉得敏捷方法，需要视情况使用。我已经把项目分成几个阶段，如果够人，是可以做到并行进行。但现在不够人手，所以全盘分析后再开始比较安全。

-----

我在这里作了比较详细的分析：
http://www.itpub.net/viewthread.php?tid=1205270&pid=14102992&page=1&extra=page%3D1

[ 本帖最后由 张恂 于 2009-8-18 14:51 编辑 ]

bq_wang

呵呵，看了您关于敏捷的不少文章，昨天也开始慢慢开始阅读敏捷的书籍

感觉最大的一个问题在于：甲乙双方能否一起协作？
甲方往往认为需求谈好了，剩下的就全是乙方的工作了，随着项目的推进，甲方关于需求的不断深化，导致最终需求与最初大相径庭，这是事实；敏捷关于交付物>文档也是这方面的原因吧。

在国内项目中，甲乙双方地位的不平等，甲方的参与程度如何，决定了是否能够采用敏捷方式

bq_wang

呵呵，上面的回复好像与之无关了

这个是一个国内小IT公司普遍存在的现象，应该与敏捷无关吧，资源得不到保障，所谓的规章制度又必须的遵守；

对于这些公司来说，理顺组织结构理顺公司制度的作用要远远大于敏捷吧

张恂

bq_wang:

感觉最大的一个问题在于：甲乙双方能否一起协作？

甲方往往认为需求谈好了，剩下的就全是乙方的工作了，随着项目的推进，甲方关于需求的不断深化，导致最终需求与最初大相径庭，这是事实；敏捷关于交付物>文档也是这方面的原因吧。

在国内项目中，甲乙双方地位的不平等，甲方的参与程度如何，决定了是否能够采用敏捷方式

--------

你提的这几个观点和问题非常好，属于经典 FAQ。后面我会在《中式太极敏捷》中作进一步地分析，这里先简单回答一下：

的确，甲方的参与度非常重要。如何 engage customer、保障顺畅的 communication 是敏捷的重点和前提，如果双方不能很好地沟通、紧密的协作，敏捷就无从谈起。

对于国内项目中较为普遍的甲乙双方地位不平等或乙方弱势，需要一些应对措施。

正好有个讨论“为什么不能敏捷？”有此有关：

http://www.itpub.net/viewthread.php?tid=1181948&extra=page%3D1

[ 本帖最后由 张恂 于 2009-8-20 14:56 编辑 ]

张恂

bq_wang:

甲方往往认为需求谈好了，剩下的就全是乙方的工作了，随着项目的推进，甲方关于需求的不断深化，导致最终需求与最初大相径庭，这是事实；敏捷关于交付物>文档也是这方面的原因吧。

--------

是的，这种现象国内相当常见，就是大家常抱怨的“需求变化大”的情况，这跟客户不成熟、不了解软件工程、对软件需求存在误解等许多因素有关。我会在《中式太极敏捷》中专门讨论这个问题。

对于这种需求变化大、不确定性多的情况，敏捷迭代开发恰恰是最好的解决之道。

[ 本帖最后由 张恂 于 2009-8-20 15:03 编辑 ]

syderny

突然理解了一个事实，管理即分析，还得分析得有条理有逻辑，恩学到了

syderny

突然理解了一个事实，管理即分析，还得分析得有条理有逻辑，恩学到了

iamlomen

张恂 发表于 2009-8-5 16:54
如果我是这个项目的项目经理，我会怎么做。

1、我会向领导要2个程序员，全职，最好毕业后1-2年的人；

哎，我也支持楼上的说法，我现在就在做一个death march 项目。。。
项目需求：大概需要3-4个三年以上的工作经验的，预计开发周期是9个月。
现有人力：一个应届毕业上过培训班的，再加一个未毕业的实习生，再加一个有一年多经验的。加上我这个三年多以前兼过管理的程序员。
项目现状：项目设计我做，框架代码我写，中间用到了比较强大的一个开源框架（选择这个的原因说来话长），因为研究不透彻造成我对其中出现的问题也不能及时解决，其他人不了解框架更是没啥指望，新人基础知识都不牢固，很多东西从头学起，耗费很多时间，而且积极性不足，工作排程经常拖很久（这个一部分也是技术原因）。但是上面认为正规院校毕业的学生，技术差不到哪去，进度之所以慢都是我的错，不会管理不会用人，给我很大压力。事实真的与他们的想象不同啊。
暂时的应对：稍加压力，不敢严格要求（因为人员补充很难，所以担心流失，哎）。对于他们的基础问题，我都一一作答，问题这样的情况下我自己的工作又无法保证。所以比较纠结。对自己心理暗示，不要总将问题归咎与别人，努力发现自己在管理中出现的问题。

自身的反省：初期对于人员素质培训上做的不足，前面的开发中跟催不到位，对于他们的一些编码规范跟踪不足，义务的沟通不足，只是给了他们设计文档和界面设计，自己以为都是些简单的业务就没多做讲解。

我很想向上面的大哥一样，要两个毕业有一两年工作经验的，问题是没有啊。。。哎。
求各位资深管理者指教后面的路怎么走，挺纠结的。。如何化解这诸多的矛盾。