项目问题讨论.ppt

《项目问题讨论.ppt》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、敏捷开发——分享交流本次介绍的目标21问题思考技术债务scrum上路3项目初期制定一系列计划，要求在一定时间范围内完成计划的功能，而事实往往是项目交付周期延期问题思考-交付延期计划赶不上变化缺乏与客户一定的沟通反馈，交付产品的时间阶段比较长，客户看到系统后，又新增需求或变更需求疏远。太多的会议等烦杂事情要处理，导致整个项目实际的工作脱节太理想化。开始计划时就要求一定完成哪些功能在项目开发中，有时候会发现在重复做一些工作，需求经常变化问题思考-重复工作没有完全理解客户的需求、挖掘客户的潜在需求开发与需求人员没有沟能好

2、，没有共同参与需求技术的支撑没有完全应变尽可能需求带来的变化开发人员紧密的开发完成一个项目后，发现没有获取更多的学习机会和技能问题思考-个人成长没有更多的参与至项目中缺少主动性、参与性，相互沟通较少混乱。没有任何时间变得有条理，没有时间学习新的知识，因为一直都在忙这忙那学习。缺乏自我学习，没有自我管理的升华，团队内缺少技能培训、知识共享项目中经常出现的问题不是大问题，而是无数的小问题。有时这些只是一些为了方便而使用的捷径（开发时添加硬编码、设定魔鬼数字等），有时开发人员仅仅是不熟悉这中语言，有时代码跟灌木丛一样凌乱

3、，需要大幅度的修整。所有这些都属于“技术债务”。如果我们没有很好地管理并设法降低这些“技术债务”，那么，程序编写和维护的代价最终将会超过它对客户的价值。开发团队拖延债务的时间越长，所积累的问题就会越多(会额外增加很多工作)，付出的成本也就越高。另外，这还增加了实际的财务支出：开发团队处理技术债务所花费的时间，可以用在对团队有价值的其它工作上。同时，这些难读的代码引起的技术债务也让我们难以找到软件的缺陷。再且，理解代码所损失的时间还可以用来做其它更有价值的事情呢。技术债务是个累赘：它会扼杀生产力，使维护工作变得麻烦、

4、困难甚至在某些情况下无法实施。技术债务会逐渐使整个团队的吞吐量越来越少。什么是“技术债务”？债务清偿-更改成本曲线“是否该清偿技术债务”这样的问题，答案当然是肯定的。技术债务会逐渐减慢前进的步伐，因而阻碍实现目标。有一种非常著名的更改成本曲线，其中显示了100%质量测试驱动方法与“怀揣胶带边漏边补的冒进方法”之间的区别简单易行的高质量设计可能初始成本较高，但产生的技术债务较少，因而随着时间的推移，对代码进行后续添加或修改的成本相对较低。在质量曲线（蓝色）上，可以看到初始成本较高，但长期的成本是可预测的。“冒进”曲线

5、（红色）的进入成本较低，但后期开发、维护以及产品和代码的总体拥有成本都会越来越高。没有经验的开发人员技术债务来自哪里？项目工期的压力凌乱而难读的代码专业领域的代码过度复杂糟糕的设计让开发人员接受语言方面的基本培训并教授他们面向对象的原理，从而把他们的理解力提升至入门阶段解决技术债务让团队成员、管理人员知道解决当前的这些问题都是需要花费时间、精力、代价提供一些培训，包括代码的坏味道，重构，单元测试和测试驱动开发等在工作的时候，给予空余时间去研究和练习技能使用工具（静态分析，单元测试，持续集成，自动化可接受性测试）来帮

6、助团队发现、减少和衡量他们的技术债务量解决技术债务建立一些基础的开发规范，从设计、编码、测试等定期举行一些关于技术方面的学习型会议。利用这些会议来促进开发成员之间的讨论维护关于技术债务的备忘录–任何时候，如果开发中发现一些无法立即应付的技术债务时，就需要填写一份技术债务登记卡提高了团队成员的技能结果、意义软件的代码质量会不断改善软件缺陷的数目也会不断减少很好的提高团队的整体开发能力债务已经开始下降了角色-技术技能表角色技术技能（在不同的方面）行为技能开发人员单元测试（工具——NUnit、JUnit）代码覆盖率的概念

7、和工具代码审查的概念和工具持续集成工具重构的概念代码味道的概念Scrum过程沟通、合作、时间管理/计划、思维、冲突管理、处理更改/灵活性、决策、团队合作/团队建设、处理压力、问题解决、领导、外交QA“完成”的定义—>验收标准测试管理自动化/脚本环境设置数据库概念与开发人员相同ScrumMasterScrum过程、模板和使用、项目管理工具、持续集成工具、设置开发环境开发人员的技能+推动力