1. 锦囊妙计
1.1. 专案修改委员会
控制软件产品修改的方法,由每个相关部门的代表(开发部,客服部,市场部)的参与,并给予它们无限的权力接受或拒绝被提出的修改方案。
提升专案功能的可见度及降低不可控因素的数量
风险:通过太多或太少的修改
1.2. 每日制作与测试
每天软件都被完全整合并经过测试,以确保正常运行,降低整合测试的风险。
主要风险:软件临时版本推出过于频繁,提高了专案成本
1.3. 弹性设计
专案前期使用:找出可能被须改的部分,运用信息隐藏,指定一个修改计划,定义软件家族,运用物件导向设计。
主要风险:过于依赖程式语言来解决软件设计问题。
1.4. 渐进式系统上线
1.5. 渐进式系统模型
1.6. 目标设定
利用人类的意志力来提供工作效率
主要风险:目标改变失去努力的动机
1.7. 检查
检查是一种正是的技术捡视。
1.8. 合作系统开发
(Joint Application Development JAD)
运用需求定义及使用者界面模型的方法设计,用户,高管,开发人员同时参加会议讨论系统开发细节。
1.9. 选择生命周期模式
1.10. 量测
不要只收集资料,要分析并把结果回报给给被量测者
1.11. 小型里程碑
可以不断给人成就感,鼓舞士气,降低时程风险,提高专案可见度及控制。
不要让你的开发团队走在黑暗里。
间隔较大的大里程碑用来指定总的方向。
1.12. 外包
1.13. 原则化商议
1.14. 高效率环境
无噪音,无干扰,不拥挤,不被经常打断,足够的灯光,稳定的电源,方便得卫生设备
80平方尺/人,15平方尺的桌面,避免电话/人为/噪音干扰
15尺宽的书架,12平方尺白班,12平方尺布告栏,方便使用的打印机/复印机,方便使用的会议室,容易拿到的办公用品,开向外面的窗户。
1.15. 快速系统开发语言
1.16. 理清客户需求
找出不真正需要和过分复杂的客户要求,并除去它们。
1.17. 再用
一个长期收益的策略,公司把常用的软件部分储存在编码资料库中,将来再用
有计划地运用再用。
计划性再用
临时性再用(外部,内部)
功能导向的办法:35%的编码可以从旧软件中取得。
物件导向的办法:70%以上的编码可以从旧软件中取得。
1.17.1. 管理上的考量
1. 在高层管理人员中指定一个再用负责人。准备再用对第一线管理人员没有好处,因为这只会使以后的专案受益,而使在目前的专案在时间上受损。
2. 把再用作为一个长期的策略,因为可能要在两年以后才会开始受益。
3. 强调再用并把它作为软件开发重要的一部分,把支援再用当作工作表现评估的一项。
4. 把公司软件开发效率的标准从有多少软件被开发改为有多少软件被推出,这可鼓励软件开发者用再用的办法。
5. 建立一个再用小组来负责再用的软件部分,在小公司里,这个小组可能只有一个人。
6. 训练再用小组和它的客户
7. 提高公司对再用的认识。
8. 记录使用再用的软件开发者,若他们所再用的部分出现问题,可及时通知他们
9. 建立一个使用再用编码库的索费制度
1.17.2. 技术上考量
1. 评估现有的软件架构是否支援再用,若不支援,开发一个支援再用的软件架构。
2. 评估现有的编码标准是否支援再用,并在适当的时候建议新的标准。
3. 设计支援再用的程式语言和界面标准,若语言界面编码习惯不同就很难使用再用。
4. 设计支援再用的开发过程。建议在每个专案开始时先看是否有可再用的部分。
5. 建立一个可再用的部分的资料库,并提供一个目录来帮助如见开发者找到需要的部分。
6. 隐藏和包含才是再用的要点而不是继承和多态。
7. 品质和文档包括缺陷文档。
最大危机:可再用的特性会延长开发时间2~3倍
1.18. 心态动机
您提供开发者除了工作本身外还有一些奖励:有机会做很重要的事,扩展他们的能力,完成几乎不可能完成的目标,完成以前没有人完成的工作。
1.19. 螺旋式生命周期模式
1.20. 阶段式系统上线
1.21. W理论管理
让每个人都成为赢家Winner
一个专案涉及到很多利益冲突的人,此理论设法使每个人从专案中得利。
专案中每个人的目的 | ||||
客户 | 上司 | 开发者 | 使用者 | 维护者 |
快速推出 低成本 | 不超支 无惊讶 专案成功 | 工作有趣 探索新技术 没有怨言 运行快效率高 | 功能齐全 容易用 容易修改 | 无故障 好的说明文件 在家工作 |
找出大家都得利的先决条件
理解为何大家想得利
建立适当的期望(让大家设身处地的为别人考虑,用经验来说服,用通用数据公式说服)
把每个人的工作与他的目标联系起来
1.22. 抛弃式系统模型
1.23. 限时开发
让吓阻感觉到专案时程的压力,可能牺牲一些次要的不重要不常用的功能而不是牺牲品质或延长专案时程。
1.24. 工具小组
在几个专案间负责收集有关软件开发工具的信息,评审工具,安排工具的使用。
1.25. 十大危机
每星期定期检查十大危机清单有助于提高对风险的识别和解决
1.26. 使用者界面模型(雏形)
1.27. 自愿加班
太多的加班及时程压力,将破坏开发时程。适当加班每周4-8个小时,将增加10%~20%或者更多的工作量。
当你发现开发人员开会开始迟到,午餐吃很久,这表示您要求加班太多了,已超过最有效的工作量了。