在对开发过程实施严格治理的公司中使用Scrum?[关闭]

我曾为一家公司工作,在SOX疯狂的边缘徘徊,同时仍然保持着一个相当敏捷的开发过程。有知识渊博的管理人员愿意在文书工作中工作,这帮了很多忙。我们做了几件事来说服SOX审计员,我们的电子流程不仅是替代品,而且比他们的书面工作要好。

• 我们使用ssh的一个特殊功能锁定了对代码存储库的访问,这样只有管理员才能访问原始文件。这就阻止了任何开发人员进行任何简单的、摇摇欲坠的存储库操作来隐藏更改。虽然我们不担心这种情况发生,但这让SOX审计人员感到高兴,他们接受版本控制系统作为一个安全的变更日志,而不是让我们在纸上提交(不是开玩笑)差异。

• 我们把大部分的文书工作委托给了质量保证部门,这些部门过去常常手工完成重复性的任务。:)

• 我们的在线任务管理器的安全性得到了提高。每一个变更都必须有一个与之相关联的任务。只有少数经理在系统中“签字”之后,才能处理任务管理器中的任务。实际上,这意味着我是一个经理,在网络表单中打勾。

• 我们将权力从准备阶段转移到生产部门,并将其推送到质量保证部门。同样,在实践中,这意味着告诉QA中的某人运行脚本。作为副作用,它有助于使我们的生产推动过程更快、更简单。

• 通过使用开发、分段和生产分支机构,我们可以自由地在开发和分段分支机构上工作,因为它们没有访问生产数据库的权限,只需要为实现生产的变更准备好所有的文书工作。

值得注意的是,尽管我们在工作桌下做了一些事情来完成我们的工作,但在大多数情况下,我们让负责SOX合规性的人知道它对完成工作有多大的影响,并与他们合作以平衡他们的SOX偏执和我们的效率。我们发现了他们真正想要的,并提供了更有效的替代方案(比如安全版本控制而不是纸面差异)。我们不是在一个破碎的系统周围工作,也不是在开发人员和QA之间创建一个战场,而是在改进系统。

在那个环境中,我通过更加隐蔽地做一些事情,在项目中取得了成功。在我管理的项目中,在这样的环境中,我通常会设法让实习生全职工作。实习生的工作是填写所有美丽的文件和垃圾,给人一种假象,我们遵循一个过程,而在背景中,我的开发人员继续工作,继续推进项目。在内部,我使用了一种严格的基于Scrum的方法。我的项目以100%的成功率结束,而成功项目的公司平均水平在20-30%左右。

用我那一团糟的意见自担风险。

至于SOX合规性BS,他们还没有扔掉吗?

我不明白为什么您认为文档和正式的流程不能很好地与敏捷配合。

如果您知道如何正确地执行RUP,那么对您来说更容易执行Scrum,因为您已经有了足够的纪律,可以在不成为牛仔的情况下保持敏捷。

没有人说你做Scrum时不能做适当的文档。这些文件 做 增加一些价值——当你遵循敏捷的过程时,它们并不是完全必要的,所以大多数团队都不会这样做。

如果您认为文档是您的可交付成果,那么就将它们添加到迭代范围中,为它们编写重要的东西,以便它们对您的团队有用——它们是一种开销,但是它们也有价值,特别是在长期项目中,或者当您有一个大型和/或分布式团队时。

RUP迭代不强制使用瀑布模型——它们只是强调其中某些规程的指导方针,但是RUP中适当的迭代将所有的活动混合在一起。例如,考虑到精化阶段是一个有一些尖峰的正常敏捷阶段,您将无法分辨出不同之处。

它为我们处理这些文档的方式是使用wiki获取类似这样的信息,并将其内容导出到Word文件中,这些文件稍后可能会被注销。

这些文档可以通过审查,但不必维护,团队可以访问wiki获取信息。