当软件开发人员听到关于“新的JavaScript框架”或“新的IDE”的消息时,他不需要问更多的问题来澄清这是关于什么的. 但如果他听说了 新的敏捷框架, 他可能会像荷马·辛普森那样点头, 假装他知道是怎么回事, 但他会有一个, 只有一个, 问题: “敏捷框架”到底是什么意思?

在现代软件开发环境中, 我们越来越多地听到像“敏捷”这样的词,”“scrum,和“看板”,，它们经常被不恰当地使用. 在本文中，我将尝试解释和澄清其中的一些术语.

敏捷

如果你想成为人群中的聪明人, 当你在谈论工作过程时，你应该在每句话中都使用“敏捷”这个词. 它的范围很广, 没有义务让你对你正在谈论的话题了解得更多吗, 这是一个非常好的形容词或副词:“思维敏捷”,敏捷方法,”“根据敏捷原则.但是“敏捷”到底是什么意思呢?

“敏捷”指的是“敏捷软件开发，即遵循敏捷原则的开发方法. 但是什么是“敏捷原则”呢?“看一下 敏捷宣言 在 敏捷的12个原则，为敏捷开发奠定了基础. 《欧博体育app下载》:

敏捷原则鼓励持续交付功能良好的软件, 团队之间的紧密沟通, 对不断变化的需求有很高的适应性. 如果你在工作中遵循这些价值观和原则, 你可以说你在一个敏捷的环境中工作. So, 敏捷软件开发不是一种方法论, 它只是一套不同的方法, 框架, 以及遵循相同原则的技术. 可以说，“敏捷”是一种 框架 思考和做决定.

但为什么在我们的工作中遵循这些原则如此重要呢?

宣言和原则是几十年来为应对软件开发的挑战而寻找最佳解决方案的结果. 整个70年代, 80s, 和90年代, 世界各地不同的开发人员和团队一直在尝试各种工作方法和解决问题的方法, 发明 不同的框架 和技术(比如scrum和极限编程), 甚至可以并行地得出相同的想法. 最后, 2001年2月, 17名开发者聚集在一起，为所有这些不同的想法和经验找到了共同点. 宣言就是这样诞生的.

Scrum

如果你谈到 敏捷和. scrum 不知道其含义的方法, 你可能会说错，说的话会在了解这个话题的对话者面前暴露你的身份:“Scrum和其他敏捷方法.”

Scrum不是一种方法论，尽管我们都听到过这样的说法，而不是美国的杀人事件数量 权力的游戏. Scrum不会对每个问题都给出答案, 它也不会给你提供应对你所面临的每一种情况的精确程序. 很可能是这种错误解释的结果, 大多数scrum实现也是错误的:团队没有获得价值. 这可能会导致关于scrum最愚蠢的说法:“scrum不起作用.”

什么是scrum? Scrum指南 将scrum定义为:

所以它是。 框架和其他框架一样，它也可能被错误地使用，而且经常被错误地使用. 有效地使用scrum不仅需要采用scrum设定的结构, 但是在整个团队中对敏捷原则有深刻的理解和欣赏.

Scrum由以下角色组成:产品负责人、Scrum Master、开发团队.

还有四种Scrum仪式:计划会议, 每日例会, 冲刺评审, Sprint回顾

还有三个工件:产品待办事项列表，冲刺待办事项列表，产品增量.

Scrum项目被组织成固定的时间框架，我们称之为sprint. 它们通常持续两周.

A 产品负责人 负责指导项目的方向. 当确定了新的任务和特性时，产品负责人将它们添加到产品待办事项列表中. 冲刺从计划会议开始，开发团队从待办事项中选择要处理的任务，并计划如何实现这些任务. 然后是发展, 在此期间，开发团队使用待办事项列表来跟踪进度，并为每日会议召开会议，以同步活动并调整计划, 如果需要. 开发的结果应该是产品增量, 可以应用于产品并立即发布的内容. 在冲刺结束时, 产品增量在sprint评审时呈现给产品负责人, 如果需要进一步的更改，产品待办事项列表在哪里增加. 后来, 整个团队参加sprint回顾会议，讨论工作流程以及如何改进工作流程.

学习和理解scrum很容易，但很难采用. 这个框架可能适合项目，也可能不适合项目，原因很多. 它通常需要很多变化，不仅在日常发展中，而且在文化上. Scrum最适合复杂产品的开发, 他们会持续很长时间，包括不同类型的专家.

为什么scrum如此受欢迎，为什么它比传统的瀑布模型有优势? 简单地说，因为它为产品和客户提供了更多的价值. 使用“重量级”方法，如瀑布, 恐怖的故事层出不穷，几个月都没有人看到这个项目. 在scrum中，这是不可能的.

Scrum是关于 价值 这是交付给最终用户的. 如果你真的使用scrum，你需要在每个sprint中交付一些有价值的东西. 该值是可以测量的, 团队还被迫检查障碍并进行调整, 目标是在下一次迭代中交付更多的价值.

In most software development we are not building a skyscraper; we don’t need to have the whole plan ready before we start, 坚持到最后. 我们正在开发软件, 我们有能力适应不同的情况，并在开发过程中改变产品的要求. 很长一段时间, 许多开发者认为这是第八宗罪, 但从产品的角度来看，这对优化可预测性和控制风险是一个巨大的好处. Scrum就是围绕这种能力开发的, 它的实施为处理必要的变化提供了一种可靠而有效的方法.

许多技术与scrum结合使用:计划扑克, 结对编程, 测试驱动开发, 行为驱动开发 (BDD)等. 它们并不是scrum的一部分，而是兼容的技术. 与scrum同时被提及的一种方法是看板, 人们对这两者之间的关系有很多困惑.

看板

当你谈论scrum和. 看板，一个经常被问到的问题是，“scrum和看板哪个更好??你不知道该怎么回答，因为这就像比较苹果和橘子一样, 或问, “哪个更好?”, 煎饼还是啤酒?“两者都更好。.

看板是一种简单的方法，旨在及时交付，同时不使团队成员负担过重. 它与scrum的相似之处在于，目标是在最后交付最大的价值, 但它比scrum灵活得多.

看板不是软件开发社区发明的. 事实上, 它起源于丰田的生产流程, 在其他领域也有广泛的应用. 没有什么严格的程序是你必须遵循的, 和 no strict way you should implement 和 use kanban; it is, 而, 一套原则和实践, 您可以根据自己的需要从这些实践中进行选择. 但是在软件开发中有一种最常用的看板实现，它包括一个 看板，由表示工作阶段和任务的列组成.

列表示开发过程中任务的状态. 最简单的例子由三列组成:“To Do”、“In Progress”和“Done”.” So, 任务被添加到“待办事项”中,，在开发开始时变为“进行中”, 当移到最后一栏时，认为“完成”. 当然，情况可能更复杂:

待办事项→定义规范→准备开发→开发→代码审查→测试→部署(→没有人真正使用→完全删除).

Every column can have subcolumns; for example, “Development” can be divided into “Planning” 和 “Coding”; “Testing” can be divided into “[Unit Testing]”(http://wlmqn.946543.com/qa/how-to-write-testable-code-和-why-it-matters)和“集成测试”等等. 如果合适的话，专栏可能专门针对专家. 团队根据需要定义列和阶段. 根据“拉”哲学, 任务应该只在对它们的需求非常迫切时才进入工作流.

这个板的目的是 可视化工作流，这是第一次 看板中的关键实践. 事实上，看板可以在没有板子的情况下完成! 它可以是Google工作表中的简单任务列表，用不同的背景颜色指示任务的状态, 也可以是甘特图, 图, 甚至可能是你办公室里的一组水桶, 其中每个代表任务的状态, 在那里球被用作任务. 只需可视化工作流程，并为整个过程提供透明度.

另一个重要的原则是 减少工作的批量大小. 简而言之，这意味着避免多任务处理. 这意味着减少你同时处理的任务数量. 如果你的团队中有三个设计师, 团队可能会将“设计”列中的最大任务数设置为3.

像scrum, 敏捷中的看板方法也将团队视为过程中最重要的角色. 但它并不像scrum那样建议角色, 您可以保留现有的角色，以避免对现有流程进行更改. 这同样适用于持续改进:看板通常鼓励你不断学习和改进, 但并没有为这个过程规定一个特定的事件, scrum的Sprint回顾也是如此.

敏捷和. 看板和. Scrum:我应该使用哪个?

Scrum和看板并不是相互排斥的，也没有可比性. 在scrum中,, 有明确的角色, 看板说的是, “搞什么鬼?”, 保持你目前的角色和职责.” Scrum will force you to change your way of working; kanban lets you start with your existing process. 在scrum中,, a clear schedule for events is prescribed by the 框架; in kanban you don’t have events. 然而,, 它们有很多相似之处:都是以价值为中心的, 团队成员被尊为系统的“老板”, 和本质上, 他们有同样的使命:不断地消除浪费，消除障碍.

但问题是，“我应该在我的特定项目和特定团队中使用什么??就更有意义了. 看板不需要太多的流程和文化变化, 和, 在大多数情况下, 它比scrum更容易采用. Scrum, 另一方面, 提供了更多的结构来指导过程, 只要每个人都在同一页上，哪一个可以消除大量的开销.

但两者的美妙之处在于，它们都不是一套严格的规则. 没有什么能阻止你挑选最适合自己的scrum元素, 比如每天的会议或回顾. 你没有理由不把看板纳入scrum.

当整个团队都很好地理解Scrum时，它已被证明是一个非常有效的框架. 然而，根据我的经验，我发现很难与一些客户进行scrum工作. 正确实施scrum所需的流程和文化变化可能太多了(尤其是在与那些认为自己正在打造一个新谷歌的人打交道时)!). 另一方面，看板更灵活，不会强迫人们做出改变. 一些作者还说看板是实现敏捷的好途径, 并且提供了更容易实现scrum的方法. 另一些人说，使用scrum应该最终导致看板.

事实上，每个项目都是不同的，没有放之四海而皆准的解决方案. 作为一个项目经理，决定什么最适合你的团队是由你来决定的.