Agile 敏捷
前言
在这个文章中，我主要以我对敏捷的理解对其进行描述，对于一些敏捷的定义可能会有偏颇和遗漏，欢迎与我讨论或提出反馈，让我”敏捷”地开发出这篇关于敏捷的文章。
什么是敏捷
敏捷，指的是使用者以高的效率低的成本为自己或他人提供价值。当一个人抱着这样的目的并为此做出行动，提供价值时，他就是敏捷的。在软件开发的领域，由于市场的变化、技术的变化、商业策略的变化等，需求的变化时常发生，因此低成本地快速适应变化是敏捷在软件开发行业内的核心表现。
经过在软件行业耕耘许久的前辈们的实践，他们总结出了一些通用的实践，包括manifesto宣言、principles原则以及ceremonies会议等。当这些实践帮助我们在当前的情况下更快更好地达成目的时，那么这些个实践就是敏捷的。
从敏捷实践看敏捷
在软件开发领域，当开发一款产品时，进行快速的价值交付需要考虑什么关键的要素呢？前辈总结出来的敏捷实践又怎么帮助我们对这些要素进行优化呢？
故事板 story board/看板 kanban board帮助聚焦价值与提升效率
故事板story board或看板kanban board时常被用于进行需求的管理与描述。它们一般是以as…, I want …, so that …的模版进行需求的叙事性表述。通过故事的内容，开发者可以更好地理解相关工作的上下文、验收标准。这最终将导致团队内沟通的成本被降低，开发的效率被增高与不必要的工作被减少。这个实践方法不仅可以用于具体的软件开发中，对于其他的一切需求进行故事化，也可以给使用者在短时间内了解大概的上下文与接受的标准。
as… 作为数字化方案提供商
I want/need to… 我需要以更低的成本为客户更快地提供更有价值的数字解决方案
so that… 我可以在商业上获得竞争力
as… 作为一个thoghtworks员工
I want/need to… 我需要写出一篇关于敏捷的文章
so that… 读者在阅读完文章后，可以对敏捷有大体正确的印象
在创建故事时需要注意两点
- 不同的故事定义将决定不同的验收标准，如当故事最终提供的价值为“读者在阅读完文章后，可以对敏捷有大体正确的印象”时，验收故事的标准主要考虑的即为读者；而当故事最终提供的价值为“帮助自己更好地梳理知识”时，所考量的主要就为作者了。对于不同的验收标准，对“产品”所进行的开发方式也会有所不同。
- 故事在开始时是较为笼统的，但在持续的迭代中，故事所描述的需求会变得越来越清晰。而且我们无法避免一开始笼统的故事描述，由于已有的事实：
- 获得所有的需求在一开始是不可能的。
- 细节的需求是一定会改变的。
- 总是会有更多超过给定时间和金钱限制的事情需要完成。
会议 ceremonies帮助达成目标
为了快速地提供符合客户要求的价值，敏捷的实践会将一整个长的产品开发周期会被细分成更小的周期。这个更小的周期在不同的敏捷框架中会被称为sprint或者iteration。我们在下文统一使用迭代进行表示。而每一个迭代都可以通过PDCA（Plan-Do-Check-Act）循环进行再次细分。我将基于这个PDCA循环介绍敏捷实践中的会议，从而让我们更好地了解到会议使用的时机和目的
在Plan阶段，即迭代刚开始时，团队的各种角色包括BA（Business Analyst）、PO（Product Owner）、TL（Tech Lead）等会聚在一起对客户的需求进行分析与工作量评估，这个会议被称为IPM（iteration planning meeting）这个会议主要决定了三个事情：
- 为什么这个迭代有价值（目标），
- 这个迭代能完成什么（范围），
- 如何完成所选工作（怎样完成）。
通过这个会议，我们可以确定提供给客户的产品是有价值的。
在Yunzhi Liu在博客大赛《从迭代计划会看敏捷实践》的博客中提到，这个IPM可以根据情况再细分成两个会议Iteration Planning Meeting和Iteraction Kick-off Meeting，IPM让PO、BA、TL来决定业务优先级与规划迭代，IKM来帮助团队更好地了解业务上下文来讲行开发，其目的是为了进一步提升团队的开发效率。
我认为这种细分法可以根据团队的构成来决定是否采用。当团队中有较多的junoir时可以通过将细分IPM以节省他们花费在确定需求优先级与讨论技术方案的时间。而在有较多的senior的时候，将会议细分，则会让开发花费更多的时间来获取业务信息与阐明细节。 回到敏捷，即选择真正可以提升效率的方式去使用会议。
在Do阶段，在定下了迭代的目标、范围与如何完成工作之后，我们进入开发的流程。standup是一个短的非正式的会议让团队的成员更新他们自己的昨天的工作与其今天的安排。这个会议帮助成员们对项目的情况保有相同的理解。通过这个会议，我们可以减少不必要的重复工作的进行，扫除开发过程中的障碍，让交付的效率更高。
来到check阶段，当开发团队完成了当前迭代的开发任务后，在迭代结束前，团队会举行showcase会议并邀请客户参与。在会议上 ，团队将新的产出进行展示以及时获得客户的反馈。尽早让客户了解当前产品的状态并获得反馈，可以让产品的交付更加符合客户的要求。
retrospective会议发生在check和act阶段。在迭代结束时，团队会在这个会议上对这个迭代的执行对于效率、质量、成本等进行反思并提出反馈，最后根据这些反思及反馈提出相应的行动在下一个迭代进行运用。通过这个会议，我们可以帮助团队持续成长和提高团队效率。
还有很多其他的会议如Dev Huddles, Analysis等，而根据敏捷框架的不同，会议所关注的重点和形式也会有所不同，但我们只需要记住，会议不是最终目的，会议是为客户更快更好地传递价值这个目的的手段。
特定于开发人员的实践 developer-specific practices帮助提升代码质量
敏捷的思想不仅可以被应用在更宏观的项目管理上，如上面提到的各个会议，在软件开发的过程中，它也处处可见。敏捷开发实践有TDD, pair programming, refactoring, continuous integration 和 continuous delivery等。这些实践的目的是为了以更低成本更快地产出更加有质量的软件，进而为客户提供价值 。
测试驱动开发，开发者通过先写测试，强迫自己从结果反向推导业务代码的内容，以促进只写必要的代码。通过这种方式，有利于后期产品的快速调整，进而适应市场。
结对编程，两人以合作的方式，使用一台机器进行代码的书写。通过这种方式，提高了反馈的速度，进而提升了代码的质量，也为后期的快速调整带来可能。
重构，通过经常对代码进行重构，可以帮助开发者更快地读懂代码并在此基础上进行新功能的添加。
持续集成，指的是尽早地将每个人的代码融合到一起，通过这种方式，它可以帮助我们尽早地发现代码冲突并解决它。
持续交付，指的是尽早将代码部署在生产环境中，以此为客户传递真正的价值。
敏捷宣言 Agile manifesto
为了以更简洁易记的方式表明了敏捷的价值观，并以此价值观进而决定其行为，最终指导达成敏捷目标。在2001年，敏捷联盟（ The Agile Alliance ）制定并发布了《敏捷宣言》，
个体和互动高于流程和工具，工作的软件高于详尽的文档，
客户合作高于合同谈判，
响应变化高于遵循计划。
总结
关于敏捷还有很多相关的名词，例如敏捷开发12原则、Scrum、XP、SAFe、Lean等，这些名词在了解敏捷的目标与价值观后，都十分容易理解与掌握。总而言之，敏捷是一种思维，当我们尝试以尽可能高效的方式产出质量高的内容时，我们就在敏捷中，而尝试的这些方式即被称之为敏捷实践。