|
|
9 回复 | 直到 6 年前
|
1
20
首先,去读 Twelve Principles of Agile Software . 其次,从你知道的事情中找出如何实现对你来说最重要的原则。
这不是它的本意。你已经列出了15个“最佳实践”,这让我有点害怕。不要太认真,也不要想得太多。如果你发现你漏掉了什么…在下一个迭代中得到它。 |
|
2
17
This text
总结所有敏捷最佳实践(带有链接):
|
|
|
3
14
我正在读《敏捷的成功》。在第二章中,迈克·科恩提出了一个可怕的警告:不要建立任何形式的“最佳实践”:
他接着引用丰田的大野泰一的话: “……有一种叫做标准工作的东西,但标准应该不断改变。相反,如果你认为标准是“你能做的最好的”,它就结束了。。。[如果我们建立一个尽可能好的方法,改善(持续的渐进改进)的动力就会消失。” Succeeding with Agile: Software Development Using Scrum, Mike Cohn, 2010 |
|
|
4
4
您可以添加一些非常重要的内容:
|
|
5
4
列出一个最佳实践列表看起来像是敏捷转换的BDUF。如果你想变得敏捷,试着以敏捷的方式达到目的。 你现在的流程最糟糕的问题是什么?你能改变什么来解决这个问题?试试看效果如何。 冲洗并重复。 作为一个团队完成所有这些。 编辑: 有些东西很难在评论中合理地表达出来,所以我将在这里进一步介绍一些评论:
如果您的测试覆盖率不高,那么您可能交付的软件存在缺陷,或者在不引入缺陷的情况下进行更改是困难和耗时的。这些都是问题。 如果人们拒绝编写测试,要么他们不相信有问题,要么他们不相信编写单元测试可以解决问题,要么他们不在乎。 最好的办法就是和你的团队聚在一起,决定问题所在,并就需要改进的地方达成一致。 如果你的团队成员对改进不感兴趣,那是一个更大的问题。你还是应该试着把它作为一个整体来处理,但这很困难,你可能需要一些管理方面的帮助。
|
|
|
6
2
我相信你的名单相当完整。您可以为每个迭代添加“清晰和固定的范围”,这是我在实践中经常看到的问题——尽管有人可能会说这只是“小发布周期”的一部分。 另外,我会把“小的发布周期”和“重构”列为单独的点——它们是相当独立的。 无论如何,我不会过分担心敏捷的“缺失”部分。敏捷方法的一个重要特性是,它们不是全部,也不是什么都不是——你可以先从一个对你很有用的部分开始,然后逐步提高。有些实践确实相互依赖(例如重构和集体代码所有权),但大多数都可以独立使用。 |
|
|
7
2
还有一些想法需要补充,尽管有些想法可能是你在其他实践中隐含的: 记住,每一个都可以按照自己的方式定制,这是一个重要的方面,因为如果一个练习对你的情况没有帮助的话,那么太过虔诚地遵循它未必是件好事。
|
|
|
9
0
“敏捷”或“敏捷软件开发”不是单一的方法。这是一个总括性的术语,涵盖了你可能选择持有的一系列“价值观”。两种不同的方法都可以是“敏捷”的,但是当涉及到你应该或者不应该做的实践时,它们会相互冲突。 “敏捷”没有一个明确的定义,所以不可能列出一个明确的“敏捷实践”清单。 有 a definitive list of the basic Extreme Programming Practices 也有一些你必须做的事情去做Scrum(尽管那不是很有用,因为它 完全没有提到具体的工程实践 .) |
推荐文章
|
|
Andy · 如何记录Scrum/敏捷/TDD过程中未定义的行为[已关闭] 10 年前 |