一个工具还是一套工具更适合Scrum?

Rob*_*lls 2 collaboration scrum

天儿真好,

编辑:我们已经在几个不同规模的项目上成功使用Scrum了好几年.事实上,我们的团队使用经典的Scrum方法为BBC开发了成功的iPlayer项目.

在使用各种工具组合(一些高科技,一些低技术)之后,我们现在希望尝试采用合适的工具套件.我们的经理在某种程度上试图强制采用Scrum的单一工具套件.

我看过SO问题" 最好的Scrum工具 ",大多数人似乎都建议:

  1. 一套低技术解决方案,例如白板,贴后卡,索引卡等,或
  2. 一个单一的工具,试图尽可能地满足过程,例如Agilo,Mingle,ScrumWorks,Target Process等.

我们的团队目前正在评估几种不同的Scrum工具.但是,我们正在考虑选择单一的整体工具,例如Agilo.

所有"一站式"解决方案都有其优点和缺点,严肃的企业类型解决方案是最佳选择.但都有一些缺点.

在SmartBear上阅读了" Peer Code Review:An Agile Process "之后,我开始想知道我们是否试图在"最适合"的基础上强制采用工具.

我想你可以参考一些Scrum开发过程的参考文献

  1. 用户故事,史诗和主题,以及
  2. 代码库必须使用众所周知的SCM,例如SVN,Hg等.

然后,如果我们将其作为所用工具的公共参考点,那么我们将能够使用一组工具来处理Scrum过程的不同方面,而不是尝试强制使用单个工具,这有点像强制一个正方形的钉子插入圆孔.

通过这种方式,如果您已经同意了您的共同参考点,那么您可以使用多个工具,每个工具都比单个工具套件中的单个组件更好地执行其角色.

这是一种更明智的做法吗?

我上面提到的两个参考点是否合适,或者它们是工具满足的更好的选择点?

干杯,

Gis*_*shu 9

那敏捷的答案是"它取决于".尝试一些东西,如果它适合你的团队,坚持其他适应/改变.

说明:建议使用低技术工具,以促使人们脱离椅子,移动,交谈和参与团队的进步.但我个人的经验是,采用取决于团队成员的确切构成和态度.如果整个团队不喜欢移动/同意发布它,请不要继续使用它; 尝试别的.虽然我经常看到"卡住"的球队表现出这种阻力.你最终得到了一个多彩多姿的scrum board,只有scrum master才会关注它.

西装/管理层首选高科技工具,主要是因为他们可以按几个按钮并准备好报告.另一方面是大量/定期数据输入以保持同步.现在有了敏捷的项目管理工具,进展(或缺乏进展)更为明显(早期),因此我将在未来更多地打赌.如果您的管理层已经选择了"组织范围内的标准",那么您就会坚持下去.

目前我正在尝试使用共享电子表格,该电子表格包含此sprint的故事/任务列表以及计算的burndowns.如果有人想要查看它,则在scrums +放入网络共享期间将此工作表投影在墙上.SM在每日的scrums期间进行更新.