- 浏览: 2679042 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
80后的童年2:
深入浅出MongoDB应用实战开发网盘地址:https://p ...
MongoDB入门教程 -
shliujing:
楼主在不是精通java和php的前提下,请不要妄下结论。
PHP、CakePHP哪凉快哪呆着去 -
安静听歌:
希望可以一给一点点注释
MySQL存储过程之代码块、条件控制、迭代 -
qq287767957:
PHP是全宇宙最强的语言!
PHP、CakePHP哪凉快哪呆着去 -
rryymmoK:
深入浅出MongoDB应用实战开发百度网盘下载:链接:http ...
MongoDB入门教程
第六章 快速开发中的核心问题
活动 小型项目 大型项目
总体/设计 10% 30%
详细设计 20% 20%
编码/测试 25% 10%
单元测试 20% 5%
综合测试 15% 20%
系统测试 10% 15%
软件项目的平衡三角:进度、费用、产品
实现快速开发的方法:
生命期计划
估算
进度计划
面向客户开发
激励
团队合作
团队结构
功能限定
生产力工具
项目校正
第七章 生命期计划
选择了适宜的生命期模型,就可以提高开发速度、提升质量、加强项目跟踪和控制、减少成本、降低风险,或是改善用户关系
错误地选择生命期模型,必定会导致工作拖沓、劳动重复、无畏的浪费和遭受挫折
1,纯瀑布模型
文档驱动,意味着主要工作成果是通过文档从一个阶段传递到下一个阶段
在纯瀑布模型中,各阶段不连续也不交迭
软件概念->需求分析->架构设计->详细设计->编码和测试->系统测试
当你有一个稳定的产品定义和很容易理解的技术解决方案时,纯瀑布模型特别合适
对于那些容易理解但很复杂的项目,采用纯瀑布模型比较适合,因为你可以用顺序的方法处理复杂的问题
当开发队伍的技术力量比较弱或者缺乏经验的时候,瀑布模型更为适宜
如果你采用瀑布模型,遗漏需求的时候是代价高昂的错误
瀑布模型最主要的问题是缺乏灵活性
2,编码修正模型
编码修正模型比较常见,如果你没有明确地选择其他生命期模型,也许你就会不自觉地进行编码,然后进行修改
编码修正模型的好处:一,它不需要什么成本,二,它只需要极少的专业知识
对于稍微大一点的项目,采用这种模型是很危险的
它虽然不需要什么成本,但是它也不提供评估项目进展情况的手段
3,螺旋模型
螺旋模型是一种以风险为导向的生命期模型,它把一个软件项目分解成一个个小项目
每个小项目都标识一个或多个主要风险因素,直到所有主要风险因素都被确认
螺旋模型的基本思路是,从一个小范围的关键中心地带开始寻找风险因素,制定风险控制计划,并交付给下一步骤,如此迭代
每次迭代都把项目扩展到一个更大的规模,每次迭代都包括以下六个步骤:
1)确定目标、方案和约束条件
2)识别并解决风险
3)评价备选方案
4)开发本次迭代可供交付的内容,并检查它们的正确性
5)规划下一个迭代过程
6)交付给下一步骤,开始新的迭代过程
螺旋模型最重要的优势是随着成本的增加,风险程度随之降低
螺旋模型是风险导向的,对于任何无法逾越的风险你都可以预知
螺旋模型的惟一缺陷是它比较复杂,需要责任心、专注和管理方面的只是,通过确定目标和可以验证的里程碑,来决定你是不是已经准备好在“桂皮卷”上再加一层
是比较困难的
4,经过修改的瀑布模型
1)生鱼片模型(把阶段重叠起来的瀑布模型)
2)具有子项目的瀑布模型
3)能够降低风险的瀑布模型(需求分析和架构设计阶段采用螺旋模型)
5,渐进原型
在需求变化很快的时候、用户很难提出明确需求的时候、你和用户都不知道怎么才好的时候,渐进原型特别有用
最初概念->设计和实施最初原型->精化原型直到可以被接受->完成和交付原型
6,阶段交付
阶段交付的特点是不会再项目结束的时候一下交付全部软件,而是在项目整个开发过程中持续不断的交付阶段性成果
阶段交付和渐进原型不同,在阶段交付的时候,你明确地知道下一步要完成什么工作
软件概念->需求分析->架构设计->阶段1:详细设计,编码,调试,测试,交付->阶段2:详细设计,编码,调试,测试,交付...
阶段交付的主要缺点是,如果管理层面和技术层面上缺乏仔细的规划,工作就无法进行
7,面向进度的设计
软件概念->需求分析->架构设计->高优先级:详细设计,编码,调试,测试->中优先级:详细设计,编码,调试,测试...->交付
超出时间或费用: ->中优先级:详细设计,编码,调试,测试->低优先级:详细设计,编码,调试,测试
8,渐进交付
渐进原型和渐进交付的最大不同不在于基本方法,而在于其着重点
在渐进原型中,你最初强调的是系统的看得见的样子,然后回来堵住系统基础上的漏洞
在渐进交付中,你最初的重点是系统的核心,包括了不太可能因为用户反馈意见而改变的底层系统功能
软件概念->初步需求分析->架构和系统内核设计->
循环:开发一个版本->交付该版本->得到用户反馈->并入用户反馈
->交付最终版本
快速开发生命期模型和项目需求结合得十分紧密,最有效的模型的选择完全依据项目需求
第八章 估算
除非你很清楚地知道客户想要什么,否则你很难知道能否在期望时间段内建造客户想要的产品
估算步骤:
1,估算产品规模(代码行或功能点)
2,估算工作量(人月)
3,估算进度(日历月份)
4,提供某一范围内的估算,并且随着项目的进行,定期改进范围,以提供更高的精确度
第九章 进度计划
很多进度计划都过于乐观,原因是多方面的
不好的管理方法的表现之一是:当某件事进展缓慢时,应加倍地督促
进度压力与计划偏离间的恶性循环:
更大的进度压力->更重的负担->更多的错误->更加偏离进度计划->更大的进度压力...
坚持客观标准:
1,谈判不要局限于估算本身(指出不可实现进度计划的不合理之处并表示拒绝接受,才是真正的为客户利益着想)
2,坚持由专业组织进行进度估算
3,坚持科学的估算过程
4,顶住压力
第十章 面向客户开发
调查表明,项目成功的第一要素是用户的参与,造成项目完成时间延迟、成本超出预算、达不到预期功能的前三个因素分别是缺乏与用户沟通、需求说明不完备以及
中途变更需求说明
面向客户的开发方面对开发过程的影响:
1,计划
1)选择适当的生命期模型
2)弄清项目最终是让谁满意
3)建立有效的客户沟通渠道
4)力争采用双赢的解决方案
5)进行风险管理
2,需求分析
1)使用需求诱导方法帮助客户找出真正的需求
2)组成一个中心攻关组,帮助搞清用户到底需要什么
3)把用户使用软件的情况录在录像带上
4)进行客户满意度问卷调查,以便得到你同客户的关系的量度值
3,设计
在系统设计中应允许客户偶尔提出需求变更
4,实现
1)编写易读易改的代码,这能提高对客户需求变化的能力
2)采用诸如最短里程碑等进度监控方法,以便客户了解项目进度
3)选择一个能为用户提供稳定明显的进度标识的生命期模型
软件开发领域中的诸多问题,尤其是关于开发速度的争执,大都源于客户对项目持有的不现实的期望
作为开发人员,应尽量客观准确地设定自己的期望值,以免客户对进度计划或交付日期寄予不现实的希望
第十一章 激励机制
激励是决定工作表现最重要的影响因素
1,开发人员的典型动机
不同人员动机比较:
顺序 开发人员 项目管理人员 普通人
1 成就感 责任感 成就感
2 发展机遇 成就感 受认可程度
3 工作乐趣 工作乐趣 工作乐趣
4 个人生活 受认可程度 责任感
5 成为技术主管的机会 发展机遇 领先
6 领先 与下属关系 工资
7 同事间人际关系 同事间人际关系 发展机遇
8 受认可程度 领先 与下属关系
9 工资 工资 地位
10 责任感 操控能力 操控能力
11 操控能力 公司政策和经营 同事间人际关系
12 工作保障 工作保障 成为技术主管的机会
13 与下属关系 成为技术主管的机会 公司政策和经营
14 公司政策和经营 地位 工作条件
15 工作条件 个人生活 个人生活
16 地位 工作条件 工作保障
与管理人员相比,开发人员较少关系责任感或受认可程度
若要激励开发人员,更应强调技术挑战性、自主性、学习并使用新技能的机会、职业发展以及对他们私人生活的尊重等
踹一脚并不能产生动力,只能产生被动行为
为达到开发人员工作表现的最高级,不仅要让开发人员表面上动起来,更要调动其内在动力
要激发研发人员的创造力,就要为他们创造满足内在需求的环境
当被激发出创造力时,研发人员会投入时间和精力并享受其中
激励研发人员的最重要的5个因素是:成就感、发展机遇、工作乐趣、个人生活和成为技术主管的机会
其他激励因素:奖赏和鼓励、向导项目、对业绩的评价
士气杀手:
1,保健因素
2,管理操控
3,执行计划的压力
4,缺乏对开发而付出努力的表扬
5,因技术措施不当受到牵连
6,开发人员没有参与同自己有关的决策行为
7,生产率障碍
8,低质量
9,过分夸张的激励形式
微软非常关注员工士气。微软的每一个小组都有一份士气基金,可以做这个小组成员任何想做的事情。有些小组用它来买爆米花机;有些去滑雪,去打保龄球,或去
野餐,有些买T恤衫;还有的去看电影
在当地,微软被称为“高薪的血汗工厂”,这说明微软太会激励其员工了
第十二章 团队合作
并不仅仅是一组人恰巧在一起工作就可以构成一个团队
在“团队的智慧”一书中将团队定义为:能相互负责的、具有共同的目的、共同的执行目标和共同的方法的有互补技能的一些人
一个高业绩、定形的、有凝聚力的团队的特点:
1)共同的、可提升的愿景或目标
2)团队成员的认同感
3)结果驱动的结构
4)胜任的团队成员
5)对团队的承诺
6)相互信任
7)团队成员间相互依赖
8)有效的沟通
9)自主意识
10)授权意识
11)小的团队规模
12)高层次的享受
成功管理高凝聚力团队的关键:
1)建立一个愿景
2)创造变化
3)管理团队
4)以具有挑战性的、清楚的和支持的方式委派团队任务
5)将如何完成任务的细节留给团队,可能包括个人工作责任的分配
6)当团队运行得不好的时候,想想MOI模式:多数的团队问题来源于动机、组织或信息
团队为什么会失败:
1)缺乏共同的愿景
2)没有认同感
3)缺乏认可感
4)生产力障碍
5)低效率的沟通
6)缺乏信任
7)有问题的员工
团队领导实战指南:
1,避免团队目标向政治问题妥协
2,向团队目标显示个人的承诺
3,不用太多优先级的事物冲淡团队的工作
4,公平、公正地对待团队成员
5,愿意面对和解决与团队成员不良表现有关的问题
6,对来自员工的新思维和新信息采取开放的态度
团队成员实战指南:
1,展示对个人角色和责任的真实理解
2,展示目标和以事实为基础的判断
3,和其他团队成员有效地合作
4,使团队目标优先于个人目标
5,展示投身于任何项目成功所需的努力的愿望
6,愿意分享信息、感受和产生适当的反馈
7,当其他成员需要时给予适当的帮助
8,展示对自己的高标准要求
9,支持团队决策
10,展示直接面对重要问题的勇气和信念
11,以为团队的成功而奋斗的方式体现带头作用
12,对别人的反馈做出积极的反应
第十三章 团队结构
有效运行的团队设计特征:
1,明确的角色和责任
2,监控个人表现和提供反馈
3,有效的沟通
4,以事实为依据制定决策
第十四章 功能限定
1,项目早期:功能的简化
2,项目中期:功能蔓延的控制
3,项目后期:功能剪切
第十五章 生产率工具
工具遴选标准:
1,预计收益
2,供货商稳定性
3,质量
4,成熟度
5,培训时间
6,适用性
7,兼容性
8,发展规划
9,定制遴选标准
第十六章 项目修复
一般的修复方案:
1,缩减项目规模,以便在计划的时间与工作量内完成项目
2,把注意力放在短期的改善上,以提高过程的生产率
3,面对软件不可能按时完成的现实,放弃原计划,并着手准备危害控制,可能包括取消项目
本章要介绍的方式:
扔掉一些功能,尽量提升生产率,必要时抛弃原进度计划
理念:
如果你想改变现状的话,动作就要做大一点,而且马上去做。小修小补对整个开发组的士气不利,而且在管理层看来就仿佛你也不知道该怎么办一样。要想重新获取
控制权,采取断然行动要比长时间的小打小闹要好得多
修复计划:
1,第一步
1)评估你的处境
2)应用W-理论分析(平衡各方需要,使项目所有干系人都成为Winner)
3)自己作好修复项目的准备
4)问问你的开发组需要做什么
5)变得现实一些
2,人员
1)采取一切措施恢复开发组的士气
2)要确保你已为开发组创造了保健类因素
3)消除重大的人员问题
4)消除重大的领导问题
5)增加新手一定要审慎
6)充分利用开发人员的时间
7)允许开发组成员各有不同
8)观察开发人员的节奏
3,过程
1)修正明显支离破碎的开发过程
2)创建详细的小型里程碑
3)依据里程碑的完成来安排进度
4)细致地追踪进度进展状况
5)记录里程碑未完成的原因
6)短期后再调整--1周或2周
7)在得出有意义的进度前不要固守着某一个
8)进行风险管理要不辞辛劳
4,产品
1)稳定需求
2)修正特性集
3)评估你的政治地位
4)去除没有用的垃圾
5)降低缺陷数目,并要持续降低
6)达到一个可知的良好状态,并在此基础上继续
5,找准时机
如果项目的确已经陷入困境,建议你抓好展示修复计划的时机,以便让项目的其他人员有着充分的接受准备,项目成功也就有保障了
活动 小型项目 大型项目
总体/设计 10% 30%
详细设计 20% 20%
编码/测试 25% 10%
单元测试 20% 5%
综合测试 15% 20%
系统测试 10% 15%
软件项目的平衡三角:进度、费用、产品
实现快速开发的方法:
生命期计划
估算
进度计划
面向客户开发
激励
团队合作
团队结构
功能限定
生产力工具
项目校正
第七章 生命期计划
选择了适宜的生命期模型,就可以提高开发速度、提升质量、加强项目跟踪和控制、减少成本、降低风险,或是改善用户关系
错误地选择生命期模型,必定会导致工作拖沓、劳动重复、无畏的浪费和遭受挫折
1,纯瀑布模型
文档驱动,意味着主要工作成果是通过文档从一个阶段传递到下一个阶段
在纯瀑布模型中,各阶段不连续也不交迭
软件概念->需求分析->架构设计->详细设计->编码和测试->系统测试
当你有一个稳定的产品定义和很容易理解的技术解决方案时,纯瀑布模型特别合适
对于那些容易理解但很复杂的项目,采用纯瀑布模型比较适合,因为你可以用顺序的方法处理复杂的问题
当开发队伍的技术力量比较弱或者缺乏经验的时候,瀑布模型更为适宜
如果你采用瀑布模型,遗漏需求的时候是代价高昂的错误
瀑布模型最主要的问题是缺乏灵活性
2,编码修正模型
编码修正模型比较常见,如果你没有明确地选择其他生命期模型,也许你就会不自觉地进行编码,然后进行修改
编码修正模型的好处:一,它不需要什么成本,二,它只需要极少的专业知识
对于稍微大一点的项目,采用这种模型是很危险的
它虽然不需要什么成本,但是它也不提供评估项目进展情况的手段
3,螺旋模型
螺旋模型是一种以风险为导向的生命期模型,它把一个软件项目分解成一个个小项目
每个小项目都标识一个或多个主要风险因素,直到所有主要风险因素都被确认
螺旋模型的基本思路是,从一个小范围的关键中心地带开始寻找风险因素,制定风险控制计划,并交付给下一步骤,如此迭代
每次迭代都把项目扩展到一个更大的规模,每次迭代都包括以下六个步骤:
1)确定目标、方案和约束条件
2)识别并解决风险
3)评价备选方案
4)开发本次迭代可供交付的内容,并检查它们的正确性
5)规划下一个迭代过程
6)交付给下一步骤,开始新的迭代过程
螺旋模型最重要的优势是随着成本的增加,风险程度随之降低
螺旋模型是风险导向的,对于任何无法逾越的风险你都可以预知
螺旋模型的惟一缺陷是它比较复杂,需要责任心、专注和管理方面的只是,通过确定目标和可以验证的里程碑,来决定你是不是已经准备好在“桂皮卷”上再加一层
是比较困难的
4,经过修改的瀑布模型
1)生鱼片模型(把阶段重叠起来的瀑布模型)
2)具有子项目的瀑布模型
3)能够降低风险的瀑布模型(需求分析和架构设计阶段采用螺旋模型)
5,渐进原型
在需求变化很快的时候、用户很难提出明确需求的时候、你和用户都不知道怎么才好的时候,渐进原型特别有用
最初概念->设计和实施最初原型->精化原型直到可以被接受->完成和交付原型
6,阶段交付
阶段交付的特点是不会再项目结束的时候一下交付全部软件,而是在项目整个开发过程中持续不断的交付阶段性成果
阶段交付和渐进原型不同,在阶段交付的时候,你明确地知道下一步要完成什么工作
软件概念->需求分析->架构设计->阶段1:详细设计,编码,调试,测试,交付->阶段2:详细设计,编码,调试,测试,交付...
阶段交付的主要缺点是,如果管理层面和技术层面上缺乏仔细的规划,工作就无法进行
7,面向进度的设计
软件概念->需求分析->架构设计->高优先级:详细设计,编码,调试,测试->中优先级:详细设计,编码,调试,测试...->交付
超出时间或费用: ->中优先级:详细设计,编码,调试,测试->低优先级:详细设计,编码,调试,测试
8,渐进交付
渐进原型和渐进交付的最大不同不在于基本方法,而在于其着重点
在渐进原型中,你最初强调的是系统的看得见的样子,然后回来堵住系统基础上的漏洞
在渐进交付中,你最初的重点是系统的核心,包括了不太可能因为用户反馈意见而改变的底层系统功能
软件概念->初步需求分析->架构和系统内核设计->
循环:开发一个版本->交付该版本->得到用户反馈->并入用户反馈
->交付最终版本
快速开发生命期模型和项目需求结合得十分紧密,最有效的模型的选择完全依据项目需求
第八章 估算
除非你很清楚地知道客户想要什么,否则你很难知道能否在期望时间段内建造客户想要的产品
估算步骤:
1,估算产品规模(代码行或功能点)
2,估算工作量(人月)
3,估算进度(日历月份)
4,提供某一范围内的估算,并且随着项目的进行,定期改进范围,以提供更高的精确度
第九章 进度计划
很多进度计划都过于乐观,原因是多方面的
不好的管理方法的表现之一是:当某件事进展缓慢时,应加倍地督促
进度压力与计划偏离间的恶性循环:
更大的进度压力->更重的负担->更多的错误->更加偏离进度计划->更大的进度压力...
坚持客观标准:
1,谈判不要局限于估算本身(指出不可实现进度计划的不合理之处并表示拒绝接受,才是真正的为客户利益着想)
2,坚持由专业组织进行进度估算
3,坚持科学的估算过程
4,顶住压力
第十章 面向客户开发
调查表明,项目成功的第一要素是用户的参与,造成项目完成时间延迟、成本超出预算、达不到预期功能的前三个因素分别是缺乏与用户沟通、需求说明不完备以及
中途变更需求说明
面向客户的开发方面对开发过程的影响:
1,计划
1)选择适当的生命期模型
2)弄清项目最终是让谁满意
3)建立有效的客户沟通渠道
4)力争采用双赢的解决方案
5)进行风险管理
2,需求分析
1)使用需求诱导方法帮助客户找出真正的需求
2)组成一个中心攻关组,帮助搞清用户到底需要什么
3)把用户使用软件的情况录在录像带上
4)进行客户满意度问卷调查,以便得到你同客户的关系的量度值
3,设计
在系统设计中应允许客户偶尔提出需求变更
4,实现
1)编写易读易改的代码,这能提高对客户需求变化的能力
2)采用诸如最短里程碑等进度监控方法,以便客户了解项目进度
3)选择一个能为用户提供稳定明显的进度标识的生命期模型
软件开发领域中的诸多问题,尤其是关于开发速度的争执,大都源于客户对项目持有的不现实的期望
作为开发人员,应尽量客观准确地设定自己的期望值,以免客户对进度计划或交付日期寄予不现实的希望
第十一章 激励机制
激励是决定工作表现最重要的影响因素
1,开发人员的典型动机
不同人员动机比较:
顺序 开发人员 项目管理人员 普通人
1 成就感 责任感 成就感
2 发展机遇 成就感 受认可程度
3 工作乐趣 工作乐趣 工作乐趣
4 个人生活 受认可程度 责任感
5 成为技术主管的机会 发展机遇 领先
6 领先 与下属关系 工资
7 同事间人际关系 同事间人际关系 发展机遇
8 受认可程度 领先 与下属关系
9 工资 工资 地位
10 责任感 操控能力 操控能力
11 操控能力 公司政策和经营 同事间人际关系
12 工作保障 工作保障 成为技术主管的机会
13 与下属关系 成为技术主管的机会 公司政策和经营
14 公司政策和经营 地位 工作条件
15 工作条件 个人生活 个人生活
16 地位 工作条件 工作保障
与管理人员相比,开发人员较少关系责任感或受认可程度
若要激励开发人员,更应强调技术挑战性、自主性、学习并使用新技能的机会、职业发展以及对他们私人生活的尊重等
踹一脚并不能产生动力,只能产生被动行为
为达到开发人员工作表现的最高级,不仅要让开发人员表面上动起来,更要调动其内在动力
要激发研发人员的创造力,就要为他们创造满足内在需求的环境
当被激发出创造力时,研发人员会投入时间和精力并享受其中
激励研发人员的最重要的5个因素是:成就感、发展机遇、工作乐趣、个人生活和成为技术主管的机会
其他激励因素:奖赏和鼓励、向导项目、对业绩的评价
士气杀手:
1,保健因素
2,管理操控
3,执行计划的压力
4,缺乏对开发而付出努力的表扬
5,因技术措施不当受到牵连
6,开发人员没有参与同自己有关的决策行为
7,生产率障碍
8,低质量
9,过分夸张的激励形式
微软非常关注员工士气。微软的每一个小组都有一份士气基金,可以做这个小组成员任何想做的事情。有些小组用它来买爆米花机;有些去滑雪,去打保龄球,或去
野餐,有些买T恤衫;还有的去看电影
在当地,微软被称为“高薪的血汗工厂”,这说明微软太会激励其员工了
第十二章 团队合作
并不仅仅是一组人恰巧在一起工作就可以构成一个团队
在“团队的智慧”一书中将团队定义为:能相互负责的、具有共同的目的、共同的执行目标和共同的方法的有互补技能的一些人
一个高业绩、定形的、有凝聚力的团队的特点:
1)共同的、可提升的愿景或目标
2)团队成员的认同感
3)结果驱动的结构
4)胜任的团队成员
5)对团队的承诺
6)相互信任
7)团队成员间相互依赖
8)有效的沟通
9)自主意识
10)授权意识
11)小的团队规模
12)高层次的享受
成功管理高凝聚力团队的关键:
1)建立一个愿景
2)创造变化
3)管理团队
4)以具有挑战性的、清楚的和支持的方式委派团队任务
5)将如何完成任务的细节留给团队,可能包括个人工作责任的分配
6)当团队运行得不好的时候,想想MOI模式:多数的团队问题来源于动机、组织或信息
团队为什么会失败:
1)缺乏共同的愿景
2)没有认同感
3)缺乏认可感
4)生产力障碍
5)低效率的沟通
6)缺乏信任
7)有问题的员工
团队领导实战指南:
1,避免团队目标向政治问题妥协
2,向团队目标显示个人的承诺
3,不用太多优先级的事物冲淡团队的工作
4,公平、公正地对待团队成员
5,愿意面对和解决与团队成员不良表现有关的问题
6,对来自员工的新思维和新信息采取开放的态度
团队成员实战指南:
1,展示对个人角色和责任的真实理解
2,展示目标和以事实为基础的判断
3,和其他团队成员有效地合作
4,使团队目标优先于个人目标
5,展示投身于任何项目成功所需的努力的愿望
6,愿意分享信息、感受和产生适当的反馈
7,当其他成员需要时给予适当的帮助
8,展示对自己的高标准要求
9,支持团队决策
10,展示直接面对重要问题的勇气和信念
11,以为团队的成功而奋斗的方式体现带头作用
12,对别人的反馈做出积极的反应
第十三章 团队结构
有效运行的团队设计特征:
1,明确的角色和责任
2,监控个人表现和提供反馈
3,有效的沟通
4,以事实为依据制定决策
第十四章 功能限定
1,项目早期:功能的简化
2,项目中期:功能蔓延的控制
3,项目后期:功能剪切
第十五章 生产率工具
工具遴选标准:
1,预计收益
2,供货商稳定性
3,质量
4,成熟度
5,培训时间
6,适用性
7,兼容性
8,发展规划
9,定制遴选标准
第十六章 项目修复
一般的修复方案:
1,缩减项目规模,以便在计划的时间与工作量内完成项目
2,把注意力放在短期的改善上,以提高过程的生产率
3,面对软件不可能按时完成的现实,放弃原计划,并着手准备危害控制,可能包括取消项目
本章要介绍的方式:
扔掉一些功能,尽量提升生产率,必要时抛弃原进度计划
理念:
如果你想改变现状的话,动作就要做大一点,而且马上去做。小修小补对整个开发组的士气不利,而且在管理层看来就仿佛你也不知道该怎么办一样。要想重新获取
控制权,采取断然行动要比长时间的小打小闹要好得多
修复计划:
1,第一步
1)评估你的处境
2)应用W-理论分析(平衡各方需要,使项目所有干系人都成为Winner)
3)自己作好修复项目的准备
4)问问你的开发组需要做什么
5)变得现实一些
2,人员
1)采取一切措施恢复开发组的士气
2)要确保你已为开发组创造了保健类因素
3)消除重大的人员问题
4)消除重大的领导问题
5)增加新手一定要审慎
6)充分利用开发人员的时间
7)允许开发组成员各有不同
8)观察开发人员的节奏
3,过程
1)修正明显支离破碎的开发过程
2)创建详细的小型里程碑
3)依据里程碑的完成来安排进度
4)细致地追踪进度进展状况
5)记录里程碑未完成的原因
6)短期后再调整--1周或2周
7)在得出有意义的进度前不要固守着某一个
8)进行风险管理要不辞辛劳
4,产品
1)稳定需求
2)修正特性集
3)评估你的政治地位
4)去除没有用的垃圾
5)降低缺陷数目,并要持续降低
6)达到一个可知的良好状态,并在此基础上继续
5,找准时机
如果项目的确已经陷入困境,建议你抓好展示修复计划的时机,以便让项目的其他人员有着充分的接受准备,项目成功也就有保障了
发表评论
-
也论TDD
2010-05-20 12:36 1339写这篇短文的原因是: 1,公司内部最近在讨论十条不错的编程观点 ... -
《产品经理实战手册》笔记一
2009-07-24 10:59 2153一、认识产品经理 1, ... -
读《唐骏:我的成功可以复制》
2009-02-20 16:38 4699唐骏可谓中国第一职业 ... -
《快速软件开发》笔记三,最佳实践
2009-02-09 17:07 3192变更委员会 变更委员会是控制软件产品变更的一种措施 通过提高性 ... -
读《修炼:我的职场十年》
2009-02-05 18:28 2853果敢 事情是干出来的,不是想出来的 尊重 真正平等地与人相处 ... -
《快速软件开发》笔记一,有效开发
2009-02-01 17:15 3335序 调查表明,大约70%的软件开发项目超出了估算的时间,大型项 ... -
FREEWHEEL OPERATION JOB SPEC
2008-10-17 14:27 2167Job Title: Network/System Engi ... -
《Project 宝典》笔记1,理解项目
2008-05-28 17:46 1605《Project 宝典》笔记1,理解项目 什么是项目 项目是 ... -
《从优秀到卓越》4-6章笔记
2008-05-28 15:56 2419《从优秀到卓越》4-6章笔记 第四章 直面残酷的现实(但决不 ... -
《从优秀到卓越》1-3章笔记
2008-05-19 18:57 1797第一章 优秀是卓越的大 ... -
糗大了
2008-04-08 10:33 1733早上outlook看到一封会议通知,早上10点的 于是到了1 ... -
怎样做Sprint Plan?
2008-04-03 17:55 2124利用Microsoft Office Project,我们可以 ... -
SCRUM、XP、RUP与Agile的关系
2008-04-01 12:27 76541,什么是Agile? http://www.ruby-lan ... -
拥抱混合语言开发
2008-01-18 03:54 2183Web开发2.0大会上陈金洲的这篇混合语言开发确实说出了构建大 ... -
svn 命令再学两招
2008-01-17 12:08 1488diff svn diff -r1234:1235 > ... -
项目开发工具集
2007-09-13 13:02 2084Aragon: IM:MSN SCM:SVN Project ... -
总结的一些项目管理和软件方法
2007-07-24 15:23 6400鲁迅先生弃医从文,为的是根治民族劣根性,因为即使鲁迅先生的医术 ...
相关推荐
这份"软件开发学习笔记"涵盖了多个编程语言和技术领域,如C#、Delphi、VB.NET以及DLL库的开发,还包含了ICCO Development Help的相关资料,旨在帮助学习者深入理解软件开发的核心概念和实践技巧。 首先,C#是一种...
【软件开发】是一个涵盖广泛领域的概念,涉及到计算机科学与工程中的多个方面,是将需求、设计、编程、测试和维护等多个步骤整合在一起的过程,旨在创建高效、可靠且用户友好的软件产品。在研究生课程中,软件开发的...
【标题】:“笔记:个人软件开发笔记” 在个人软件开发过程中,笔记的记录至关重要,它可以帮助开发者系统地整理思路,回顾技术细节,以及追踪项目的进展。这个“笔记:个人软件开发笔记”很可能是某位开发者关于...
【MLX90640开发笔记】是关于如何使用MLX90640热成像仪进行软件开发的详细教程。MLX90640是一款高性能的红外热成像传感器,常用于各种环境监测、设备检测以及科研应用。在开始开发前,开发者需要准备必要的开发资料,...
演化模型的优点是能够快速响应用户的需求变化,提高软件开发的灵活性和适应性。 软件工程是一个复杂的系统工程,它涉及到软件开发的各个方面,包括软件危机、软件工程概念、软件开发方法学、软件开发模型、软件生存...
Eclipse插件开发学习笔记将带领我们深入了解Eclipse插件开发的方方面面。 首先,我们需要了解Eclipse插件的基础概念。在Eclipse中,插件主要由一系列的扩展点(Extension Points)组成,这些扩展点定义了插件可以...
这篇笔记主要涵盖了软件开发的基本概念、流程和技术,旨在帮助初学者和有经验的开发者巩固和提升在软件开发领域的知识。通过阅读这些笔记,你可以深入了解软件开发的各个环节,包括需求分析、设计、编码、测试以及...
8. **未来趋势和挑战**:预测电子政务软件开发的未来发展方向,如云计算、大数据分析、人工智能等新技术的应用,以及可能面临的挑战,如技术更新快速、信息安全威胁等。 通过学习这份资料,读者不仅可以了解到电子...
金蝶EAS_BOS开发学习笔记是针对金蝶企业应用套件(Enterprise Application Suite, EAS)中的业务操作服务(Business Operation Service, BOS)进行深入解析的学习资料。EAS是金蝶公司推出的一款高端企业管理软件,...
用户在记录笔记的过程中,如果遇到需要查询的信息,无需离开软件界面,可以直接通过内置的搜索引擎快速查找相关资料,将获取到的信息整合到笔记中。这一功能尤其适用于研究型工作或者学习,它使得信息获取和整理的...
总之,"基于Markdown语言的快速笔记软件,QT框架开发.zip"是一个结合了Markdown文本编辑和QT跨平台开发的项目,使用C++编程语言,为用户提供便捷的Markdown笔记创建和管理体验。开发者可以通过这个项目学习到如何...
### 软件工程课程笔记知识点详解 #### 一、软件生命周期 ...以上内容涵盖了《软件工程》课程的核心知识点,通过对这些知识点的学习和理解,可以帮助学生更好地掌握软件开发的整个过程,提高软件开发的质量和效率。
敏捷软件开发是现代软件工程领域的一项重要实践,它倡导快速迭代、持续集成和对变化的迅速响应。敏捷软件开发的主要目的在于提高软件质量和交付速度,同时更好地满足客户需求和应对变化。敏捷开发的核心是一系列原则...
### ARM开发笔记——经验体会总结 #### 一、ARM的发展趋势及市场需求 ARM技术近年来的发展势头迅猛,成为了嵌入式领域的重要组成部分。嵌入式系统按照功能和应用场景的不同大致可以分为四类:传统微控制器(如51、...
快速原型模型是软件开发过程中的另一种模型,迅速建造一个可以运行的软件原型,以便理解和澄清问题,使开发人员与用户达成共识,最终在确定的客户需求基础上开发客户满意的软件产品。快速原型模型允许在需求分析阶段...
- **定义**:一种以快速迭代和持续改进为核心理念的软件开发方法。 - **基本原则** - **客户紧密参与**:确保需求始终与客户期望一致。 - **拥抱变化**:灵活调整计划以适应变化。 - **增量交付**:分阶段交付...
总的来说,【达内开发笔记】是一份全面的IT技术学习资料,不仅覆盖了各种编程语言和技术框架的基础知识,还包含了软件开发过程中的重要实践环节,对于提升开发者的技能水平和解决实际问题的能力有着极大的帮助。...
源码是软件开发的基础,通过对源码的学习和理解,开发者可以深入掌握软件的设计理念、架构和实现方式,甚至进行二次开发或定制化改造。 在这款笔记软件源码中,我们可以探索以下几个关键知识点: 1. **数据管理**...
这篇开发笔记提供了全面的指导,帮助开发者深入理解这一复杂的领域。 首先,让我们从“嵌入式”这一概念开始。嵌入式系统是指嵌入到其他设备中的计算机系统,它们通常执行特定的功能,如控制家用电器、汽车电子设备...