回顾两个项目看设计阶段

回顾自己所经历的两个项目,来对设计阶段进行了总结,自己也算是个XPer,经历过的这两个项目也基本都是采用XP的方式进展,大家都知道,XP在设计阶段推崇的是群体设计,通过CRC来完成,在这里就对两个项目执行的情况做做总结。
项目A
一个大型项目,当时的团队相当于是两个设计师加上三个高程组成,迭代会议完成用户故事分解、CRC设计以及任务分配,典型的XP方式,项目开展过程中应该是整个过程都执行的不错,尽管现在回想当时的CRC做的并不是很好,但应该说在整个项目开展过程中并没有出现多少问题,项目需求的实现都还算正常,整个团队的提高也是非常的不错,共同进步。
项目B
一个框架型项目,团队成员是一个设计师、一个高程加上四个初程,同样的XP方式的设计,项目开展过程中出现了不少问题,设计师不得不花大量的时间在技术支持上,而且最后项目的结果无论是需求上还是设计上都产生了不小的偏差,整个团队的提高也没达到期望的效果,而由于设计师过多的投入在技术支持上,使得架构的完善一直存在偏离。

为什么同样的过程在两个不同的项目、不同的团队中执行的效果会相差这么远呢?
首先从项目类型分析,项目A属于实际项目,项目B属于研发项目,两个项目的关注点不同,项目A的关注点是客户需求,项目B的关注点则更多的是扩展性和二次开发的易用性,在这两类项目中设计几乎是完全不同的,项目A更多的是业务的复杂度,而项目B更多的却是技术的复杂度,从这个方面分析下来得出的结果其实就是项目A更重人员的业务能力,而项目B更重人员的技术能力,当时项目A团队中的人员对该项目的业务应该说都属于熟悉的那种,觉得这也是成功的原因之一,而项目B团队中的人员技术相对项目要求来讲是不足的。
接着从项目成员本身分析,项目A中的几个成员基本都属于能够独当一面的人,而项目B中的成员水平参差不齐,觉得这也是在两个项目中执行效果不同的原因之一。
而最重要的一点问题我认为出在设计阶段上了,XP在设计阶段更多的是发挥群体智慧,在设计时基本是群体参与,而形成的CRC尽管已经详细,但通常都没有一个良好的记录,在项目A中由于团队成员个人的能力即使在实现的过程中出现一些问题也能独立解决,所以没有暴露出什么问题,同时由于团队成员能力的相当,在CRC设计讨论的时候大家基本能做到充分的交流,对于大家的提升都很明显,而在项目B中则由于团队成员能力的参差不齐,导致在CRC设计时基本没有讨论,都是设计师主导,而且最终由于没形成足够的文档,在实现时团队成员仍然是出现不少的问题,而需要设计师不断的去指导,最终导致设计师在架构上投入的不足,同时也导致团队成员在实现时仍然出现不少问题;在设计阶段的第二个问题则是由于在XP中实行简单设计,当然,简单不等于简陋,但这个时候的设计更多的其实是需要通过重构去不断完善的,在项目A的团队中成员在完成任务后都会对自己的任务进行一定的重构完善设计,而在项目B中却没法做到这一点,导致最后的实现在设计上出现过多不完善的地方。

在这样的分析下,认为设计阶段需要充分结合团队情况而考虑开展方式,对于水平都相当并且具有一定设计能力的团队而言,群体设计的方式无疑会大大超过个体设计,对于整个团队的协作、水平提升都会起到极佳的作用,而且这时我觉得也没必要在设计上过多的追求,而应该采用能想到的最简单的解决方案,在成员实现解决方案的过程中成员可根据经验不断的进行重构完善设计,在这样的情况下没必要开始形成规范的设计文档,可在一定的阶段如迭代完成前的设计稳定时形成规范的设计文档,其实同样,在这样的团队中没有明显的设计师和开发人员的区别,在这样的团队中对于需求的变化是可以快速进行响应的,不用纠缠于规范的文档格式,而可以通过代码来表达出足够的设计思想;而对于水平参差不齐的团队而言,个人认为团队中的系统设计师这时要充分担当设计师的职责,对于任务提供出详细的设计文档,通常来说,为了方便整个团队的理解,需要形成规范性质的文档,而且在做设计时,设计师应该尽量的考虑齐全,不能过多的去依赖后期的重构来完善设计,同时,在将设计交由开发人员进行实现时要加强Code Review以及开发指导,在这样形式的团队中,自动生成代码的形式以及开发代码的模板会起到很好的帮助,或者设计师可以通过依赖设计工具如rose等的强大支持,将设计模型转化为开发模型,从一定程度上限定和规范开发人员的开发,当然,最佳的就是提供框架和框架的IDE,在这样的方式下,就要求设计师对于设计有充分的把握能力和预见能力,否则在需求出现变化时会难以应付,呵呵,就仅仅在规范的文档格式方面都要投入不少时间,在这样的情况下,设计师和开发人员的职责一定要界定清楚,设计师需要首先对架构进行完善,在完善后开始详细设计并交由开发人员实现,在这个过程中设计人员更多的是需要承担起开发指导和设计Review的角色。

by the way:其实也可以看出,需要充分的对团队成员进行了解来制定相应的软件过程,想做到流水线式的开发是要付出巨大的前期努力的。

ps:后续一文:系统设计方法和工具(争取在年前完成),^_^

posted on 2006-01-18 23:22 BlueDavy 阅读(2128) 评论(7)  编辑  收藏 所属分类: 系统设计

评论

# re: 回顾两个项目看设计阶段 2006-01-19 00:09 mimimama

不错。有同感。  回复  更多评论   

# re: 回顾两个项目看设计阶段 2006-01-19 08:40 dev

项目B失败在人力资源配置上,对于一个框架性、研发项目,这样的团队配置是很难成功的,或者要花费很大的代价。从项目B的组成来看,那个高程是一个很重要的因数,这里先假设设计师的系统分析、设计、需要把握和项目控制能力都满足需要。那个高程需要帮助设计师承担解决重要技术问题、任务细分、进度跟踪、质量控制的细小而有重要的任务,让设计师尽可能从底层脱离出来,关注系统架构、系统范围、把握需求,把握更大层面的问题。从这点看,对于这种框架性研发项目,比较好的人员配置应该是:设计师(可能兼任项目经理)1人,有经验的,3年以上开发经验的高程2人,初程1人,有至少2年开发经验的程序员2人  回复  更多评论   

# re: 回顾两个项目看设计阶段 2006-01-19 09:31 GHawk

可以参考一下这篇文档 http://www.iturls.com/Articles/doc/XP_Value.pdf
XP也具有一定的局限性。Agile Process也并不只有XP而已,可以试试其他的过程。有了实践和总结,应该会有提高的。  回复  更多评论   

# re: 回顾两个项目看设计阶段 2006-01-19 22:14 Programmer's Life

to dev:
多谢你的建议,^_^,在研发类的项目中我觉得对人员技术的能力要求是会比较高的

to GHawk:
^_^,恩,我先看看这个PDF,软件过程是一门需要经验的丰富学问  回复  更多评论   

# re: 回顾两个项目看设计阶段 2006-01-20 00:38 Vincent Thinking

xp中,人的因素要重要的多。

成员水平参差不齐,我个人感觉最好不要施行XP,至少不要全面施行。


我的感觉:很多情况不是XP方法的问题,不是多开几次会,多迭代几次,多PP几把就能解决问题,核心的关键还是人!!  回复  更多评论   

# re: 回顾两个项目看设计阶段 2006-01-20 02:56 mixlee

培训初程的代价太大,国内公司很少做这种事。
我认为初程最好只做二次开发,就是基于公司的快速开发框架做业务流程的应用开发。这样以来框架会强制性的实现开发的规范性以及一致性还有性能的问题。
要设计师提供详细设计文档给初程也是不现实的事情。
详细设计花的时间比编码的时间还长,只一个设计师不可能完成这项任务。
到最后设计师就成扑火队员,一方面要培训初程,跟初程沟通也是一件花时间的事情,另一方面还得解决技术攻关,两头都做不好,基本上会累的半死。
  回复  更多评论   

# re: 回顾两个项目看设计阶段 2006-01-20 16:23 Programmer's Life

^_^,vincent说的很对,一个良好合作的团队是有很多因素的,软件过程只是一种辅助。

mixlee说的对,是我应该重点考虑的问题,多谢。  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航:
 

公告

 









feedsky
抓虾
google reader
鲜果

导航

<2006年1月>
25262728293031
1234567
891011121314
15161718192021
22232425262728
2930311234

统计

随笔分类

随笔档案

文章档案

Blogger's

搜索

最新评论

阅读排行榜

评论排行榜