敏捷项目管理

在远古时代，文字没有出现之前。知识的传承靠口口相传，不管隔了多少代，其准确性很高。文字出现后，我们大脑中的这种技能反而逐步衰退。于是各种软件、各种方法充斥着我们，左右着我们。各位是否也有相同的想法？试想一下，上节课我们讲了什么？每次应允别人的承诺，我们转过头就忘记？比如忘记约会，忘记洗车、忘记写日报？ “要想知道栗子的味道，你得咬一口”这个真理朴实，正确。当用户提出一款软件时，我们不要只想着从技术的角度，认为用户不专业，他的需求是错误的。如果他专业，就没我们啥事了。用户大脑中的需求是离散的，不可控的，这时，就需要我们放下成见，彼此真诚相对，让用户参与进来，通过各种方法，一条条梳理，直至双方的理解是一直的。 其作用：1.我们弄懂了用户为何会这样想。2.用户通过亲身参与，头脑中的需求逐渐变成技术可理解的。“求同去异”是一个很难的过程，需要双方彼此做出改变，很难.....，往往难得事情才是最重要的，要不怎么会有“战胜困难”的伟大，痛苦成就了欢乐。 软件的最大价值只有在用户认可，使用才算真的有价值。“再牛逼的算法，再严谨的逻辑”不符合用户实际需求，都是白费力气。“当顾客很饥饿时，他只需要的立马填报肚子的食物，而不是需要几天或者几个月才能做好的满汉全席”。 扯远了，回归正题。因用户对软件领域不专业，脑中对需求没有一个正确的定论。就需要我们专业人士，运用特殊的方法，梳理用户真正的意图。

Sprint（冲刺）是Scrum的核心，持续时间为一个月或更短的时间，在这个时间内构建一个完成、可用的和潜在可发布的产品增量.在整个开发过程期间，其长度应保持一致，前一个Sprint完成后，新的下一个Sprint紧接着就开始，有点像接力棒的游戏。 Sprint计划会议：会议时间不要过长，不要为了会议而会议。通常一个月内的，上限为8小时或更短；依次类推。其主要目的是确定每个参会者都理解会议的目的。敏捷教练要确保会议顺利举行并教导敏捷团队遵守时间盒规则。包含几点：这次做什么？如何完成所选的工作？期间会遇到什么问题？预期可交付的增量？ 每日站会：2W1H，昨天我做了什么？今天准备做什么？是否需要他人协助？注意一点，站会的时间不要太长，其核心的地方，每个人参与，不要开成训导式的，确保每人都可以发言及每人都有机会主持会议； 开发工作：通过看板、代码测试、代码审核、沟通来确保Sprint正常进行； Sprint评审会议：在Sprint尾期进行，用于检视所交付的增量并按需调整ProBackLog列表。参会人员：团队成员、客户、利益相关者；会议时长同样不要太长，根据Sprint的大小决定。在会议中集中讨论几个要点：probacklog哪些“完成”、哪些“未完成”、遇到什么问题及如何解决的、演示“完成”的工作并解答增量交付的问题、讨论当前的probacklog的情况

软件项目管理的两大主流管理模式：传统项目管理（预测型项目管理）、敏捷项目管理； 传统项目管理（预测型项目管理）：瀑布式、部分迭代开发模式，要求在项目一开始，需求足够明确、文档足够规范、迭代过程需求变更越频繁，其对项目造成的灾难往往越大。相信很多IT团队都尝试过，这里不赘述。 敏捷项目管理作为新兴的项目管理模式，简化了传统项目的流程，从繁琐的流程和详尽的文档中解脱出来。但并不代表敏捷不做计划，有很多人的观念“敏捷不做计划”这是错误，否“probacklog、scrum、看板、燃起图、燃尽图、用户故事等等”方法和工作又是为谁提供工作依据？敏捷即迭代、增量交付，其中代表XP、Scrum是用的最多的方法，其核心思想：拥抱变化，通过sprint迭代快速向客户交付可用的软件，并通过反馈来确定产品的方向，使产品利益最大化。 1.管理流程 完整的项目管理流程包含五个过程：启动、规划、执行、监控、收尾； 敏捷的项目管理框架：构想、推测、探索、适应、结束。 构想阶段：确定产品的构想、项目范围、项目团队以及团队共同的工作方式。通常采用用户故事方式进行深挖； 推测阶段：制定功能发布计划、里程碑和迭代计划，确保交付构想的产品（产品路线图-组件团队-项目章程-流程剪切）。通常采用故事作坊模式进行深挖和确定需求； 探索阶段：在短期内提供可经测试的功能，不断的刺探市场\客户的反馈，减少项目的风险和不确定型

在当今极度变化的大环境中，产品团队正面临着一场巨大的变革。为了更好的适应大环境，研发团队都极力做自我调整。 达尔文曾说过“留下来的物种往往不是最强的，确实最先进化的”，从传统的“瀑布式”到“迭代式”，最终再到敏捷型研发团队。无数组织、团队都在进行思考、变革。 研发团队一定要通过无尽的加班，才能交付产品，不能一边享受生活一边交付产品吗？ 产品一定要尽善尽美后再推向市场，是否可以通过小的版本快速推向市场？ 答案是可以的，是时候来场变革了！ 在本系列，我将和你一起探索敏捷项目管理的知识和实践。 最终客户价值在销售时交付，不是在计划时交付。 敏捷商业目标 持续创新力--满足当前客户的需要； 产品适应性--满足未来客户的需要； 缩短交付进度--满足市场，提高投资回报率（ROI）； 可靠的结果--支持业务增长和盈利能力。 持续创新 关起门来造轮子，已经无法适应当今复杂的商业和技术环境。开发产品和新服务都需要新意识。 特别是随着大数据、人工智能、工业互联、5G的发展，编程步入了一个高速发展的时期，从C语言到python，从低级语言到高级语言层出不穷，从成人编程教育到少儿编程的兴起，市场给了我们更大的机遇和挑战。 持续创新能力随着环境的变化显得尤为突出，当大家都在聊4G，5G已经悄然来临，快速占领行业浪尖--这就是持续创新的一种表现，带来的机遇和收益往往是巨大的。 创新思想并不会是模式化的

摘要 :目前软件开发除了强调产品质量,同时对产品能够快速发布并且迅速适应市场变化的要求也日益强烈。为适应这种开发环境和市场需求,传统的软件开发模式已被敏捷开发模式所替代。本文介绍敏捷软件开发中的Scrum方法,并结合实际问题,分析Scrum方法在实践中的运用。 关键词 :敏捷开发;Scrum 产品质量和开发效率一直是软件产品开发的关键。随着科技和经济的发展,软件的市场环境和用户需求不断发生变化,这对软件产品的快速发布提出很高的要求。传统的瀑布模型、螺旋模型、原型模型等已不能适应越来越复杂和不断变化的需求和市场环境。近年来,敏捷软件开发逐步流行,并被广泛认识、研究和使用。敏捷开发具有应对快速变化的市场和需求的能力,因此,它被越来越多的公司企业采用。用于敏捷软件开发的方法有很多,其中Scrum方法是被广泛应用的方法之一。 1.Scrum简介 Scrum是一个增量的、迭代的开发过程,名称来自英式橄榄球的争球。Scrum的整个开发周期包括若干个小的迭代周期,每个小的迭代周期称为一个冲刺(SPrint),每个冲刺的长度一般为2到4周。在Scrum中,使用产品订单来管理产品或项目的需求,产品订单是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。开发团队总是先开发的是对客户具有较高价值的需求。在每个冲刺中,开发团队从产品订单中挑选最有价值的需求进行开发

　　一些评论员写下了敏捷实施中 一些 常见错误和反模式。他们贴出了“Top X”列表，列出了需要避免的事项和他们曾在各种组织实现敏捷时见过的错误。 /*--> */ /*--> */ Target Process 的 Michael Dubakov写了两篇博文：“10个敏捷实施中最常见的错误”（ Part 1 ; Part 2 ）。 他认为“ 许多公司在敏捷实施中再三犯同样的错误。 ” /*--> */ /*--> */ 他的常见错误列表如下： /*--> */ /*--> */ 1. 从一个工具开始 敏捷开发是不同的。一个工具不会立刻产生影响，不会由于这一工具的存在而解决多数的问题。而且，你由于需要为工具的实施投入精力， 这会 影响更重要的目标--敏捷实施。 /*--> */ /*--> */ 2. 从一个过程开始 多数公司是从一个过程开始的。这错误不是很严重，但更常见。如果你读读Scrum相关资料，会觉得它看起来很容易启动。你实施所有的Scrum实践，在若干sprint后发现开发有 了 点改进，但 远没有达到预期。于是热情开始消退，过程开始退化。任何公司开始尝试任何敏捷过程前做的第一件事 应该 是，专注于敏捷价值，比如：沟通、协作、反馈、信任和热情。 如果你对这些价值中的任何一个做出妥协，就几乎不可能实施一个 良好地 开发过程。 3.开发实践就足够了 有趣的是

什么是敏捷开发？ 敏捷开发( Agile Development )是一种以人为核心、迭代、循序渐进的开发方法。 怎么理解呢？首先，我们要理解它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发； 为什么说是以人为核心？ 我们大部分人都学过瀑布开发模型，它是以文档为驱动的，为什么呢？因为在瀑布的整个开发过程中，要写大量的文档，把需求文档写出来后，开发人员都是根据文档进行开发的，一切以文档为依据；而敏捷开发它只写有必要的文档，或尽量少写文档，敏捷开发注重的是人与人之间，面对面的交流，所以它强调以人为核心。 什么是迭代？ 迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。 关于Scrum和XP 前面说了敏捷它是一种指导思想或开发方式，但是它没有明确告诉我们到底采用什么样的流程进行开发，而Scrum和XP就是敏捷开发的具体方式了，你可以采用Scrum方式也可以采用XP方式；Scrum和XP的区别是， Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的， 这里我主要讲Scrum。 什么是Scrum？ Scrum的英文意思是橄榄球运动的一个专业术语

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 敏捷建模（Agile Modeling，AM）的价值观包括了XP（Extreme Programming：极限编程）的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。 Scrum和XP就是敏捷开发的具体方式。 Scrum和XP的区别是，Scrum偏重于过程，XP则偏重于实践，但是实际中，两者是结合一起应用的。 Scrum是指一种迭代式增量软件开发过程，通常用于敏捷软件开发。虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法。Scrum之间的合作称为“Scrum of Scrums”。 Scrum开发流程中的三大角色： 产品负责人（Product Owner）主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。 流程管理员（Scrum Master）主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。 开发团队（Scrum

敏捷开发 敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。 那Scrum又是什么呢？Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作。 Scrum 是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(互联网产品研发可以使用1周的Sprint)。在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。 Scrum起源于软件开发项目，但它适用于任何复杂的或是创新性的项目。 其中

请阅读我们的热门文章，这些文章着重讨论了敏捷的过去、现在和未来。-- Leigh Griffin（作者） 对于 Opensource.com 上的敏捷主题来说，2019 年是非常棒的一年。随着 2020 年的到来，我们回顾了我们读者所读的与敏捷相关的热门文章。 小规模 Scrum 指南 Opensource.com 关于 小规模 Scrum 的指南（我曾参与合著）由六部分组成，为小型团队提供了关于如何将敏捷引入到他们的工作中的建议。在官方的 Scrum 指南 的概述中，传统的 Scrum 框架推荐至少三个人来实现，以充分发挥其潜力。但是，它并没有为一两个人的团队如何成功遵循 Scrum 提供指导。我们的六部分系列旨在规范化小规模的 Scrum，并检验我们在现实世界中使用它的经验。该系列受到了读者的热烈欢迎，以至于这六篇文章占据了前 10 名文章的 60%。因此，如果你还没有阅读的话，一定要从我们的 小规模 Scrum 介绍页面 下载。 全面的敏捷项目管理指南 遵循传统项目管理方法的团队最初对敏捷持怀疑态度，现在已经热衷于敏捷的工作方式。目前，敏捷已被接受，并且一种更加灵活的混合风格已经找到了归宿。Matt Shealy 撰写的 有关敏捷项目管理的综合指南 涵盖了敏捷项目管理的 12 条指导原则，对于希望为其项目带来敏捷性的传统项目经理而言，它是完美的选择。 成为出色的敏捷开发人员的