世上没有这样的方法：只要你运用它，就能写出完美的软件，无论你使用哪种设计模式；但可能确实有一种开发方法可以帮助我们一步一步地构建出所需要的软件和架构——这可能就是敏捷开发。与软件开发过程相比，有一门特殊的学科——软件工程。最早接触软件工程是20年前在北电贝尔北方实验室工作的时候。当时的开发流程是这样的：其他主流的瀑布式开发流程也是如此。但是随着技术的演进，尤其是互联网的发展，BS架构的广泛应用使得及时响应用户反馈成为可能。20世纪90年代以来，一些新的软件开发方法逐渐受到广泛关注，如XP（极限编程）、Scrum等，统称为敏捷开发。敏捷开发主要是通过高透明度、可测试性和适应性来管理复杂性、不可预测性和变化。以Scrum为例，典型的开发模型如下：这是一张广为引用的图，还有一张烂大街的图是Sprint的流程图：难点在于一个sprint周期有多长.个人认为Sprint周期的长短应该取决于你在Sprint的过程中能保持需求不变多长时间。敏捷是一种方式，而不是一种简单的方法，通过各种行为来达到目标??。首先，冲刺计划会议。为会议安排足够的时间，最好至少8小时。拿出一些产品需求做冲刺需求，写到索引卡上。识别并细分每个索引卡的故事（UserStory），然后进行工作认领（不是assignment）。还要确定每日站立会议的时间和地点，并确定演示会议和回顾会议的日期。站立会议是敏捷的一个显着特征。他们每次持续10-15分钟。迟到会受到惩罚。每个成员自问自答三个问题：昨天做了什么，今天要做什么，遇到了什么问题？交流问题的解决方案，最重要的是更新燃尽图。在开发过程中，使用任务看板关注产品的整个生命周期：需求、设计、开发、测试和维护。注意燃尽图。对于小团队，建议不要用软件来代替看板。它可以选择性地与XP或其他敏捷方法结合使用。演示会议至关重要。演示是跨团队的，导致不同团队之间的沟通。不要关注太多细节，专注于主要功能，让老板或客户看到。演示会非常重要，绝不能忽视。评审会一般持续1-3小时，需要找个最舒服的地方（最好有reviewboard）。从轮流发言开始，而不是主动发言。记录和总结问题，并讨论改进的方法，并放在审查板上。每个人将最重要的2-3个改进点作为下一轮产品需求的一部分。还是那句话，“没有灵丹妙药”，敏捷不是万灵药。Scrum的主要缺点是团队压力大，不方便跨时区、跨语言的团队协作，而且一旦启动就不能中断。更重要的是，程序维护成本高，对工程师的要求高，尤其是应用。体系结构和可扩展性。但是，敏捷开发的12条原则还是要了解的。我个人总结了一句话，照着花生酱，赞不绝口。ClicaccordingtoConcise：Concise开发要简洁，即尽量减少不必要的工作。这是一门艺术。精益：精益求精追求技术的卓越和设计的持续改进会提高敏捷性迭代：高速迭代必须持续交付可用的软件，从数周到数月不等，越短越好变化：拥抱需求的变化欢迎提出变化需求——甚至在项目开发的后期。善于利用需求变化帮助客户获得竞争优势。JifPeanutButterJoin：在全员参与项目的过程中，业务人员和开发人员必须共同努力。激励：员工激励要善于激励项目人员，给予他们所需要的环境和支持，相信他们能够完成任务。Face2Face：面对面交流无论是团队内部还是团队之间，最有效的交流方式就是面对面。Raves对Rethink赞不绝口：反思型团队定期反思他们如何才能更有效并相应地调整他们的行为可用性：可用首先可用的软件是衡量进展的主要指标。价值：尽快为用户带来价值最高目标是尽早持续交付有价值的软件来满足客户。均匀：敏捷过程促进可持续发展。项目方、开发人员和用户应该能够保持持续稳定的进度。自组织：自组织团队最好的架构、需求和设计来自自组织团队。敏捷开发乃至一般的开发流程都会涉及到一件事，任务预估，以及如何处理。个人认为一个任务最好以2小时为单位，设计半小时，编码半小时，测试半小时，文档、评论、重构半小时。原因可能是这样的。网上有一句名言——3个月就是一年，也就是1周相当于1个月。那么，2小时就相当于1天，也就是说，我们团队会把每两个小时算作一天。众所周知，所有的预估都是不准确的，以2小时为单位是为了减少误差。就像我们测量的时候，如果我们用米来测量，那么误差就是米，如果我们用毫米来测量，那么误差就是毫米。2小时的任务，相当于开发的“毫米”。敏捷开发最重要的是代码，优秀的代码质量决定了产品或服务的质量。我个人认为提高代码质量有四种方式：1）面向意图的编程，简单来说就是把注释变成代码，让代码不言自明2）测试驱动开发，尤其是后端最重要的是，它可以与日志系统相结合，更快速地定位问题。3）创建和使用分离，也就是常说的“高内聚低耦合”。4）单点修改原则。单点修改可能只是一种理想状态。但应该牢记这一点。至于敏捷团队，是我提倡的ABC：具体的，我在旧文《和 <创时代>》中有描述，这里不再赘述。对于团队敏捷，我只想澄清项目开发与产品开发之间的区别。两者还是有着不同的目标，比如持续演进、架构的可扩展性等等。老曹眼中的敏捷开发，还是以我喜欢的一行python代号为共勉：$python-c"importthis"TheZenofPython,byTimPeters美胜于丑。显式优于隐式。简单胜于复杂。复杂总比复杂好。扁平比嵌套好。稀疏比密集好。可读性很重要。特殊情况不足以违反规则。虽然实用胜过纯粹。错误不应该悄无声息地过去。除非明确沉默。面对模棱两可的情况，拒绝猜测的诱惑。应该有一种——最好只有一种——显而易见的方法来做到这一点。尽管这种方法一开始可能并不明显，除非你是荷兰人。现在总比没有好。尽管从来没有比*现在*更好。如果实现难以解释，那就不是一个好主意。如果实现很容易解释，那可能是个好主意。命名空间是一个很棒的想法——让我们做更多这样的事情！【本文来自栏作者老曹的原创文章，作者微信公众号：喔家ArchiSelf,id:wrieless-com】
