如何在新产品中应用敏捷.pptxVIP

如何在新产品中应用敏捷第1页/共55页 The following presentation represents values of a practitioner of agile methodology.It is personal. If there are something same to that, it is coincidental. 以下分享内容代表了一个敏捷实践者的观点，纯属一家之言，如有巧合，实属雷同！第2页/共55页 Agenda 我们的困惑 敏捷简介 如何实施敏捷第3页/共55页 这个功能貌似不是特别重要？是呀，还花这么多时间！第4页/共55页 这个功能不是这样的哟？杯具了！！@#￥%……第5页/共55页 这需求从哪里冒出来的？@#￥%……去你的！啊，我一定会回来的！第6页/共55页 这不是我想要的，重做！@#￥%……第7页/共55页 项目最近进展如何？@#￥%……第8页/共55页 效率太低，效率太低！第9页/共55页 加油！干巴爹！Fighting！第10页/共55页 面临的问题如何保证团队在做正确的事？如何快速响应变化？如何让信息透明？如何让团队保持激情？如何改进工作？如何保证团队目标一致？第11页/共55页 Agenda 我们的困惑 敏捷简介 如何实施敏捷第12页/共55页 历史敏捷一词来源于2001年初美国犹他州雪鸟滑雪圣地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会Kent BeckJames GrenningRobert C. MartinMike BeedleJim HighsmithSteve MellorArie van BennekumAndrew HuntAlistair CockburnRon Jeffries Jeff SutherlandWard CunninghamJon KernDave ThomasMartin FowlerBrian MarickKen Schwaber第13页/共55页 敏捷宣言个体与交互胜过过程和工具可用的软件完备的文档胜过客户协作合同谈判胜过响应变化遵循计划胜过第14页/共55页 敏捷宣言个体与交互胜过过程和工具可用的软件完备的文档客户协作合同谈判响应变化遵循计划胜过胜过胜过虽然右项也具有价值，但我们认为左项具有更大的价值。第15页/共55页 敏捷开发的原则即使到了开发的后期，也欢迎需求变更频繁交付可工作的软件关注协作，业务人员和开发人员必须每天协同工作首要目标：更早地持续地交付有价值的软件，满足客户需求围绕被激励起来的个人来构建项目面对面的交谈，是最有效和效率最高的沟通方法第16页/共55页 可工作的软件是度量进度的主要标准敏捷过程提倡可持续的开发速度持续地优化技术和设计，会增强敏捷能力简单--使工作效率最大化的艺术--是基本原则最好的构架、需求和设计，出自自组织团队定期总结回顾，思考团队如何更加高效，并作出相应调整敏捷开发的原则第17页/共55页 价值观沟通 - 建模不但能够促进你团队内部的开发人员之间沟通、还能够促进你的团队和你的project stakeholder之间的沟通简单 - 画一两张图表来代替几十甚至几百行的代码，通过这种方法，建模成为简化软件和软件（开发）过程的关键。这一点对开发人员而言非常重要－它简单，容易发现出新的想法，随着你（对软件）的 理解的加深，也能够很容易的改进。反馈 - Kent Beck在Extreme Programming Explained中有句话讲得非常好：“乐观是编程的职业病，反馈则是其处方。”通过图表来交流你的想法，你可以快速获得反馈，并能够按照建议行事。勇气 - 勇气非常重要，当你的决策证明是不合适的时候，你就需要做出重大的决策，放弃或重构（refactor） 你的工作，修正你的方向。谦逊 - 最优秀的开发人员都拥有谦逊的美德，他们总能认识到自己并不是无所不知的。事实上，无论是开发人员还是客户，甚至所有的 project stakeholder，都有他们自己的专业领域，都能够为项目做出贡献。一个有效的做法是假设参与项目的每一个人都有相同的价值，都应该被尊重。第18页/共55页 敏捷有什么不同关注协作:更少的文档工作，更多的沟通干系人引入研发过程关注质量:我们对系统做全面的回归测试我们开发的是低耦合、高内聚的架构我们不断的重构以保证产品的质量关注工作解决方法:更多的反馈使敏捷项目更便于管理更少的文档需求更少的管理机构敏捷是基于经验的，不是基于理论的:这是和传统的方法最大的区别需要在敏捷过程中去彻底了解敏捷第19页/共55页 敏捷有什么不同第20页/共55页 术语表Agile XP SCRUM JUNIT RUP UML FDD DDD