Scrum项目管理浅析.docVIP

Scrum项目管理浅析 在混乱中的项目管理 一直以来很多的组织或机构把预定义的、强调制定周密项目计划并严格按计划实施的项目管理方法及流程奉为必然的圣条。然而我们又不断的耳闻目睹许多项目的失败，特别是在软件、IT系统及产品开发领域，尽管这些项目大部分严格按照传统项目管理所定义的方法来执行。 在软件开发组织中，当项目复杂程度超出管理者能力，难以向目标实现有意义的进展时，会导致混乱局面。进展可能时断时续，但通常不明显，无法令人满意。 具体场景如下： 开发团队的员工依照角色被分派任务，各角色的工作包括分析、设计、编程、测试和文档。这种方法导致瀑布式工作处理模式。首先由一个人分析需求，另一个人设计，再派若干人将设计转为代码，最终，由其他工程师测试代码。软件开发工程师彷佛装配工厂的工人，完成各自任务后，将产品沿流水线传递。这种方式扼杀了合作机会。此外，工作的顺序性导致开开停停，人们需等待先行任务完成后方能开展后续工作。而且在复杂项目中一般难以提前预估所有事项。模块间交互相当复杂并有大量未知因素。管理者在发布周期之初规划的任务，可能在下达后不久，就不再符合实际情况。团队工作刚开始，项目便出现问题，已规划的任务无法完成，从属的后续任务只能无限期拖延。 任务的顺序性割裂了团队。分析情况和确定需求的工作于设计满足上述需求的方案并不是由同一批人完成，第三批人员为了方案编写代码，在这样的情况下，团队之间的交流与合作后的效果难如人意。 Scrum与XP Scrum与极限编程（XP）都要求团队在每一次迭代的结尾完成一些可以交付的工作片段。迭代要短，没有时间限制。将注意力集中于在短时间内交付可工作的代码，这就意味着Scrum和XP团队没有时间进行理论研究。他们不会花时间用建模工具来画UML图、编写完美的需求文档，也不会为了应对在可预计的未来中所有可能发生的变化而去编写完美的代码。实际上，Scrum和XP都关注如何把事情做好。这些团队承认在开发过程中会犯错，但是他们明白：要投入实践中，动手去构建产品，这才是找出错误的最好方式，不要只停留在理论层次上对软件进行完美的分析和设计。 UML用例图、时序图、需求说明书、概要设计文档、详细设计文档、测试用例其存在的最大目的在于项目人员彼此间进行沟通的需要，而对于IT项目的最终使用者而言，他们唯一关心的只是切实可用的软件产品，能够满足或快速响应其不断变化的业务需要。 成功关键策略 不同类型/背景下的项目可能需要截然不同的管理方法； 衡量项目成功与否，要看重项目成果的商业价值与投资回报，而非仅仅看其有没有超支，延时或按原定计划行事； 20/80原则，最大可能地满足利益关系人的核心需要； 尽可能让核心关系人参与并及早展示项目的进展和成果，及时作出必要调整，以确保更高商业价值的交付； Scrum流程 Scrum核心在于迭代。团队首先浏览开发需求，考虑可用技术，并对自身能力做出评估，然后共同确定构建功能的方案，并每日调整方法，以应对新的复杂问题、困难和出乎意料的情况。团队找出并选择最佳方案去完成任务。此创造性过程便是Scrum生产的和核心。 一个Scrum项目的起点是待开发系统的愿景。产品负责人根据项目目标制定出计划，该计划是一张关于功能性和非功能性需求的清单，根据该清单排列出不同优先等级并把事项分成多个建议发布组，最易产出价值的事项享有最高优先级。项目一旦开始启动，该清单内容、优先等级和发布组便会不断变化-即不断变化的商业需求，以及团队将待开发事项转化为功能的速度。 所有的工作在Sprint迭代周期内完成。每个迭代周期开始时，需要召开Sprint计划会议，共同探讨Sprint内的工作内容。 每天，团队集合召开15分钟的会议，称为”每日Scrum简会”。在简会上，每位成员回答3个问题：自上次Scrum简会后的一天里你做了什么？从现在到下次Scrum简会的一天时间里你准备做什么？在具体的工作中，你遇到了那些困难？其目的在于让团队内的所有成员都知道其他人每天都在做些什么，非常利于团队内部的沟通。 Sprint周期结束时，需召开Sprint评审会议。由产品负责人向利益相关者展示该Sprint周期内的产品开发情况。该展示功能的非正式会议，旨在召集相关人员，共同决定团队接下来的工作内容。 产品负责人 随着软件工程实践的进步，利益相关者与开发者之间的鸿沟也愈发深阔。造成这一疏离的最新举措便是”瀑布式方法”的引入，它囊括了顺序开发的所有缺点。该方法收集全部的需求信息、制定设计、编写代码、开发并运行测试，最后实施系统。它通过评审会议连接各个步骤与阶段。会上，开发者和管理者向客户提问：“我们所收集的需求信息及其展示模型，是否全面且精准地表达了你们的需要？一旦给出肯定的答复，改变主意的成本将更加昂贵！”这类言辞暗示着客