敏捷和精益
As promised here’s the part 2 of my Lean and Agile article. Before you go further do make sure to read the part 1. This part concludes my findings about the two modern software development paradigms.
正如承诺的那样，这是我的精益和敏捷文章的第二部分。 在继续之前，请务必阅读第1部分 。 这部分总结了我对两种现代软件开发范例的发现。
精益敏捷 (Lean is Agile)
In the previous part the values and principles of lean and agile were introduced. The first look at them leads to the direct conclusion that lean and agile share many common thinkings and both way of thinkings arose with one main goal “reducing the waste”. This sections describes the similarities between the two.
在上一部分中 ，介绍了精益和敏捷的价值和原则。 初看它们会得出直接的结论，即精益和敏捷共享许多共同的思想，并且两种思想都以一个“减少 浪费”的主要目标出现。 本节描述了两者之间的相似之处。
减少软件开发中的浪费 (Reduction of Waste in Software Development)
As already mentioned lean processes focus on reducing the waste. According to Mary and Tom Poppendieck, the lean software development begins with the identification of the “Value Stream” in the software development of the organization (Poppendieck, M. & Poppendieck, T., 2003). This means identifying every process and step that does not lead (directly or indirectly) to the value adding and eliminating or optimizing them.
如前所述，精益生产Craft.io着重于减少浪费。 根据Mary和Tom Poppendieck的说法，精益软件的开发始于组织软件开发中“价值流”的识别(Poppendieck，M.和Poppendieck，T.，2003)。 这意味着识别出不会(直接或间接)导致增值，消除或优化它们的每个过程和步骤。
The four agile principles of Individuals and Interactions, Working Software, Customer Collaboration and Responding to Change ingrain the reduction of every unnecessary step (waste) such as rigid processes, comprehensive documentation, contract negotiation as these do not lead to quality improvement and may only cause delay and customer dissatisfaction.
个人和互动，工作软件， 客户协作和对变化的响应这四项敏捷原则根深蒂固地减少了 不必要的步骤(浪费)，例如严格的流程，全面的文档编制，合同谈判，因为它们不会导致质量改善，只会导致延迟和客户不满意。
尊重人 (Respecting people)
Both lean and agile methodologies realize that the individuals, the teams are the backbone of every successful software development project (Bente, S. et al., 2012 p. 180). Sections 2.2.1 and 3.3.5 discussed the importance of individuals.
精益和敏捷方法论都认识到，个人和团队是每个成功的软件开发项目的骨干(Bente，S.等人，2012，p。180)。 第2.2.1和3.3.5节讨论了个人的重要性。
The Agile Manifesto defines more than one principle that make the importance of respecting and motivating the individuals clear:
敏捷宣言定义了多个原则，这些原则使尊重和激励个人的重要性变得清晰起来：
Business people and developers must work together daily throughout the project.
在整个项目中，业务人员和开发人员必须每天一起工作。
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
围绕有积极性的人建立项目。 给他们提供所需的环境和支持，并信任他们来完成工作。
The best architectures, requirements, and designs emerge from self-organizing teams.
最好的体系结构，需求和设计来自自组织团队。
The lean methodologies in manufacturing (or in any field) also aim to acknowledge the importance and role individuals in the success of a project. Mary and Tom Poppendieck consider Self-Determination, Motivation, Leadership and Expertise as the main tools to “Empower the team” and treat them like volunteers.
制造(或任何领域)中的精益方法论还旨在承认个人在项目成功中的重要性和作用。 玛丽和汤姆·波彭迪克(Mary and Tom Poppendieck)将自我决定，动机，领导能力和专业知识视为“增强团队能力”并像志愿者一样对待他们的主要工具。
欢迎变化 (Welcoming Changes)
“The waterfall stereotype is patterned around greenfield development. It doesn’t easily accommodate the constraints of any embedded base to which the new software must fit, nor does it explicitly provide for future changes in requirements, nor does it project what happens after the first delivery.” (Bjørnvig, G. & Coplien, J., 2010 p. 11)
“瀑布定型观念围绕着未开发的土地而形成。 它不能轻易适应新软件必须适合的任何嵌入式基础的约束，也不能明确提供未来需求的变化，也不能预测首次交付后会发生什么。” (Bjørnvig，G.＆Coplien，J.，2010 p.11)
Both the lean and agile methods of software development welcome changes and encourage the learning from mistakes rather than the rigid approach of Waterfall Model where changes and mistakes are considered to be fatal. The agile value “Responding to change over following a plan” follow the same objective as the lean values of “Deliver as fast as possible” and “Amplify learning” as both consider the software development as an iterative process rather than the sequential phases in Waterfall, although both follow a slightly different approach which will be discussed in section 5.
精益和敏捷的软件开发方法都欢迎更改并鼓励从错误中学习，而不是采用瀑布模型的僵化方法，因为瀑布模型中的更改和错误被认为是致命的。 敏捷值“响应计划的转换”遵循与精益目标相同的目标 “交付尽可能快”和“放大学习”这两个值都被视为软件开发是一个迭代过程，而不是Waterfall中的顺序阶段，尽管两者都遵循略有不同的方法，这将在第5节中进行讨论。
软件质量 (Quality of Software)
“Working software is the primary measure of progress” is one of the twelve agile principles, which may lead to the misbelief that the agile methodologies do not concentrate on the quality of software. Further principles of “Continuous attention to technical excellence and good design enhances agility” and “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly” focus on improving the quality of the processes and thus that of the software constantly.
“工作软件是进度的主要衡量标准”是十二种敏捷方法之一 原则，这可能会导致人们误认为敏捷方法论并不专注于软件质量。 “持续关注 技术卓越和良好设计可增强敏捷性”的进一步原则和“团队定期思考如何提高效率，然后相应地调整和调整其行为”，着重于提高流程质量，从而的 软件不断。
“Building Integrity In” and “Optimize the Whole” also target the improvement of the quality of software and its development processes in a lean organisation. Mary and Tom Poppendieck suggest tools such as Refractoring, Testing, Measurements to ensure a continuous improvement in the development.
“建立诚信”和“优化整体”也旨在改善 一个精益组织的软件质量及其开发过程。 Mary和Tom Poppendieck提出了折射，测试，测量等工具，以确保开发的持续改进。
精益与敏捷 (Lean vs. Agile)
The last section explained some similarities between the lean and agile approach to software development. As the lean thinking emerged from the large-scale production and agile practices were specifically defined for software development there are some differences in their respective approaches.
最后一部分解释了精益和敏捷方法在软件开发中的一些相似之处。 随着大规模生产中出现精益思想，并且为软件开发专门定义了敏捷实践，它们各自的方法也有所不同。
计划做检查行动 (Plan-Do-Check-Act)
Most of the agile methods rely on learning by doing. According to the value of “Responding to change over following a plan” the developers are expected to “inspect and adapt” (Shalloway, A. et al., 2010 p. 81). This approach leaves the team figure out the best way of executing the goal based on their own experience and intuitions. This allows the errors to be corrected quite fast but does not try to avoid the errors to begin with. Agile is thus, more about doing. Lean on the other hand is about thinking and doing (Bjørnvig, G. & Coplien, J., 2010 p. 13). The “Plan-Do-Check-Act” approach requires the team to follow a specific work-flow and does not leave them in dark. The team plans what to do, executes it, checks the result and act accordingly, which may lead to planning again (Shalloway, A. et al., 2010 p. 81). This could avoid a lot of doing and even re-doing and reduce the waste. Lean even suggests planning for changes whereas agile responds to changes.
大多数敏捷方法都依赖边干边学。 根据“响应按照计划进行的转换”的价值，开发人员应“检查并适应” (Shalloway，A.等，2010，第81页)。 这种方法使团队可以找出最佳方法 根据自己的经验和直觉执行目标。 这样就可以非常Swift地纠正错误，但是并不能避免发生错误。 因此，敏捷更多地是在做 。 另一方面，精益则是思考和做事 (Bjørnvig，G.＆Coplien，J.，2010 p。13)。 “计划-执行-检查-执行”方法要求团队遵循特定的工作流程，而不要让他们陷入困境。 该团队计划做什么，执行，检查结果并采取相应的行动，这可能会导致再次进行计划(Shalloway，A.等，2010，第81页)。 这样可以避免很多事情甚至重复做， 从而减少浪费 。 精益甚至建议对变化进行计划，而敏捷则对变化做出React。
整体思考 (Thinking about the Whole)
Most of the lean values are directly or indirectly covered by the agile practices. But, the principle of “See the whole” is a missing aspect in agile methods (Bente, S. et al., 2012 p. 182). For example Scrum suggests never to plan beyond the current sprint (Shalloway, A. et al., 2010 p. 90) to keep the work simple which may be seem true for small projects, but difficult for Scrum to be used in large-scale projects or in large teams.
敏捷实践直接或间接地涵盖了大多数精益价值。 但是， “查看整体”原则是敏捷方法中缺少的一个方面(Bente，S.等人，2012 p。182)。 例如，Scrum建议不要计划超出当前的冲刺(Shalloway，A.等人，2010，第90页)，以保持工作简单，这对于小型项目而言似乎是正确的，但对于大规模使用Scrum而言却很难。项目或大型团队。
Lean has a different point of view here. Each step is to be considered as a part of the whole. As explained in section 3.3.7 software development is a more than just coding and the success of the project also depends on the management of the organisation. Lean applies thus to all the levels of the organization and not just the software development (Shalloway, A. et al., 2010 p. 6). Each area, business, management and software development, must focus on using lean principles to achieve the common goals.
精益在这里有不同的观点。 每个步骤都应视为整体的一部分。 如第3.3.7节所述，软件开发不仅是编码，项目的成功还取决于组织的管理。 因此，精益不仅适用于软件开发，还适用于组织的所有级别(Shalloway，A.等，2010，第6页)。 业务，管理和软件开发的每个领域都必须专注于使用精益原则来实现共同的目标。
精益敏捷 (Lean-Agile)
“Lean is often cited as a foundation of agile, or as a cousin of agile” (Bjørnvig, G. & Coplien, J., 2010 p. 12). Both the methodologies follow the same goal of optimizing the software development process, but follow different directions, top-down for lean and bottom-up for agile (Bente, S. et al., 2012 p. 181).
“经常将精益作为敏捷的基础或敏捷的表亲” (Bjørnvig，G.＆Coplien，J.，2010 p。12)。 这俩 方法论遵循优化软件开发流程的相同目标，但是遵循不同的方向，即自上而下的精益和自下而上的敏捷(Bente，S. et al。，2012 p。181)。
Lean emerged from the large-scale production systems that tend to see the whole and find simple solutions for complicated problems, whereas agile is structured to deal with complex problems where the main problem is to deal with the unknown. The software development teams can benefit through the combination of these two approaches. For example, large-scale software that require significantly large amount of time can benefit from the top-down and analysis characteristic of lean and the software component that interact with people and is almost impossible to predict would appreciate the principles of agile in the development process (Bjørnvig, G. & Coplien, J., 2010 p. 9). This section will introduce some approaches where lean and agile can complement each other.
精益是从大型生产系统中产生的，这些系统通常可以看到整体并为复杂的问题找到简单的解决方案，而敏捷的结构是处理复杂的问题，而主要的问题是处理未知的问题 。 通过将这两种方法结合起来，软件开发团队可以从中受益。 例如，需要大量时间的大型软件可以从精益的自上而下和分析特性以及与人互动的软件组件中受益，并且几乎无法预测会从敏捷的原理中受益于开发过程(Bjørnvig，G.＆Coplien，J.，2010 p.9)。 本节将介绍App.svelte和敏捷可以相互补充的一些方法。
摆脱等待时间 (Getting rid of Wait times)
As discussed earlier waste is the pivot of lean thinking. The wait times in software development is a main cause of waste, which should be removed for more efficient work. Some agile practices, such as Scrum, may have following wait times (Starr, D., 2012):
如前所述， 浪费是精益思想的关键。 软件开发中的等待时间是造成浪费的主要原因，应将其删除以提高工作效率。 一些敏捷实践(例如Scrum)可能需要以下等待时间(Starr，D.，2012)：
- Permission to do something 允许做某事
- A hand-off from another team or individual 从另一个团队或个人移交
- Tests to be run or validation to be completed 进行测试或完成验证
- Access to a needed resource 访问所需的资源
- The Sprint itself 冲刺本身
The Scrum teams work in Sprints and releasing features at the end of the Sprint. This may lead to wait times in integrating the features to form a base line if more than one teams are working on different set of features and may take more or less different amount of time.
Scrum团队在Sprint中工作，并在Sprint末尾发布功能。 如果多个团队正在研究不同的功能，这可能会导致集成功能以形成基线的等待时间，并且可能会花费或多或少的时间。
The lean approach suggests Continuous Integration in such a case. The teams may integrate the features as soon as the work is “done”. Which would reduce the wait times. Continuous Integration also leads to reducing the amount of Work in Progress. The lean thinking recommends having fewer completed user stories rather than having many 90% WIPs.
精益方法建议在这种情况下进行持续集成。 一旦工作“完成”，团队可能会集成功能。 这将减少等待时间。 持续集成还可以减少进行中的工作量。 精益思维建议完成的用户故事要少一些，而不要有90％的WIP。
建筑与设计 (Architecture and Design)
The 12 agile principles include the statement “the best architectures, requirements, and designs emerge from self-organizing teams”. This if literally interpreted means that the software architecture and design could be neglected. Agile doesn’t mean this though, but the lean-agile approach could help avoiding over- and under-architecture and design. One of the main agile values is to “respond to change”, but a lean approach would rather design for change so that the software developers could respond to the changes quickly (Shalloway, A. et al., 2010 p. 206). This could be achieved if an architecture comprises of following (Shalloway, A. et al., 2010 p. 205):
这12条敏捷原则包括“ 自组织团队中出现 的最佳架构，要求 和设计 ”的说法。 如果按字面解释，这意味着 可以忽略软件体系结构和设计。 敏捷并不意味着这个，但是精益敏捷的方法可以帮助避免架构的过度和不足。 敏捷的主要价值观之一是“响应变更” ，但精益的方法宁愿设计变更，以便软件开发人员可以快速响应变更(Shalloway，A. et al。，2010 p。206)。 如果架构包含以下内容，则可以实现这一目标(Shalloway，A.等，2010 p。205)：
- The code is written quickly. 代码写得很快。
- The code can be changed quickly. 可以快速更改代码。
- The changes do not break the system. 所做的更改不会破坏系统。
- If the changes do break the system, it should be detected automatically 如果更改确实破坏了系统，则应自动检测到
“Agile keeps the links in the value stream consistent with each other through individuals and interactions over processes and tools. The feedback in Agile supports Lean’s goal of consistency, while Lean’s trimmed and fit processes make Agile change more flexible. Together, all of these contribute to reduced time and cost.” (Bjørnvig, G. & Coplien, J., 2010 p. 38)
敏捷通过个人以及流程和工具之间的交互，使价值流中的链接彼此保持一致。 敏捷中的反馈支持精益的一致性目标，而精益的精简和调整流程使敏捷变更更加灵活。 所有这些共同有助于减少时间和成本。” (Bjørnvig，G.＆Coplien，J.，2010，第38页)
没有自我指导的团队 (No self-directing Teams)
One of the misconceptions of the agile way of thinking is that the self-directing teams, alone, could improve continuously and succeed on long-term. This may work in a small organization or for small project, but purely self-directing teams have a history of failures (Shalloway, A. et al., 2010 p. 89).
对敏捷思维方式的误解之一是，仅凭自我指导的团队就可以不断改进并取得长期成功。 这可能适用于小型组织或小型项目，但纯粹的自我指导团队有失败的历史(Shalloway，A.等，2010，第89页)。
Mary and Tom Poppendieck mentioned four tools to empower the team: self-determination, motivation, leadership and expertise (Poppendieck, M. & Poppendieck, T., 2003). Self-organizing teams may achieve self-determination and expertize on their own, but the motivation and leadership aspect is the job of a good management team. A continuous improvement, Kaizen, can only be achieved through a partnership between the teams and management. The most crucial role of the project managers is to ask intelligent questions and establish an environment of respect in which leadership and collaboration can co-exist together without being an autocrat or a handsoff manager (Shalloway, A. et al., 2010 p. 89).
Mary和Tom Poppendieck提到了增强团队能力的四个工具：自决，动机，领导能力和专业知识(Poppendieck，M。和Poppendieck，T.，2003年)。 自组织团队可以自行实现自我决定和专业化，但是动机和领导才能是一支优秀管理团队的职责。 持续的改进Kaizen只能通过团队和管理层之间的伙伴关系来实现。 项目经理的最关键作用是提出明智的问题，并建立一种尊重的环境，在这种环境中，领导和协作可以共存而不必成为专制或移交经理(Shalloway，A. et al。，2010 p。89) )。
This article explained how agile software development emerged through the limitations of the more traditional process models like Waterfall, where the core beliefs were that one can know everything required to build a software right at the beginning. The agile methodologies are based on the experience of most of the software developers that even the customer doesn’t know at the start what the software should exactly achieve. Agile methodologies focus on interactions, working software and to be able to respond to changes.
本文解释了敏捷软件开发是如何通过瀑布等更传统的流程模型的局限性出现的，该流程模型的核心信念是，人们一开始就可以知道构建软件所需的一切。 敏捷方法基于大多数软件开发人员的经验，即使客户一开始都不知道该软件应确切实现什么。 敏捷方法论着眼于交互，工作软件并能够响应变化。
On the other hand, lean software development finds its core in the lean manufacturing where the main focus lies on reducing the waste. Mary and Tom Poppendieck made the term lean software development and translated the lean principles to software development. Just as agile, lean focuses on respecting people, eliminating processes that do not add to value.
另一方面，精益软件开发是精益制造的核心，精益制造的重点是减少浪费。 Mary和Tom Poppendieck创造了精益软件开发一词，并将精益原理转化为软件开发。 就像敏捷一样，精益专注于尊重人，消除不会增加价值的过程。
Agile software development focuses more on developing a software as it was initiated by a group of veteran software developers, whereas the lean thinking tries to optimize the whole and not “just” the software development. Section 6 showed how lean and agile complement each other. The principle-driven and top-down lean techniques are closely related to the more practice-driven and bottom-up agile techniques (Bente, S. et al., 2012 p. 182). Lean software development can not exist on its own as it borrows methods and tools from agile to implement the its principles, such as iterations, continuous integration, test-driven development etc. On the other hand, combining lean thinking, like optimizing the whole, to agile helps overcome the greatest limitation of the agile practices, the scaling-up.
敏捷软件开发更多地侧重于由一组资深软件开发人员发起的软件开发，而精益思想则试图优化整体而不是“仅仅”进行软件开发。 第6节显示了精益和敏捷如何相辅相成。 原则驱动和自上而下的精益技术与实践驱动和自下而上的敏捷技术密切相关(Bente，S. et al。，2012 p。182)。 精益软件开发不能独立存在，因为它借鉴了敏捷性的方法和工具来实现其原理，例如迭代，持续集成，测试驱动的开发等。另一方面，结合了精益思想，例如优化整体，敏捷有助于克服敏捷实践的最大局限性，即扩大规模。
The relationship between lean and agile could be summed up by the following statements:
精益和敏捷之间的关系可以通过以下语句来总结：
“Lean defines principles, whereas agile describes practices” (Bente, S. et al., 2012 p. 181)
“精益定义原则，而敏捷则描述实践” (Bente，S.等人，2012第181页)
“Lean principles lie at the heart of architectures behind Agile projects.” (Bjørnvig, G. & Coplien, J., 2010 p. 13)
“精益原则是敏捷项目背后架构的核心。” (Bjørnvig，G.＆Coplien，J.，2010第13页)
Thank you for reading. Hope you enjoyed it. Cheers
感谢您的阅读。 希望你喜欢。 干杯
翻译自: https://medium.com/@samir.ar.2810/lean-and-agile-contrasting-and-complementary-part-ii-7627dd807bee
敏捷和精益