开发者肯定要犯错误-Read.PPT

人本开发 复旦金仕达计算机有限公司 CSAI顾问团专业顾问 rongxi@ 序 “焦油坑” 史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼…… ——《人月神话》 与我们一起挣扎的还有软件工程的理论和项目管理的方法 当“项目”遇到了“软件” 软件开发的各项技术都不成熟 软件开发距离“机器化大生产”还有漫长的道路 软件项目的重要干系人——客户——也不成熟 人——开发的灵魂 人，创造了软件中的一切，是开发的灵魂 软件开发者不同于其他的工程建造者，有着自己的特性 不考虑开发者的特性很难高效的达到目标 工程·管理·人 工程视点 分析 设计 实现 验证 管理视点 计划 跟踪 …… 人本视点 学习是曲线上升的过程 个体生产率不稳定 个体间的生产率差距更明显 对外界的干扰反映强烈 人无完人，开发者肯定要犯错误 除了天生的工作狂，开发者都有惰性 具有主观能动性 成就感和可预见的个人发展是对开发者最好的激励 系统视点 工程、管理和人之间充满了错综复杂的关系，他们共同构成了软件开发过程这个大系统 这三种类型的系统单元的变化会直接影响到其他单元，激励或抑制 不可能孤立的改变其中一部分而不影响其他部分 只见树木不见森林的做法经常造成更大的负面影响 人本工程 人本工程 人本需求 人本设计 人本编码 人本需求 获取用户需求是软件工程的第一步 从用户那里获取软件需求的一般过程： 反复同用户交流 从无到有的建立起软件蓝图 将需求和软件蓝图记录下来并文档化 人本需求 需求活动中最需要关注的人的特点： 学习是曲线上升的过程 开发者肯定要犯错误 人本需求 学习是曲线上升的过程 人对需求的理解过程实际是学习的过程 学海无涯，没有绝对意义上的需求终点 需求的理解不是直线上升的,是曲线 人本需求 回忆我们进行过的需求活动，需求的学习过程会经历三个阶段 第一阶段，入门 第二阶段，顿悟 第三阶段，遭遇瓶颈 人本需求 时刻牢记入门阶段的存在，并力求缩短达到第一阶段的时间 预留时间让需求人员适应业务领域 开展类似于预习的预调研 保持第二阶段的稳定增长 经常性的总结可以巩固已获取的需求。例如组织讨论、迭代的开展需求分析工作…… 控制调研节奏，避免填鸭式的被动接受需求 以潜在的时间作为需求终点，并冻结需求 避免在需求阶段毫无意义的浪费时间 人本需求 人无完人，开发者肯定要犯错误 需求中存在盲点，且盲点无法完全消除 人本需求 承认需求中必然存在缺陷是解决问题的前提 要争取提前暴露缺陷，而不要把需求缺陷留到最后 需求评审 迭代开发 加强后续工作的反馈 准备出一定的时间在项目最后解决需求的缺陷 人本需求 非人性化的需求过程： 在经历漫长的立项阶段后，派遣一批人直接进入客户现场展开调研 粗暴的按照部门或者功能点划分任务。例如每两天调研一个部门 调研时像学生一样的听客户讲解业务、需求，并一丝不漏的记录下来 人本设计 设计过程将需求中的软件蓝图转化为概念模型 高层设计经常会经过长时间的思考，一定的讨论，得出简洁的结果 人本设计 在设计过程中，我们需要重点考虑： 学习是曲线上升的过程 对外界干扰反映强烈 人无完人，开发者肯定要犯错误 人本设计 学习是曲线上升的过程 设计过程是学习和创造过程的混合 如果设计人员没有参与需求，那就一定要让他先充分的理解需求 除需求外，对设计方法的学习也是需要考虑的因素 可以把两个学习过程结合起来，缩短整个周期 人本设计 对外界干扰反映强烈 办公环境 理想和现实总是存在巨大的差距 起码要进行最基本的环境准备 阻止外部对设计人员的骚扰 各种无聊的会议 临时的外借 建立良好的沟通渠道 同需求人员的沟通 设计人员之间的沟通 人本设计 人无完人，开发者肯定要犯错误 同需求的结果一样，我们的设计基本上是漏洞百出 把千疮百孔的设计直接转化为代码的后果不堪设想 缩小问题域可以化繁为简，降低缺陷率 例如FDD中将系统划分为特征列表 评审是一种减少设计缺陷的好方法 人本设计 非人性化设计过程 让设计人员根据自己的理解将需求转化为设计 在设计过程中经常被打断 孤军奋战，找不到任何可以讨论的人，这样的设计只有跟着感觉走了。 画UML图用了一个小时，其中有四十分钟在聆听硬盘噪声中等待 人本编码 在编码过程中，我们需要重点考虑： 学习曲线 个体生产率不稳定 个体间的生产率差距更明显 对外界的干扰反映强烈 人无完人，开发者肯定要犯错误 除了天生的工作狂，开发者都有惰性 人本编码 学习曲线 在编码工作中，学习曲线体现的并不明显，但如果引入了新的开发框架、开发语言等技术时，需要关注编码人员的学习过程。 人本编码 个体生产率不稳定 个体生产率不稳定在编码阶段体现的相对严重，同样的编码人员在不