敏捷 vs 伪敏捷(2)

　　欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

　　敏捷伪敏捷拥抱变化，被看作为项目提交的积极部分。宁愿改变也不愿提交错误的东西。持续变更的请求成为计划糟糕、需求分析糟糕或者设计糟糕的媒介。变更通过任务列表(Backlog)的流程管理，以确保所有变更都是可控的。不会积压!变更缺乏管理，并影响时间表，交付时间，或者打破团队工作生活的平衡。变更范围是为了满足客户的经营目标。变更常常因为技术部门差劲表现导致的。原则3：交付更短，收获更多

　　经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。

　　敏捷伪敏捷致力于分解大系统到更小的可部署可工作的组件特性。致力于发布2周内能完成东西。冲刺(Sprints)的长度能确保一个或者多个完整的用户故事能被交付开发活动被时间盒(timebox)陷住，并努力在这个时间盒里完成。"完成"(Done-Done)的定义理解得非常透彻，组件只有在符合标准时，才会部署。"完成"是在时间盒的尾声主观判断定义的。原则4：成功需要参与

　　业务人员和开发人员必须相互合作， 项目中的每一天都不例外。

　　敏捷伪敏捷业务人员和技术人员在同一个地方共同工作，并持续协作配合。各个团队在简短的每日会议后，又各自回到自己的项目领域。各个团队视最终产品(交付的软件系统)为大家共同的交付(而不仅是开发人员的责任)。开发人员主导整个过程，并自己做出决定，因为他们比其他人更知道该完成些什么。冲刺(Sprint)中发现的问题(Issues)会被利益相关者(stakeholders)快速地解决。问题(Issues)会被推迟到任务列表(Backlog)，因为交付至上。每一天都一起工作，以此利益相关者(stakeholders)对解决方案和更优的用法有着直接的了解。利益相关者(stakeholders)没能投入他们所有时间和团队一起，他们只在危急时出现并常在此时调整方向。原则5：授权给“合适的”的员工

　　激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。

　　敏捷伪敏捷成熟的、经验丰富的员工，能利用这些经验做出杰出的事情。员工由强有力的领导结构驱使，确保在冲刺(Sprint)的时间表内完成任务。团队成员由自我管理和自我确立目标而受到激发。团队成员被强势的组织结构驱动。团队成员确立冲刺(Sprint)的大小和范围，并为质量和完整性而调整其大小。领导确立任务列表(Backlog)的工作量，员工被要求按时完成。分心事宜(Distractions)，例如会议，被面对面的协作配合取代。分心事宜(Distractions)，例如状态会议，将是必须的，以便“控制”工作任务的完成。娴熟的角色(Skilled roles)促进确保完全的“我们都在这里一起”的环境。关键的角色(如，QA和BA)被“超级”开发人员取代，因为他们能做所有的事情。原则6：协作不只是坐一起

　　不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。

　　敏捷伪敏捷团队成员坐在一起，不是把团队从组织中隔离出来，而是为了更高效的协作。不是所有团队成员都坐在一起。面对面交流能迅速地分享信息，但这并不能完全抛弃文档。鼓励团队成员所有的工作都通过口头沟通，并不要浪费时间在文档上。各个团队对产品交付的所有方面都负有责任，像一个团队般一起工作，以确保质量。各个团队常常在一块工作，但是对交付产品的质量几乎没有责任感。避免电子邮件成为主要交流沟通工具。认为电子邮件是令人满意的文档工具。原则7：质量很关键

　　可工作的软件是进度的首要度量标准。

　　敏捷伪敏捷"完成"(Done-Done)的定义理解得非常透彻，组件只有在符合标准时，才会部署。进度是通过冲刺(Sprint)的完成情况和时间来衡量的。质量胜过进度，团队和领导对其的态度是言行如一的。进度胜过质量，成为潜规则。如果软件不能工作，那么就不交付它。交付和修复是开发过程中的一个策略。原则8：不是死亡之旅(Not a Death March)

　　敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

　　敏捷伪敏捷标准和流程，不是限制团队，而是使其加速和创新。框架是自由灵活的。流程是稳定的。标准和流程，不是过于官僚和限制，就是在解除团队限制时被完全精简掉了。项目过程像马拉松，由很多较小的冲刺(Sprint)组成。避免赢了冲刺，输了比赛。人员保持新鲜感。团队努力完成时间盒里的工作量。延长工作时间，周末加班成为常态。人员被视为商品(commodities)。原则9：技术很关键

　　坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。

　　敏捷伪敏捷标准和流程并不官僚，反而能保持一致和加速开发。流程被抛弃、被“即兴(ad hoc)”的项目执行取代以追求更快的速度。失败更快。避免为了流程而流程。流程必须有其价值!没有任何流程。文档的请求会受到温和的批评，除非有价值、风险和回报的评估分析。回避任何文档请求。“敏捷不是反方法论的运动;事实上，我们大多数人希望恢复方法论这个词的可靠性(want to restore credibility to the word methodology)。 我们希望恢复到一个平衡。我们崇尚建立模型，并不是为了把这些文件图表放置公司布满灰尘的仓库里。我们拥抱文档，但不是几百页的、从不维护更新、极少使用到的大部头文档。 我们做计划，同时也知道计划在混乱环境中的局限。”

　　Jim Highsmith, 敏捷联盟原则10：简洁 = 稳定 & 速度

　　以简洁为本，它是极力减少不必要工作量的艺术。

　　敏捷伪敏捷致力于寻找最简单且质量足够的方式满足业务需要。致力于寻找最快速、最少编码的方式满足业务需要。足够简单有效的流程，被视为战胜拖拉，加快持续交付的法宝。精简流程步骤，比如，测试。经常认为是为交付而简化。任务列表(Backlog)成为守门员，对所有任务排上优先级再处理。工作量常常变化，因为优先级发生变化颠倒，十分混乱。原则11：让团队闪耀吧

　　最好的架构、需求和设计出自自组织团队。

　　敏捷伪敏捷允许团队犯错误，提出他们的解决方案，交付产品，经常评估(回顾)，并从他们的成功(和错误)中学习。错误导致项目领导和被视为项目按时完成的诋毁者之间对峙。时间都浪费在“责备的游戏(blame game)”。鼓励团队一起工作，并让他们有权作出决定(界线模糊)。每个人都朝着同一个目标努力。一起工作但传统界线(如BA，QA，DEV)仍在。没有共同的目标，每个人看到自己不同的“工作”。做出最好的决定的那个人，是最接近这一决定的原因和影响的那个人。领导坚持复查和调整计划，以满足“政治”的时间表，而不是信任那些最接近实际工作的人。原则12：回顾并向前

原文转自：http://blog.csdn.net/ocean1ee/article/details/8873688