人本开发课件.pptVIP

人本工程 精品文档 人本工程 人本需求 人本设计 人本编码 精品文档 人本需求 获取用户需求是软件工程的第一步 从用户那里获取软件需求的一般过程： 反复同用户交流 从无到有的建立起软件蓝图 将需求和软件蓝图记录下来并文档化 精品文档 人本需求 需求活动中最需要关注的人的特点： 学习是曲线上升的过程 开发者肯定要犯错误 精品文档 人本需求 学习是曲线上升的过程 人对需求的理解过程实际是学习的过程 学海无涯，没有绝对意义上的需求终点 需求的理解不是直线上升的,是曲线 精品文档 人本需求 回忆我们进行过的需求活动，需求的学习过程会经历三个阶段 第一阶段，入门 第二阶段，顿悟 第三阶段，遭遇瓶颈 精品文档 人本需求 时刻牢记入门阶段的存在，并力求缩短达到第一阶段的时间 预留时间让需求人员适应业务领域 开展类似于预习的预调研 保持第二阶段的稳定增长 经常性的总结可以巩固已获取的需求。例如组织讨论、迭代的开展需求分析工作…… 控制调研节奏，避免填鸭式的被动接受需求 以潜在的时间作为需求终点，并冻结需求 避免在需求阶段毫无意义的浪费时间 精品文档 人本需求 人无完人，开发者肯定要犯错误 需求中存在盲点，且盲点无法完全消除 一般的需求理解过程 精品文档 人本需求 承认需求中必然存在缺陷是解决问题的前提 要争取提前暴露缺陷，而不要把需求缺陷留到最后 需求评审 迭代开发 加强后续工作的反馈 准备出一定的时间在项目最后解决需求的缺陷 精品文档 人本需求 非人性化的需求过程： 在经历漫长的立项阶段后，派遣一批人直接进入客户现场展开调研 粗暴的按照部门或者功能点划分任务。例如每两天调研一个部门 调研时像学生一样的听客户讲解业务、需求，并一丝不漏的记录下来 精品文档 人本设计 设计过程将需求中的软件蓝图转化为概念模型 高层设计经常会经过长时间的思考，一定的讨论，得出简洁的结果 精品文档 人本设计 在设计过程中，我们需要重点考虑： 学习是曲线上升的过程 对外界干扰反映强烈 人无完人，开发者肯定要犯错误 精品文档 人本设计 学习是曲线上升的过程 设计过程是学习和创造过程的混合 如果设计人员没有参与需求，那就一定要让他先充分的理解需求 除需求外，对设计方法的学习也是需要考虑的因素 可以把两个学习过程结合起来，缩短整个周期 精品文档 人本设计 对外界干扰反映强烈 办公环境 理想和现实总是存在巨大的差距 起码要进行最基本的环境准备 阻止外部对设计人员的骚扰 各种无聊的会议 临时的外借 建立良好的沟通渠道 同需求人员的沟通 设计人员之间的沟通 精品文档 人本设计 人无完人，开发者肯定要犯错误 同需求的结果一样，我们的设计基本上是漏洞百出 把千疮百孔的设计直接转化为代码的后果不堪设想 缩小问题域可以化繁为简，降低缺陷率 例如FDD中将系统划分为特征列表 评审是一种减少设计缺陷的好方法 精品文档 人本设计 非人性化设计过程 让设计人员根据自己的理解将需求转化为设计 在设计过程中经常被打断 孤军奋战，找不到任何可以讨论的人，这样的设计只有跟着感觉走了。 画UML图用了一个小时，其中有四十分钟在聆听硬盘噪声中等待 精品文档 人本编码 在编码过程中，我们需要重点考虑： 学习曲线 个体生产率不稳定 个体间的生产率差距更明显 对外界的干扰反映强烈 人无完人，开发者肯定要犯错误 除了天生的工作狂，开发者都有惰性 精品文档 人本编码 学习曲线 在编码工作中，学习曲线体现的并不明显，但如果引入了新的开发框架、开发语言等技术时，需要关注编码人员的学习过程。 精品文档 人本编码 个体生产率不稳定 个体生产率不稳定在编码阶段体现的相对严重，同样的编码人员在不同情况下差异可能很大。 在枯燥的编码工作中，项目经理需要经常性激励团队士气，尤其在遇到困难的时候 一鼓作气、再而衰、三而竭 “不以物喜不以己悲”的项目经理更容易保持团队心态的稳定和平衡 张弛有度的工作安排有助于稳定的工作进展 编码人员往往更关注能够在开发中学到什么而不是做到什么 加班，未必是士气的毒药，但长期加班绝对项目进度对有害无益。 精品文档 人本编码 个体间的生产率差距更明显 高级软件工程师物有所值，在预算允许的前提下，增加这方面的投入 在有效的培训下，普通的软件工程师也会有不俗的表现 导师制 培训紧贴项目，增加培训的实用性 培训过程中增加反馈和考核，强化培训效果 把长期培训拆成若干部分，每完成一部分马上投入实战 友情提醒：除非项目经理有极高的个人魅力，否则还是不要带一只“皇马”似的队伍。 精品文档 人本编码 合理团队比例 一名技术核心，作为团队的灵魂 1/3的成员是高级软件工程师，具有很强的独立解决问题的能力 其余的是普通软件工程师，在培训和榜样的力量下，能够发挥重要的作用 精品文档 人本编码 对外界干扰反映强烈