本文概述
- 什么不是敏捷？
- 什么是敏捷？
- 值是什么？
- 敏捷原则
- 敏捷是一种有时间限制的迭代方法, 可以逐步而不是一次全部构建项目。
- 敏捷是一种在整个软件中促进开发和测试的连续迭代的实践。
- 进行会议团队每天进行10-15分钟的频繁会议, 他们认为进行频繁会议将是敏捷的。但是, 只有以下会议不会敏捷。
- 随时更改需求可以随时更改需求, 所以它不是敏捷的。例如, 客户想要添加一些新功能并希望同时更新更改, 那么这将不是敏捷的。
- 非结构化开发假设你没有遵循任何计划, 并且你在Adhoc的基础上工作, 那么在进行Adhoc测试时, 测试人员会随机测试应用程序, 而无需遵循任何文档和测试设计技术, 因此这不是敏捷的。
- 没有文档如果公司不提供文档, 则说明它不是敏捷的。
- 敏捷是一种哲学, 即为开发软件做出决策的一组价值观和原则。
- 敏捷基于迭代增量模型。在增量模型中, 我们以增量创建系统, 其中每个增量都是单独开发和测试的。
文章图片
上图显示了敏捷模型如何逐步工作。
值是什么？
| 个人与互动 | 流程和工具。 |
| Working software | 全面的文档。 |
| 客户合作 | 过度合同谈判 |
| 应对变化 | 超过计划 |
- 个人和交互, 过流程和工具假设团队在软件中发现任何问题, 然后他们搜索另一个流程或工具来解决问题。但是, 在敏捷中, 最好与客户, 经理或团队就问题进行互动, 并确保问题得到解决。
- 工作软件, 全面的文档是必需的, 但是非常需要工作软件。敏捷并不是说不需要文档, 但是非常需要工作软件。例如, 你有20页的文档, 但没有该软件的单个原型。在这种情况下, 客户将不满意, 因为最终客户需要文件。
- 客户协作, 过度合同谈判合同谈判很重要, 因为他们要制定软件预算, 但是客户协作比过度合同谈判更重要。例如, 如果你坚持要求或流程, 则不要签订我们已经协商的合同。你需要与客户互动, 收集他们的需求。
- 在计划之后对变化做出响应在瀑布模型中, 所有事情都已计划好, 即什么时候完成每个阶段。有时你需要在软件的中间实现新的要求, 因此你需要具有多功能性才能对软件进行更改。
- 我们的首要任务是通过尽早并持续交付有价值的软件来满足客户。根据敏捷原则, 客户就是他们的一切。无论客户需要什么, 他们有任何问题或想要添加新的要求, 他们总是将客户放在首位。听客户说他们的话, 并向他们提供优质的软件。
- 它欢迎不断变化的需求, 甚至在开发的后期。敏捷流程利用变化来满足客户的竞争优势。在瀑布模型中, 如果要在软件中间进行任何新更改, 则整个过程将再次执行。因此, 瀑布模型是刚性的而不是通用的。敏捷说, 工作就像这样, 以便可以将新更改轻松地集成到软件中。
- 频繁交付工作软件, 从几周到几个月不等, 而更倾向于缩短时间。就像瀑布模型一样, 当开发整个系统时, 只有将其交付给客户, 而敏捷则表示不要等待太久, 而要等待几周或几个月。无论你开发了什么, 都可以向客户进行演示, 这可以使客户对软件有个初步的了解。
- 在整个项目中, 业务人员和开发人员必须每天一起工作。这意味着客户, 客户和团队应该每天互动。
- 围绕有上进心的个人构建项目, 为他们提供所需的环境和支持, 并信任他们能够完成工作。敏捷说, 相信??你的团队, 客户, 公司。假设给团队成员一个任务, 然后提供他需要的所有资源, 例如文档, 系统, 信息研究等。
- 向开发团队内部和内部传达信息的最有效的方法是面对面的对话。假设在某些情况下需要与客户, 开发团队进行交互, 通常是通过邮件或电话进行的, 但是最好进行面对面的对话。
- 工作软件是进度的主要衡量标准。敏捷说, 开发的内容既不是通过文档, 也不是你的项目经理说的, 开发的软件数量或工作量是进度的衡量标准。
- 敏捷过程促进可持续发展。赞助者, 开发者和用户应该能够无限期地保持恒定的步伐。敏捷说, 使你的团队的交付保持恒定, 以便团队应该有固定的工作时间, 这意味着如果公司的工作时间为8个小时, 则团队每天应该工作8个小时。
- 持续关注技术卓越性和良好的设计可增强敏捷性, 这意味着团队成员应具有良好的技术水平, 以便在进行任何更改后可以进行良好的设计, 然后可以轻松地将其合并到软件中。
- 最好的体系结构, 需求和设计来自自组织团队。无论架构团队进行什么设计, 他们都必须确保与开发团队一起坐下来讨论软件的架构。
- 团队会定期检查如何提高效率, 然后相应地调整和调整其行为。该原则表示, 团队应该经常开会, 以便他们可以讨论他们面临的问题并可以有效解决。
