译者：这是DIB指南：检测敏捷BS （0.4版） ，美国国防部创新委员会（DIB）于2018年10月9日公开发布。

敏捷是软件开发中的流行语，因此现在国防部所有软件项目几乎都默认为“灵活”。 该文档将帮助项目经理和国防部专家以一种真正灵活的方法将软件项目与以敏捷为幌子的仅使用“瀑布”或“螺旋式”（“敏捷-scrum-fall”）的项目区分开。

原则，价值观和工具

敏捷专家和爱好者确定了表征这种文化和敏捷开发方法的关键指标。 DIB在工作中制定了自己的指南，这些指南大致反映了敏捷的真实价值：

敏捷价值	DIB原理
个人和互动比流程和工具更重要	“能力比过程更重要”
运行软件比完整文档更重要	“减少了从项目开始到部署最简单的基本功能的时间”
与客户合作以达成合同	“为软件系统实现DevSecOps文化”
响应转换计划	“程序应该从小处开始，要反复进行，并以成功为基础-否则它们会迅速回滚。”

该项目不太灵活的主要迹象：

• 没有开发团队与用户沟通或跟踪实际的软件； 我们指的是真实代码的真实用户。 （除非高级评估人员在工作中使用该程序，否则它不会像高级官员那样被视为真实的用户）。 与用户交流的可接受的替代方法：监视他们的工作，将原型传递给他们以征求反馈以及其他不涉及大量口头交流的研究方法。
• 用户没有针对开发团队的持续反馈（错误报告，评级）。 在项目开始时仅讨论一次就不够了！
• 合规性被认为比尽快获得最无用的结果更为重要。
• 利益相关者（开发，测试，DevOps，安全性，承包商，最终用户等）或多或少地自主运作（例如，“这不是我的事”）。
• 最终用户不参与开发； 至少，它们应该在发布计划和验收测试期间出现。
• 当手动执行可以并且应该自动化的流程时（例如，测试，持续集成，持续交付），DevSecOps文化不足。

一些典型的敏捷开发工具（它们随着
外观最好的）：

• Git，ClearCase或Subversion是一个版本控制系统，用于跟踪源代码中的更改。 Git是现代发展中的事实上的标准 。
• BitBucket或GitHub-托管存储库。 它还跟踪票证，具有用于持续集成的“应用程序”和其他工具来提高生产率。 开源社区广泛使用。
• Jenkins，Circle CI或Travis CI是用于构建和测试Bitbucket和GitHub项目的持续集成服务。
• Chef，Ansible或Puppet-用于创建用于配置的“配方”的软件，并广播配置任务并支持许多服务器。
• Docker是一种计算机程序，可以在操作系统级别执行虚拟化，也称为容器化。
• Kubernetes或Docker Swarm用于容器编排。
• Jira或Pivotal Tracker-票证，监控和管理。

图形版本：

给开发人员的问题

• 您如何测试代码？ （错误答案：“我们有专门的测试机构”，“测试和产品评估部门负责测试”）
  
  • 扩展版本：单元测试，回归测试，功能测试，安全扫描和部署认证使用哪些工具？
• 开发，测试，安全性和部署管道的自动化程度如何？
  
  • 扩展版本：您使用什么工具来进行持续集成（CI），持续交付（CD），回归测试，程序文档； 您的基础架构是代码驱动的吗？
• 您的用户是谁，以及您如何与他们互动？
  
  • 扩展版本：您使用什么机制来获取用户的直接反馈？ 您使用什么工具集来创建错误报告和跟踪故障单？ 您如何在团队之间分配错误修复工作？ 您如何通知用户他们的问题已经解决和/或已经解决？
• 当前和将来的发布周期的截止日期是什么？
  
  • 扩展版本：您支持哪些软件平台？ 您使用容器吗？ 您有哪些配置管理工具？

给项目经理的问题

• 分配预算的组织中有多少名程序员，该程序的主要阶段是什么？ （错误答案：“我们不知道”，“零”，“取决于程序员的定义”）
• 开发和运营的管理指标是什么？ 如何将它们用于传达优先事项，发现问题； 他们多久查看和使用一次手册？
• 您在最近的三个冲刺中学到了什么，以及如何应用新知识？ （错误答案：“什么是冲刺？”，“我们正在等待领导层的批准”）
• 从每个冲刺周期中受益的用户是谁？ 我可以和他们说话吗？ （错误答案：“我们不直接为用户部署代码”）

给客户和用户的问题

• 您如何与开发人员交流？ 他们会监督您的工作并提出相关问题以表明您对需求有深刻的了解吗？ 他们最后一次坐在附近什么时候讨论您想要看到的功能？
• 如何提交有关新功能的建议或报告代码中的问题或错误？ 您对查询/报告有什么反馈？ 您是否曾经被要求尝试新软件功能的原型并观看如何使用它们？
• 在应用程序中实现请求的功能需要多长时间？

指导问题

• 在每次迭代（包括第一次迭代）时，是否向至少一小部分真实用户提供了该软件的工作版本，并且是否收集了评论？ （提示：每两周一次）
• 是否有确定任务和战略目标的产品宪章？ 所有团队成员都理解吗？ 他们是否看到他们的工作如何有助于实现目标？
• 用户审查是否将冲刺团队的特定任务变成了期限少于一个月的任务？
• 团队是否有权根据用户反馈更改要求？
• 团队是否有权根据他们在开发过程中学到的知识来更改其流程？
• 您项目的整个生态系统是否灵活？ （如果敏捷开发之后是线性，官僚的实施过程，那么这将是失败的。）

对于敏捷团队，所有这些问题的答案应该是。

图形版本：



关于国防部计划的某些功能的更多详细信息，包含在附录A（ 十个软件要求 ），附录B（ 软件开发指标 ）和附录C（软件错误和规则）中[稍后将添加链接] ）