我们的敏捷计划标准是什么？

Question

我们一直在尝试Scrum,但现在正试图将其正式化为我们自己的敏捷应用程序开发版本.以下是我们当前流程的工作原理.它现在有两个主要缺点.想要了解你是否有类似的方法,以及社区是否有任何关于我们目前遇到的障碍的实用技巧.

• Scrum团队= 4名开发人员,2名QA,1名技术作家,1名PO(PM),1名Scrum Master(Engg Dir)
• 发布= 3 Sprint
• 冲刺= 2周

PO和客户创建产品积压的用户故事和相关的验收标准.
在每次迭代开始时进行1周的Sprint计划

• 第1天#估计Sprint积压并同意优先权
• 第2-5天#Scrum团队在Sprint积压中讨论故事并处理每个故事的细节(获取故事的详细信息,流程流(如果有),确定要应用的UE准则,UI项目/字段/小部件的详细信息及其如果需要任何特定的行为,了解验收标准并创建测试)
• 2周冲刺,每天15分钟的scrum
• 重复3周循环

我们在这方面遇到的两个主要缺点是:

1. 春季计划周中讨论的细节无法有效捕获并在维基上注明.由于在Scrum中没有用于捕获此类详细信息的标准格式,因此通常会在每日Scrum中浪费时间,或者需要后续会议来进一步了解故事详细信息.什么是在sprint计划中捕获功能相当复杂的产品的故事细节的最佳方法？大多数问题似乎是围绕用户界面和开发人员无法决定如何在没有详细模拟的情况下布置屏幕/字段.
2. 当团队处于冲刺周期时,您如何预测从客户那里回来的关键showstopper错误.目前,开发人员不得不被用于支持这些红色帐户问题,从而破坏冲刺.

关于我们如何改进这一点的任何意见？

Answer 1

1. 没有"标准"敏捷计划.计划并不重要..计划是.我的意思是定期调整您的计划以反映现实情况.制定计划,让它受到权力的祝福,然后捆绑开发人员一直没有传统的工作.
2. 如果我没有弄错的话,Sprint计划不应该超过一天.scrum的一个关键想法是你不会花太多时间计划.如果他们这样做,当你有更好的清晰度时停下来并重新召开.不要跋涉.
   • 从客户那里获得优先的故事集~3小时
   • 开发人员蜷缩在一起估计~3小时
   • 显示估算值并让客户更改其存储桶以反映业务需求(在sprint配额内)~rem time.

记录决定:

• 得到一个好的抄写员？能够像4人一样快速打字的人说话......在图表......或维基等高可见性区域内获取核心陈述/决定......对你有用的东西

UX研究:

• 尝试管道UX工作.确保UX人员在开发人员到达时已经使用过UI细节,模拟屏幕,工作流程等.当开发人员正在进行迭代时,UX正在处理Iteration n + 1的故事.有点困难,但如果用户体验会给你带来很多"颠簸",那就可以做到.

错误 - 职务:

• 一种方法是将所有错误作为下一次迭代的常规积压项目.在sprint计划期间获取客户支持哪些人需要进入.
• 如果这不可行,趋势错误流入,修复率和计划.保留x天标记为专用于这些请求的按需定制开发人员.

改进范围: 您需要一名专职人员担任"客户"角色(或可以为客户提供服务的教练/ BA),开发人员可以实时联系.每日Scrum会议的时间应为30分钟,不应包括故事"澄清".坚持3个问题 - 你昨天做了什么？今天你在做什么？您需要帮助的任何障碍？
负责特定故事的开发人员或子团队应该与客户/前线合作,以防他们在处理特定任务时遇到疑问.作为开发工作的一部分,他们负责提取细节.如果有帮助,他们也可以向在相关领域工作过的其他开发者寻求帮助.与客户一起努力,保持正确的轨道.
HTH