项目管理者联盟 | 中国工程管理网 | 中国研发管理网   会员中心 资料库 论坛 博客

PMI-ACP®认证

适合敏捷开发项目
敏捷项目管理最佳实践

网络课程

PMI-PBA®认证

重视项目商业分析
商业价值与需求分析能力

网络课程

NPDP®认证

产品管理国际认证
全球产品管理最佳实践

网络课

PMP®认证

单项目管理经典指南
年轻项目经理首选

北京 | 直播 | 录播

PgMP®认证

大型复杂项目全球标准
定位高级项目管理层

网络班

PfMP®认证

链接战略与项目
实现组织资源投资回报

全球直播

软考项目管理

信息系统项目管理师
系统集成项目管理工程师

计划 | 报名 | 经验

圈子
志同道合,朋友再聚首
项目管理者联盟PMP培训
会员· 圈友
登录ID
密   码
 
圈子信息
圈名:国内项目管理探索
加入方式: 允许任何人加入

国内项目管理探索

本圈子是方便大家就国内的项目管理自主之路的探索,建立一套我们的标准。

圈主:onroading    管理员:暂无管理员   
成员数:30
主题数:1701
排名8
通讯录
圈友列表
加入本圈
管理本圈
 
话题区 投票区 资料区 精华区
标题:大项目的思考
楼主

铁托
PMB:19794
省份:安徽省
行业:综合应用
注册:2006/4/30
  
  
引言:进入现在这个我们内部号称“豪门”的项目已经两个多月了。现在回想起进入项目前一位前辈的话:“大项目有大项目的问题,但大项目也有很多东西可学“,自己此时深表赞同。两个月的时间,自己从刚来前两周的观察学习,到现在的基本融入,在这个过程中自己有了很多的想法和思考。

  为什么测试这么难写?

  TDD的开发实践保证了代码的可测试性,那么当TDD的T变的非常难写的时候,是不是现有的代码可测试性已然变的非常差呢?其中一些非常典型的场景就是:

  test的setup太难,而造成这个的一个主要原因就是贫血的model和万能的service。因为model没有行为,所以很多时候可以通过测试model来完成的测试,却不得不通过测service来完成,而万能的service做的事情又太多,需要依赖的东西也太多,而这个时候你本来一个简单的测试就为了setup这个service的依赖,而变成一个巨型的测试。

  你总有做behavior verification的冲动,而behavior verification本身就是邪恶的。记得《xUnit test pattens》这本书说到,”任何需要白盒测试的时候,往往都是代码设计的问题“。

  Assert太多了,一个简单的测试却要有一堆的assert语句。问题很简单,被测试的对象承担了太多的职责。

  脆弱的测试,这里我看到了有两个原因:第一,共享的fixture;第二,想当然的assert,比如你只是想assert这个collection有没有你要的那个instance,因为你想当然的认为此时collection里只有一个instance,造成后人对于这个collection加入另一个不同instance依然会break你的测试。

  Kent Beck说过,当你的测试出现问题,退后一步往往就是一个设计问题。

  项目初期设计framework好吗?

  很多人开发人员迷恋framework,迷恋framework设计的优雅以及对于开发的便利。我曾经也是其中一员,但是现在我站在了这个观点的对立面。

  首先,项目初期的时候framework的设计在大部分都是猜测,刚开始的时候这些猜测大部分都很准,因为这个时候距离是framework的设计者可以看到了,这就如同你站在原地,你能看到10米外的东西。随着项目时间的增长,这个距离也在增长,在加上中间需求的一些变更,就如同一个小弯,这时候的位置已经不是framework的设计者所能看到的距离了。这个时候framework对于开发限制开始突出,而开发人员碍于修改framework成本太高,很多时候被framework所牵制。既然我们只能看到10米外的东西,那么我们为什么要做100米外的设计呢?

  其次,framework的设计思想也会随着项目人员的进进出出,项目进度的压力,大家都没有实践仔细的去看framework。framwork的设计思想变的不再清晰,大家开始按照自己的对于framework的理解来写代码,后来者更不理解framework,会照那些前面未必正确的理解的代码来书写。

  团队!团队!

  一个团队是不仅是在维护一份源代码,更重要的是维护这个项目所承载的知识。而这些知识不应该只记在某些关键人物的脑中,应该记在所有团队成员的脑中,更不应该只记录在文档之中。而这知识包括:

  架构设计的知识:架构设计的知识只有进入所有开发人员的脑中,才能得到正确的实现。因此架构设计不应该只从技术角度考虑,也应该从团队知识传递的角度考虑。一个100的设计,而团队成员只能理解30分,那你觉的最后的软件是多少分呢?

  所谓的局部知识:很多时候,一些开发人员觉得我做的东西只有我一个人在做(比如build脚本),所以我可以选我熟悉的东西就好。而这种所谓局部知识的想法非常不可取,因为当你有这个想法的时候就意味着你变成这个项目的瓶颈。

  固定角色:在团队中固定角色就意味着划定了各个角色的边界,而每个角色对于自己角色外的东西已然不是外面的世界很精彩。这个时候很多时候它做得决定都是基于自己的角色,而不是整个团队的角度。


回复 | 引用 发表时间:2014/1/14 21:15:03

xinkingss
PMB:394
省份:广东省
行业:IT软件
注册:2014/1/15
  
  
标题:Re:大项目的思考
1 楼
做大项目需要哪些项目管理技能储备呢
回复 | 引用    回复时间:2014/1/15 16:14:09
分页:1/1 共1条 首页 上一页 下一页 尾页 查看页 
!  您尚未登录,不能回复主题。    现在 登录  注册
关于联盟 | VIP会员 | 培训服务 | PMP认证 | PgMP认证 | 刊物出版 | 沙龙会议 | 人才服务 | 广告投放 | 联系我们 | 友情链接
建设运营:共创时网络
版权所有 京ICP证070584号 BBS业务许可2007第353号