PMI-ACP®认证
适合敏捷开发项目 敏捷项目管理最佳实践
网络课程
PMI-PBA®认证
重视项目商业分析 商业价值与需求分析能力
NPDP®认证
产品管理国际认证 全球产品管理最佳实践
网络课
PMP®认证
单项目管理经典指南 年轻项目经理首选
北京 | 直播 | 录播
PgMP®认证
大型复杂项目全球标准 定位高级项目管理层
网络班
PfMP®认证
链接战略与项目 实现组织资源投资回报
全球直播
软考项目管理
信息系统项目管理师 系统集成项目管理工程师
计划 | 报名 | 经验
版面信息
本版版主
俱乐部导航
联盟·近期活动
社区热点
精彩专题
如何做好项目沟通计划
软件项目质量管理
国际工程索赔与反索赔
推荐信息
社区圈子
联系社区管理员
67. 开始开发和测试之前每个人都仔细审阅功能设计么? 要做。Function Spec review是用来统一思想的。而且,review过以后形成了一致意见,将来再也没有人可以说“你看,当初我就是反对这么设计的,现在吃苦头了吧”
68. 所有人都始终想着The Whole Image么? 要这样。项目里面每个人虽然都只是在制造一片叶子,但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领,反对过分的把软件制造看成流水线、车间。参见第61条。
69. Dev工作的划分是单纯纵向或横向的么? 不能单纯的根据功能模块分,或者单纯根据表现层、中间层、数据库层分。我推荐这么做:首先根据功能模块分,然后每个“层”都有一个Owner来Review所有人的设计和代码,保证consistency。
70. 你们的程序员写程序设计说明文档么? 要。不过我听说微软的程序员1999年以前也不写。所以说,写不写也不是绝对的,偷懒有时候也是可以的。参见第56条。