Goals目标：确定要达到什么目标。
Reality现实：评估现状。
Options对策：讨论可行的对策。
When时机：通过行动方案。
Reality现实：评估现状。
Options对策：讨论可行的对策。
When时机：通过行动方案。
|
XP(Extreme Programming)之所以有效，是因为它以验证为中心，而不是以生产为中心。
生产是指实际创建产品的行为，而验证则是确认产品符合预期目标的行为。 您在开发任何软件系统时，都必须回答以下两个问题：
XP实践除了重构外，都是为了解决第一个问题，因为验证的本质是交流。重构用来解决第二个问题，重构是一种很好的方法，重构使得体系结构从代码中涌现出来，使得软件系统易于维护与扩展。 在软件开发过程中，重要的不是缺乏仪式，也不是开发人员多高兴，而是自始至终验证所有的东西。 XP是第一种流行的，以验证为中心的软件开发方法。 项目管理学会（PMI，Project Management Institute）和软件工程研究所（SEI，Software Engineering Institute） 的SW-CMM/CMMI对最佳实践的理解似乎主要停留在过于强调过程定义和详细的前端计划上（当然公平地说在PMBOK 2004&2008和CMMI-Dev 1.3已经有改进）。这并不是说PMI和CMMI不好，只是说对智力密集型的软件开发项目来说存在不足。PMI项目管理观点大致上有倾向于鼓励局部优化（缺乏系统观，其中一个原因是项目本身定义引起，我推测，当然PMBOK2004已经明确强调项目组合及项目支持战略实现），在学习过程中可以掌握许多不错的技巧。PMI项目管理多数技巧是基于（单个）项目（意指明确的项目）的可预测理念。CMM建立在2个假设之上：1。管理系统的最好方法是将系统分解成可识别的工作产品，这些工作产品从输入状态变换到输出状态，以达到特定的目标；2。成熟的组织会认真规划所有的工作，然后对它们控制，以便实现计划。应该说明的是这两个假设会被隐含于多数实施CMM人员中（原因之一是没有真正理解CMM精神和CMM本身局限）CMM并没有指定方法（它会评估现有方法是否能够处理已知失效的软件开发模式），但是一个称职的实施CMM或是评估者应能在CMM3或是更高级觉察到妥善实施的敏捷生态系统。
如何超越？强调过程的同时关注人员，采用领导-协作的方式管理人员，而非采用命令-控制的方式；将推测改为基于数据的决策；将遵循计划改为学习，采用迭代式开发和波浪式自适应计划；以测试来跟踪软件开发真实进度，即可运行的软件为真实进度；将成本和进度为基准的管理目标转向以尽早与持续不断向客户提交价值为导向；强调价值、流程和人员，必然可以提高质量，降低成本，加快交付速度。 Jim Highsmith提出敏捷项目管理3个核心价值观：价值胜过约束；团队胜过任务；适应胜过遵循。现在，我还想补充一点：艺术胜过知识。管理艺术胜过管理知识/理论，本质上将项目管理是实践艺术，可能性的艺术。 注：原文最初写于2005年5月，现略作修改。 1.Fear no opponent,Respect every opponent.
不要惧怕对手，敬重每一位对手 2.Remenber,it is the perfectation of smallest details that makes big things happen. 记住：最小的细节上精益求精方能成大事。 3.Keep in mind that hustle makes up for many mistake. 牢记在心：仓促行事会筑成许多的错误。 4.Be more interested in charater than reputation. 要关注品格胜于名声。 5.Be quick,but don't hurry. 动作要快，但不要匆忙。 6.Understand that the harder you work,the more luck you will have. 要明白，你工作越努力，你的运气就越好。 7.Know that valid self-analysis is crucial for improvement. 要懂得：正确的自我分析对自我改善至关紧要。 8.Remember that the reis no substitute for hardwork and careful planning. Failing to prepare is preparing to fail. 要记得：努力工作和精心策划是无法取代的。不做准备等于准备失败。 Team Dynamics
An Apoplectic Dilemma Apollo 1973.4.13 A Different Approach to Teams 新新产品开发竞赛，接力开发，Scrum。 自组织团队的前提：授权、持续改进和多功能团队。 Capitalizing on Strengths 螺丝、钉子、锤子、螺丝刀，高绩效自我超越的团队发挥优势，识别技能空缺，工作严谨弥补之。 The Anarchical Team William Golding - Lord Of The Flies 个人需要超越于一群人的最佳目标之上。 The Evolution of a Maturing Team Tuckman’s Stages of Team Development in “Developmental sequence in small groups 敏捷宣言签署人之一Alistair Cockburn，组织大家在2011年2月12日，共同庆祝和反思敏捷宣言。这次聚会的目的是要回答以下三个问题：
敏捷教练的角色：培训师Trainer、咨询师Consultant、教师Teacher、导师/指导教师Advisor/Mentor、引导者Facilitator、教练Coach（关注客户的成长，并激发客户自己找到应对挑战/问题的方案）关注客户的利益决定方向，而不是教练的专业知识或观点。 客户Client=同事、团队、管理者、顾客
Coaching: opening Options by asking questions Trainer: X is … Consultant: You could do X Teacher/Advisor&Mentor:I’ve done X ,Try Y because … Facilitator :owns the process as servant leader for the group, helping maximize collaboration, learning, decision-making, and action Coach: What else? X,Y,Z… 迷思1：敏捷是完美的。 事实1：敏捷并不完美，敏捷一直在发展。敏捷宣言是2001年时17位为软件开发专家根据亲身实践和帮助他人实践，是对过去软件开发良好做法的总结，就如何更好地开发软件达成的共识。敏捷宣言选用“揭示/寻找（uncovering）”一词表明作者并没有所有的答案，其作用之一是让人们更加认真仔细的思考如何开发软件，寻找更好的软件开发方法。另外，就范围而言并没有覆盖软件开发的所有方面，比如敏捷没有涉及用户体验设计。另外，敏捷运动都没有与文化概念（无论在组织层面还是在国家层面上的文化）以及文化与实践之间的微妙互动（这是情景中不可或缺的一部分）完全融为一体。毫无疑问,敏捷一直处于演进之中，近年Kanban的出现很好地反映了这一点。敏捷是不完美的，同时，敏捷还将继续演进。 迷思2：敏捷是银弹。 事实2：敏捷不是银弹。敏捷只是接受常识*，提醒我们构建软件的是人。敏捷接受软件交付过程中固有的复杂性和不确定性。敏捷并不完美敏捷项目和其他项目一样同样会失败，只是相对使用传统软件开发方法而言有更高的成功率。另外，软件企业在变化，问题在变化，技术在变化，单纯地依靠任何一种管理和技术都不可能解决问题，也没有哪个方法可以直接套用。理论带来的是5％的启发或者灵感，95％的是针对软件企业实际的探索，留给了软件企业自己。敏捷也不例外，敏捷不是终点，只是敏捷是一个很好的起点和路标。 迷思3：敏捷过程。 事实3：很多人来敏捷寻找“敏捷过程”，将“敏捷看作价值观和文化”的更为宽泛视角来看敏捷或许能够更好地理解敏捷。倘若在敏捷宣言发布后的10年后的2011年还将敏捷落点在“过程”上，不能不说让我感到遗憾？！像Scrum、XP等涉及的过程只是起点，不是终点，也就是说单单一个“守”是不够的。另外，人们一直在说“敏捷过程”，但是实际上，不论是正式的还是在人们头脑中所默许的描述，过程本身都不是敏捷的。人可以敏捷，团队或者组织也可以敏捷。成为敏捷，而不是做敏捷。 迷思4：敏捷团队没有文档。 事实4：这是很典型地对敏捷宣言的误读或是误解。敏捷团队并不意味着不写文档，更确切地说敏捷团队没有写任何不必要的文档，对待文档像其他交付物一样，只是更喜欢面对面的沟通。敏捷并不否认文档的作用，与之同理，敏捷认同过程和工具、合同谈判和计划的价值，只是认为人及其交互、可工作的软件、响应变化更有价值。 迷思5：敏捷是反对规划的。 事实5：敏捷不反对规划，需要的是敏捷地去做估计与规划，发生变化时必须专业地判断回到原有的计划还是创建一个新计划哪一个更合适。另外，敏捷意味着“关注当前的现实”，敏捷规划是多层次的，更为宽泛（比如，每个季度的发布规划、每2周的迭代规划、每天的站立会议），使用不同的工具，比如使用燃尽图而不是用甘特图来可视化计划，让利益攸关者尽早地知道问题，更好地响应变化。 迷思6：敏捷反对合同。 事实6：洽谈协议，签订合同或者内部项目章程，并不是坏事，但仅有这些是不够的。客户需要的是满足他们需求的软件。客户和开发团队合作是最好的解决方案，合同提供了边界条件，通过不断协调，开发团队理解真正需求，并交付客户需要的软件。 迷思7：敏捷无纪律。 事实7：纪律提供了团队做不喜欢却又不能不做事情的能力，敏捷是讲究纪律的，其中XP尤其如此，比如，必须测试，必须反馈，必须定期交付，必须更新计划。 迷思8：敏捷反对架构。 事实8：架构在敏捷项目中和其他软件项目中一样重要。只是反对大规模预先设计（BDUF，Big Design Up Front），通过不同的手法（比如简单设计、测试驱动、持续集成和重构等）进行演进设计，实质上意味着系统设计随着系统实现而成长。在编写代码之前有进行设计的必要。其中一些设计工作在编写任何代码之前，但大多数设计则出现在针对特定任务的阶段过程中编写代码之前。在预构（Prefactoring）和重构(Refacroring)之间有一种新的平衡。敏捷强调设计简单、清晰并且易于重构。一个优秀的架构对于团队的所有的人都是简单并易于理解的。 迷思9：敏捷反对方法学，敏捷以“传统”为敌，以“PMP、CMMI与IPD”为敌。 事实9：敏捷不反对方法学，相反试图为方法学正名而努力。敏捷反对以文档驱动的重型软件开发方法，提供另外的选择，希望能恢复一种平衡，敏捷宣言的价值比较描述是其表现形式反映了这一点。真正拥护敏捷者并不会禁止或不提倡从其他阵营中汲取营养，敏捷的目的之一是促使人们认真仔细地思考如何更好地开发软件。 迷思10：敏捷团队反对管理。 事实10：管理仍然重要，管理的职责仍需承担，只是敏捷倡导创建自组织团队，敏捷反对“命令-控制”的管理方式，偏好“领导-协作”的管理方式。敏捷团队有权进行设计、计划和执行任务，并监督和管理自己的工作过程和进度，在健全的自组织团队中，团队成员共同承担领导角色，对工作成果共担职责。 迷思11：敏捷对人员要求高，适合于有经验有能力的高级技术人员组成的团队。 事实11：试想一下“使用非敏捷过程就能避免使用任何有有能力有经验的人”吗？事实上，同样的一批人应用敏捷比使用其他方法更有可能成功。根据经验，在敏捷项目中，通常初学者与有经验者之比在3：1到5：1之间。 迷思12：敏捷只能应用于小团队，敏捷无法扩展。 事实12：敏捷是可以扩展的，但敏捷扩展像其他软件实践一样，没有那么简单，没那么好。敏捷起初起源于小团队，许多敏捷实践都在团队层次上自然形成，但经过多年发展之后，有不少人对敏捷价值观、原则和实践在大团队中加以应用，更确切地说进行了试验，说明敏捷可以扩展至大团队，获得了一些成功经验。我认为与其，考虑如何往上扩展，不如尝试如何往下缩减，即大团队做减法，围绕人和工作系统（环境），以产出价值来衡量，去除不合理的部分。 迷思13：敏捷倡导的增量迭代开发就是微型瀑布（分析-设计-编码-测试）的叠加。 事实13：事实是分析、测试、编码和设计在开发过程中是持续的活动，每个迭代都产生的可工作软件。如图所示。 迷思14：敏捷是关于软件开发，不影响其他。 事实14：敏捷是一套面向商业竞争成功的适应能力和响应能力的价值观和原则。敏捷包含的概念和实践方法在挑战传统的组织假定，往往会导致组织变革。比如，敏捷倡导的自组织和跨专业/功能的团队就是高冲击力的代表；更小频繁发布软件成为有效时，企业不得不处理如何最大化其市场影响的问题；“在整个项目过程中，业务人员和开发者必须每天一起工作。”对产品营销和产品管理也会产生影响，通常需要新的资源和组织结构，如对产品经理的要求会更高，产品设计可能会与研发部门、市场部门并列。 迷思15：敏捷不过是经验之谈、观点或“信仰”，无法评估其是否合理。 事实15：不少敏捷方法明确提出其背后的科学理论依据，比如自适应软件开发的理论是复杂自适应理论，Scrum的理论依据是控制论，Crystal的理论依据是博弈论，精益软件开发的理论依据是排队论和系统论。应用排队论、控制论、信息论和博弈论等正式模型来评估采用敏捷的工作系统，证明其确实可以产生优秀绩效。 *敏捷背后的四个假定或接受的四个事实： 1. 客户不完全知道自己的需要。通常，在项目开始之前搜集完所有需求是不可能的。 2. 开发团队不完全知道如何构建软件。通常，在项目开始之前完全确定技术解决方案是不可能的。 3. 需要和构建会发生变化。唯一不变的是变化。 4. 在现实中，永远有比你时间和金钱所允许做的事更多。  敏捷没有明确的定义，解释很多。敏捷宣言的4个价值观是得到17位敏捷宣言发起者高度一致赞同的，但是12个原则是勉强达成的。认真细读和体会“敏捷宣言”也会赞同价值也继续演进，代表之一就是“Software Craftsmanship Manifesto”。17位位敏捷宣言发起者首先在应该对需求变化做出反应则是先于价值及原则达成之前。在敏捷宣言发布之后，Jim Highsmith、Martin Fowler和Alistair Cockburn等或联合撰文解释或各自写书阐释。其中，Jim Highsmith比较认同Goldman关于敏捷的的阐述“敏捷是动态的、适用于具体情况的、迎合变化和自我完善的。敏捷不仅在于提高生产率、降低成本、做好做好准备从而安全度过可怕金融风暴。还关系到在竞技场上获得成功，关系到从激烈的竞争中赢得市场份额、赢得客户。”，Jim继而将敏捷阐释为"敏捷是为了在动荡的业务环境中获益而创造变革和响应变革的能力。”Martin Fowler则在新方法学中提炼出2个重要特征：基于适应而非预测；以人为导向而非过程导向。当然其他敏捷人士也略有差别的阐释。
所以若将敏捷还是定位在《Manifesto for Agile Software Development》中的“软件”，那么大致可以这样理解：敏捷是一套面向商业竞争成功的适应能力和响应能力的价值和原则，并且会一直演进，思考的是如何更好地开发软件。它是组织（包括员工）品质的反映，也体现为了在动态环境中获益而创造变革和响应变革的能力。支持敏捷宣言的价值与原则的实践方法，被称作敏捷方法，如XP、Scrum和Lean等。敏捷方法中包含了一些良好的做法，称作敏捷实践。比如结对编程就是XP的实践。敏捷方法的三个重要的特征：以人为本、自适应和持续改进（含人、产品、过程及工作环境）。软件团队可以实施敏捷（或者说具有敏捷之形）如Scrum、XP等，但这些都是具体的敏捷方法，他们通过采纳实践——敏捷实践，如持续集成、测试驱动开发和自动化测试等，也许有助于推进敏捷实施。然而，他们要么掌握敏捷精髓，要么不能，二者必居其一。 那么，何谓掌握敏捷精髓？敏捷不等于敏捷方法如XP，也不是敏捷实践如测试驱动开发。它表示组织和人员为了在竞争中取得商业胜利，快速交付具有经济价值的产品和知识，为适应环境自我调整、对事情或变化及时做出响应、不断学习与自我完善——这就是掌握敏捷精髓。换句话说，成为敏捷不仅仅是决定采用“指定的”敏捷方法如Scrum、XP和/或敏捷大师们所描述的这样或那样的敏捷方法或敏捷实践，需要改变观念或态度，要把敏捷价值观与原则变成自己的思想和行为方式，通过不断试验，不断反思和总结经验，继而调整和自适应。也就是说，要实践，还要思考和自适应。 敏捷反应的是能力，体现的是思维，思考的是如何更好地开发软件。敏捷则是由价值--原则--实践组成一个相对完整的体系。 题外话 敏捷需要许多纪律和思考，不是每个人都可以进入敏捷思维。但是它是一种非常自然的工作方式，许多人享受它。我想是否将来某一天每个人都敏捷？不！基于同样的原因，人们有不采纳的权利。因为没有唯一的方法，所以，我们要做任何对我们有效的事！ |
Author我是一名敏捷教练致力于帮助软件组织探索和设计更好地交付高价值软件的方法，专注于向软件团队讲述如何创造价值以愉悦客户并利用精益与敏捷指导软件开发。 Archives
一月 2023
Categories
全部
Click here to edit.
|
RSS订阅
