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