敏捷转型之采用scrum
如今,敏捷就像一种时尚。 它是流行语之一,很酷……我想实际上是。 随着流行,还伴随着谣言,神话和误解,这些通常会在敏捷项目中引起问题,并归咎于流程本身。
有许多团队声称使用敏捷甚至不知道宣言 。
是的,这并不是所有软件开发问题的答案,一个尺寸不能完全解决所有问题,但是在您将其应用到项目中或责备其无法正常工作之前,请阅读此书,如果您有任何反馈意见,请随时提出评论!
如果您考虑敏捷,请考虑以下因素:
1.项目规模
在一个相对较小的项目(数十万美元),具有传统的客户端-服务器体系结构和明确定义的用户/客户的新项目中应用敏捷很容易,但是...用一个新的现有大型项目(数百或数百万美元)来重写分布式软件和多个利益相关者? 在敏捷方法论中很难解决这个问题……请查看本文以获取更多信息。
2.客户或产品所有者必须敏捷
如果您的客户真正想要的只是在固定时间内具有固定数量功能的产品,那么您很可能会失败。 无论如何,即使您不使用敏捷,您也是。 但是我想敏捷性并没有帮助。 在敏捷中,您必须不断地重新定义需求,重新制定需求,重新确定需求的优先级。 您的客户必须知道并接受。
3.您的组织必须敏捷
如果您的公司仍然要求所有工作都按照预先的规范进行签名,那么基于迭代的模型就毫无意义。 为了获得正确的价值,您需要能够适应正在进行的工作。
4.您的团队可能尚未准备好
是的,没错,团队可能不够成熟,无法自我管理,这是敏捷宣言中的要点之一。 您需要意识到是否要开始敏捷并相应地领导。 ( 这里的文章很好)。 您可能需要坚持并训练/领导您的团队(和您自己)多一些时间。 敏捷方法需要心态转变。 简单的事情,例如说某事“完成”意味着已经准备好生产。 这并不意味着代码已经完成,现在其他人将不得不确保它可以工作。 您的团队需要足够成熟才能拥有并了解他们的承诺。
5.敏捷并不意味着您将更快地开发软件
所有项目经理都必须清楚这一点。 它提高了业务价值和投资回报率,因为使用敏捷团队专注于按业务价值划分优先级的功能,并按固定的时间间隔递增地交付工作软件。 更少的功能=>更快。 如果仅考虑总时间,由于持续不断的代码重构,敏捷将需要更长的时间。
6.不要仅仅为了它而做
仅在相信敏捷的情况下拥抱敏捷。 不是因为人们说它有效。 甚至更糟糕的是仅仅告诉您的客户您是一家“敏捷”公司。 有很多成功的公司从未使用过它。
如果您已经在使用敏捷,则:
1.确保您有一个清晰且普遍接受的DONE定义
整个团队需要了解流程。 确保他们知道,理解并接受。 您的Sprint工件必须已准备好投入生产。 还请记住,如果您的sprint结果并未实际部署到生产中(无论出于何种原因),您就在收缩合同。 仅考虑到“生产”错误可能隐藏在您的代码中。
2.注意技术债务
通常,由于这种情况,技术债务往往会在冲刺中累积。 您需要在sprint期间密切监视它并分配时间以略过它。
3.不要让团队成员担任产品负责人
产品负责人是最重要的参与者。 是告诉您要执行的操作,但最重要的是首先要执行的操作。 正确选择用户故事的优先级将决定项目的成功或失败,只有所有者才可以这样做。 有时候,如果您的团队很大,您可能会想让团队中的某个人(很可能是BA)戴上产品负责人的帽子。
这会导致很多问题和误解。 敏捷宣言的关键点之一是“基于合同谈判的客户协作”。
4.您的团队可能会多元化。
并非每个团队成员都能讲完每个故事。 有人说敏捷对初级开发人员不友好。 不仅如此。 您可能有不同的专业领域的不同人员,这会产生很多您需要处理的争用/依赖关系。
5.花适当的时间进行自动化和持续集成
敏捷过程的一部分是不断构建和集成软件。 开发人员应整天运行测试。 如果您的构建需要30分钟,那么您的应用服务器又需要5分钟,依此类推,那么您的生产力确实会受到影响。 花一些时间将应用程序分解成更小的可维护性。 不要拖延原因和团队的生产力,否则就会养成不运行或跳过程序的坏习惯。
6.追求“尽可能简单”,但不要忘记设计原则
这里的想法是尽快获得反馈。 因此,如果您的应用程序将要生成图形,那么拥有基于excel的第一个版本就可以确保您了解客户的需求是没有错的。 您需要注意的是,不会遗漏软件体系结构和设计原则!
7.不要忘记非功能性要求
用户故事只谈论必需的功能。 完全没有关键的“良好”属性。 您的利益相关者无论如何都会期望他们,那就是当您遇到麻烦时。 如今,诸如性能,可伸缩性之类的所有东西都在发挥作用。 检查为什么Chrome变得越来越流行 。
参考: 为用户和新的采用敏捷软件开发的建议 ,从我们的合作伙伴JCG的博客正在发展 。
相关文章:
翻译自: https://www.javacodegeeks.com/2011/03/agile-software-development.html
敏捷转型之采用scrum