2009年5月18日星期一

芜湖项目现场需求调研阶段总结

芜湖项目现场需求调研阶段,工作效率高,工作成果的质量也很好,现在总结如下:

  1. 需求分析团队人员要尽量少,减少沟通成本。尽量只允许业务核心人员参与,这样能够以最快速度对业务流程进行确认。
    反观现在大平台的项目,需求分析阶段有30多个人参加,包括了国家局的人员和各省市的人员。分成了6个分析小组。诸多问题无法现场进行确认,因为参加的人多,因此大家都不作结论,只能会后通过EMAIL来回来去。由于分组很多,因此涉及到很多跨小组的问题进一步增加了沟通成本。
  2. 需求讨论会议现场形成文档,由于文档形式上是共同创作完成,因此可以省略客户确认文档的过程。
    反观现在大平台的项目,会议之后,需求分析人员晚上加班形成需求访谈报告,需要客户确认,然后再形成需求规格说明书,再要求客户确认,这样效率非常差。
  3. 关于需求分析的团队构成,建议如下:
    - 客户业务人员
    - 客户IT人员
    - 主力业务分析人员:主要负责需求分析工作,引导大家使用正确的方式和正确的方向进行需求分析工作。
    - 业务分析助理:主要使用合适的工具,现场进行文档撰写工作。也可以提出自己的建议。因此该人员也需要有一定的需求分析能力和文档撰写经验。
    - 项目助理:负责对会议中的各种未定事项以及决议进行跟踪,并且进行其他的一些辅助性工作。
    - 解决方案顾问团队:辅助角色,可以离线支持。主要对相关业务领域或者IT技术领域进行咨询工作。
    - 开发组组长以及主要设计人员
    - 系统实施负责人
  4. 使用的工具建议如下:
    - 业务流程分析工具,以便团队成员能够在早期对业务流程有全貌的认识,如BPMN, EPC图等等
    - 快速互动原型工具,以便快速形成可以进行互动的动态系统原型,给客户良好的感受。推荐serena prototype composer或者axure rp等。
    - Sparx Enterprise architect,全面的项目模型管理,在此阶段主要使用到:用例分析,领域模型,需求条目管理等等。(在用例中需要填写senario条目,并且需要与需求条目进行关联)
    - Balsamiq Mockups,对操作页面进行设计。
  5. 对目前的大平台,现在能想到的建议如下:
    - 分组尽量少,1~2各组,人员尽量少,减少沟通成本。
    - 现场形成文档。
    - 在早期需要有总体业务流程分析过程,然后在进入细节系统需求分析过程。
    - 使用上述的工具
    - 使用上述的团队组织结构

综上,发现上述经验并不太符合敏捷过程,反而与《人月神话》中的理论非常相似。起码,可以总结出来两点:1.架构(需求分析)是贵族专有的工作内容。2.需要组成外科手术型的团队结构。

2009年5月17日星期日

芜湖出差,巡回取货项目的一些心得

五一之后到芜湖,客串巡回取货项目的项目经理,负责需求调研工作。整两周的时间,有如下一些心得体会:
出差两周,其中需求调研工作大约占用了6个工作日的时间。另外有2个工作日大约是各种各样的汇报。
工作进行的比较顺利。体验也很好,主要是可以按照自己比较推荐的方法来进行项目工作,大家都比较轻松,工作效率也很高。客户方也反映工作效率很高,工作很有成效。
开始的几天,使用serena prototype composer工具,项目组成员在同一个会议室中,主要讨论工作流程(与系统无关)。然后同样使用这个工具,讨论大致的系统操作流程,同时画出初步的系统界面。这个阶段成果效果非常好:大家对系统的总体概念已经形成,基本确认了系统范围。并且形成了可以进行互动的系统界面原型。
然后开始使用EA和Balsamiq Mockups配合进行用例分析与界面设计。在EA中复制了serena prototype composer中的工作流程,然后进行用例分析,在用例中进行场景senario步骤描述。针对每一个用例,至少使用Mockups软件绘制一张界面设计图。另外在EA中进行领域模型的设计。
综上,提供出一份真正对开发有帮助的需求文档。
经估算,这两周的需求分析工作定义出的系统需求大约需要5人团队开发3个月的时间的工作量。开起来也非常符合比例。当然这仅仅是估算的合理值,估计和客户方面进行协商之后,时间上又会变得非常不合理。

客户非常高兴的从我这里拿到了上述的三款设计工具。不过,真正重要的是需要会使用这些工具啊。

在出差期间,抽时间学习“Head First OOAD”,有如下收获:
终于对需求和用例明确的区分开了。需求大约总是以“系统应该可以xxx”这样的格式描述,主要描述系统所具有的功能和能力。用例侧重于描述某某场景senario下面的操作步骤。因此大约会是包括正常路径/可选路径/替代路径等等。

不过,在出差期间,本计划使用类似极限编程方式的增量开发,结果未遂。最终变成了类似ICONIX方式的过程。

另外,意外的发现,原公司上班时,结识的MOTO客户,现在正在作为甲方折磨着现在我的客户。现在我的客户天天折磨我们,同时他们也在被MOTO客户折磨着。……