什么模型将选择软件项目？

#1.Scrum可用于任何规模的项目,但在某些方面存在一些开销,这对于<200小时项目可能对您没有价值.对于那个小项目,我可能会建议你看看更精简的东西,比如看板.

#2.如果您正在寻找Kanban/Scrum工作板来管理积压的故事,可以在线免费获得以下几种工具:

Trello:https://trello.com

AgileZen:http://www.agilezen.com/

Scrumy:http://scrumy.com/

看板:http://kanbanize.com/

许多其他人......只是谷歌,你会看到有一个巨大的列表.

如果你决定采用Trello路线,我有一些资源用于敏捷任务跟踪和Scrum:

使用Trello进行免费敏捷任务跟踪:http://theagilecoder.wordpress.com/2013/03/23/free-agile-task-tracking-with-trello/

使用Trello for Scrum:http://theagilecoder.wordpress.com/2013/06/08/using-trello-for-scrum/

如何设置Trello Board for Scrum:http://theagilecoder.wordpress.com/2013/11/11/how-to-set-up-trello-board-for-scrum/

#3.关于sprint的"大小",在你完成一些冲刺之前,你不会知道你的团队在sprint中可以做多少故事点.这是标准的.您的团队需要彼此建立历史记录,以便您可以根据历史绩效开始确定速度.关于长度,鉴于你现在正在转向敏捷,我可能会推荐一个为期3周的节奏.2周也很好,但是当团队第一次学习敏捷并且花费大量时间学习新流程时可能会很困难.

这里最好的办法是使用sprint回顾来评估哪些是有效的,哪些是无效的,并进行调整.如果冲刺中有太多,请少花点时间.如果冲刺太短/太长,请调整冲刺持续时间.话虽这么说,如果你确实波动了冲刺持续时间,你将很难评估你的速度,因为你没有类似的可比性.

在"定义"冲刺方面,我认为你的意思是做冲刺计划.我真的建议你看一下网上的一些资源,用于sprint计划会议.像ScrumMethodology这样的网站有各种各样的工具,但如果您只是谷歌"Sprint计划会议",您会发现许多资源需要阅读.

通常,确保您的待办事项已准备好并确定优先顺序,然后您可以开始与团队合作,找出接下来要解决的问题以及完成故事需要完成的任务.

#4.我将按照Scrum上的Wiki条目为您找到定义.简而言之,将其视为您所知道的所有工作的清单.您将需要负责此积压工作的人(产品负责人),他们将确保已创建所有需要完成的工作.

如果您在一家规模较大的产品公司工作,那么您的开发团队看到的产品待办事项可能只是当前的发布积压,而产品管理团队负责管理多个版本的长期产品积压.

#5.再次,我将遵循Scrum上的Wiki条目,以便您找到定义.Sprint计划是一个允许您将团队聚集在一起并确定他们将在下一个sprint中做什么的事件.它不是产品Backlog的一部分.它允许您评估积压中的内容,然后确定从积压中获取的内容并将其放入Sprint积压中.

在本次会议中提出了一些重要问题:

积压的物品有多大？(估计)

我们愿意接下来要处理多少积压？(确定sprint积压)

我们如何完成这些故事？(任务计划)

#6.这似乎不是一个问题,但我认为你正处于Sprint Backlog的正确轨道上.

#7.在你的Daily Scrum中,确保人们只是提供他们刚刚做了什么以及他们将要做什么的更新.保持讨论简短,如果出现需要进一步讨论的事情,请为需要参与的人安排.这只是一个接触点,以便团队中的每个人都知道其他人正在做什么,并让团队有机会提出问题(障碍).当你离开时,你可能会调整你运行scrum的方式以适应你的团队,但要保持简短(大约15到20分钟).

另外,我强烈建议让Scrum master运行大部分Scrum事件.这些人应该比敏捷过程中的其他团队有经验(或至少更有经验),并且可以指导和指导团队提高效率.如果您的团队中没有人可以回答上述问题,我强烈建议您考虑找到这样的人加入您的团队并帮助您完成过渡.

当你没有人领导时,很容易在转换到新流程时失败!