敏捷最佳实践列表

Question

我正在尝试定义我们将要使用的敏捷实践,并且我很难定义敏捷最佳实践列表.我希望我的列表更多地从技术角度(工程师的角度来看),并且应该定义SW工程师应该如何处理开发.该清单应尽可能与管理层相关.

如果重要,我们用c ++编程.

找到很多最佳实践相当容易,这是我到目前为止所形成的列表:

1. 重构
2. 发布周期小
3. 编码标准
4. 集体所有权
5. 系统隐喻
6. 刨游戏
7. 整队
8. Scrum每日会议
9. 结对编程
10. 测试驱动设计
11. 行为驱动的发展
12. 持续集成
13. 代码和设计评论
14. 活跃的利益相
15. 文件迟到了
16. 广泛使用设计模式

我们已经在使用列表中的一些实践.有些我们不打算用.

是否有可以添加到列表中的良好敏捷实践？

PS我可以根据要求添加一些小的实践描述.

编辑

正如我所说,我们已经在使用一些敏捷实践(主要是被证明是最好的实践):

1. 持续集成 - 这是非常好的做法.获得有关最新签到的快速反馈非常有用.因为有人打破了构建而导致停工时间非常令人沮丧,特别是如果它持续时间更长.
2. 系统隐喻 - 它几乎没有帮助,因为具有描述性的类和函数名称有助于更好地理解代码
3. 代码标准 - 我们在进入编码之前创建了编码标准.使用统一的代码样式是很好的,因为任何人都可以使用另一个代码并像它自己一样处理它.
4. TDD - 在开始编码之前,我们设置环境以便轻松创建单元测试,但直到最近我们才开始采用TDD原则.几年前我亲自尝试过它,并没有那么顺利,但现在我喜欢它.不幸的是,并非所有团队成员都这样做 - 只有半个团队.
5. Scrum每日会议 - 我们每天都在尝试会议,但是他们并没有那么顺利.除了我以前的工作,每天的会议通常会变成30多分钟的讨论.我想我们错过了好的scrum大师(或者领导者,怎么称呼？)
6. 重构 - 我们进行了重构,但仅限于团队中的某个人创建了更改请求.我们并没有故意这样做:"让我们坐下来,减少我们的技术债务".
7. 小的发布周期 - 现在我们有很大的发布周期(6个月),而对于下一个版本,我们正计划将周期分解为4-6个内部版本.
8. 代码和设计评审 - 我们进行了初步的设计评审(如5年前),并且在此期间很少有设计评论一些次要子组件.我们对某些课程进行了代码审查
9. 文件迟到 - 我们为此版本做了.只需要的文档就意味着编写文档的编码越来越少.开发人员喜欢它:)
10. 使用设计模式 - 我们已经在适当的地方使用了设计模式.

由于我们组织的结构,我们不能使用其他做法,但正如您所看到的那样,列表很长,而且您无法选择所有内容.此外,现在我们只有4个软件开发人员,每个开发人员维护大约80千万卢比并开发新东西.因此,我们不能做例如结对编程或集体所有权.

Answer 1

首先,阅读敏捷软件的十二原则.

其次,从你所知道的如何实现对你最重要的原则中找出答案.

人们经常犯错误,希望敏捷开发成为一个Silver Bullet或一套严格的流程,您需要遵守这些流程才能使您的软件开发成功.

这不是它的意思.您已经拥有15个"最佳实践"列表这一事实让我感到有些害怕.不要太认真,不要过度思考.如果你发现你错过了什么......在下一次迭代中得到它.

Answer 2

本文总结了所有敏捷最佳实践(包含链接):
要求
- 产品愿景/愿景声明
- 产品积压
- 用户故事
- 用例
- 使用场景
- 角色
- 规划扑克
需求优先级
设计
- 建筑尖峰/尖峰解决方案
- 领域驱动设计
-紧急设计/进化设计
- CRC卡
- 按合同设计
- 系统隐喻
构造
- 编码样式/编码指南/编码标准
- 测试驱动开发
- 行为驱动开发
- 对编程/配对
- 重构
- 集体代码所有权
- 每日构建/自动化构建/十分钟构建
- 持续集成
- 代码评审/同行评审
- 软件指标/代码度量和分析
- 源代码控制/版本控制
- 问题跟踪/错误跟踪
- 配置管理
- 频繁交付/频繁发布
测试 - 单元测试
- Smoke测试/构建验证测试
- 集成测试
- 系统测试
- 探索性测试
- T. est Automation
- 故事测试/验收标准/验收测试
过程
- 时间盒/固定冲刺/固定迭代长度
- 发布计划
- 迭代计划/规划游戏/ Sprint计划
- Sprint积压
- 任务板
- 完成/完成的定义
- 每日站立会议/每日Scrum
- 速度
- 冲刺回顾/迭代演示
- 价值流图
- 根本原因分析/ 5为什么
- 烧毁图表/烧毁图表
- 大看见图表/信息散热器
- 回顾/反思研讨会
组织
- 小团队
- 交叉 -功能团队
- 自组织团队/ Scrum团队
- 共同团队/坐在一起/共同工作区
- 现场客户/产品负责人
- Scrum Master
- 可持续发展的步伐
- 让人们
四处奔走 - Scrum Scrum

Answer 3

我现在正在阅读"成功与敏捷".在第2章中,Mike Cohn对建立任何类型的"最佳实践"提出了可怕的警告:

"当转换到Scrum时...收集最佳实践是危险的.就像警报器从岩石中向我们唱歌一样,最佳实践诱使我们放松并停止对Scrum必不可少的持续改进的努力......虽然团队成员应该总是看为了分享他们新发现的良好工作方式,他们应该抵制将它们编成一套最佳实践的冲动......"

他继续引用丰田的Taiichi Ohno:

"...有一种称为标准作品的东西,但标准应该不断改变.相反,如果你认为标准是'你能做到的最好',那就完全...... [如果我们确定了最好的东西]可能的方式,改善[持续增量改善]的动机将会消失."

归因:成功应用敏捷:软件开发使用Scrum,Mike Cohn,2010