《项目问题讨论》PPT课件.ppt

敏捷开发 分享交流 本次介绍的目标 问题思考 技术债务 scrum上路 项目初期制定一系列计划 要求在一定时间范围内完成计划的功能 而事实往往是项目交付周期延期 问题思考 交付延期 计划赶不上变化 缺乏与客户一定的沟通反馈 交付产品的时间阶段比较长 客户看到系统后 又新增需求或变更需求 疏远 太多的会议等烦杂事情要处理 导致整个项目实际的工作脱节 太理想化 开始计划时就要求一定完成哪些功能 在项目开发中 有时候会发现在重复做一些工作 需求经常变化 问题思考 重复工作 没有完全理解客户的需求 挖掘客户的潜在需求 开发与需求人员没有沟能好 没有共同参与需求 技术的支撑没有完全应变尽可能需求带来的变化 开发人员紧密的开发完成一个项目后 发现没有获取更多的学习机会和技能 问题思考 个人成长 没有更多的参与至项目中 缺少主动性 参与性 相互沟通较少 混乱 没有任何时间变得有条理 没有时间学习新的知识 因为一直都在忙这忙那 学习 缺乏自我学习 没有自我管理的升华 团队内缺少技能培训 知识共享 项目中经常出现的问题不是大问题 而是无数的小问题 有时这些只是一些为了方便而使用的捷径 开发时添加硬编码 设定魔鬼数字等 有时开发人员仅仅是不熟悉这中语言 有时代码跟灌木丛一样凌乱 需要大幅度的修整 所有这些都属于 技术债务 如果我们没有很好地管理并设法降低这些 技术债务 那么 程序编写和维护的代价最终将会超过它对客户的价值 开发团队拖延债务的时间越长 所积累的问题就会越多 会额外增加很多工作 付出的成本也就越高 另外 这还增加了实际的财务支出 开发团队处理技术债务所花费的时间 可以用在对团队有价值的其它工作上 同时 这些难读的代码引起的技术债务也让我们难以找到软件的缺陷 再且 理解代码所损失的时间还可以用来做其它更有价值的事情呢 技术债务是个累赘 它会扼杀生产力 使维护工作变得麻烦 困难甚至在某些情况下无法实施 技术债务会逐渐使整个团队的吞吐量越来越少 什么是 技术债务 债务清偿 更改成本曲线 是否该清偿技术债务 这样的问题 答案当然是肯定的 技术债务会逐渐减慢前进的步伐 因而阻碍实现目标 有一种非常著名的更改成本曲线 其中显示了100 质量测试驱动方法与 怀揣胶带边漏边补的冒进方法 之间的区别 简单易行的高质量设计可能初始成本较高 但产生的技术债务较少 因而随着时间的推移 对代码进行后续添加或修改的成本相对较低 在质量曲线 蓝色 上 可以看到初始成本较高 但长期的成本是可预测的 冒进 曲线 红色 的进入成本较低 但后期开发 维护以及产品和代码的总体拥有成本都会越来越高 没有经验的开发人员 技术债务来自哪里 项目工期的压力 凌乱而难读的代码 专业领域的代码 过度复杂 糟糕的设计 让开发人员接受语言方面的基本培训并教授他们面向对象的原理 从而把他们的理解力提升至入门阶段 解决技术债务 让团队成员 管理人员知道解决当前的这些问题都是需要花费时间 精力 代价 提供一些培训 包括代码的坏味道 重构 单元测试和测试驱动开发等 在工作的时候 给予空余时间去研究和练习技能 使用工具 静态分析 单元测试 持续集成 自动化可接受性测试 来帮助团队发现 减少和衡量他们的技术债务量 解决技术债务 建立一些基础的开发规范 从设计 编码 测试等 定期举行一些关于技术方面的学习型会议 利用这些会议来促进开发成员之间的讨论 维护关于技术债务的备忘录 任何时候 如果开发中发现一些无法立即应付的技术债务时 就需要填写一份技术债务登记卡