我们的敏捷计划是否标准？
我们尝试 Scrum 已经有一段时间了，并试图将其正式化为我们自己的敏捷应用程序开发版本。 以下是我们当前流程的运作方式。 目前它有两个主要缺点。 希望了解您是否有类似的方法，以及社区是否对我们当前遇到的障碍有任何实用的建议。
- Scrum 团队 = 4 名开发人员、2 名 QA、1 名技术作家、1 名 PO(PM)、1 名 Scrum Master（工程总监）
- 发布 = 3 个 Sprint
- 冲刺 = 2 周
PO 和客户创建用户故事的产品积压工作和相关验收标准。
每次迭代开始时进行 1 周的 Sprint 规划
- 第 1 天# 估计 Sprint 积压工作并就优先级达成一致
- 第 2-5 天# Scrum 团队讨论故事并处理 Sprint 积压工作中每个故事的细节（获取故事的详细信息，流程（如果有），确定要应用的 UE 指南、UI 项目/字段/小部件及其行为的详细信息（如果需要任何特定内容）、了解验收标准并创建测试）
- 2 周 Sprint，每日 15 分钟 scrum
- 重复 3 周周期
两个主要我们在这方面的缺点是：
- 春季计划周中讨论的细节没有被有效捕获并在维基百科上得到注释。 由于 Scrum 中没有捕获此类细节的标准格式，因此通常会在日常 Scrum 中浪费时间，或者需要随后的会议来进一步了解故事细节。 在冲刺计划中捕获功能相当复杂的产品的故事细节的最佳方法是什么？ 大多数问题似乎都与 UI 相关，并且开发人员无法在没有详细模拟的情况下决定如何布局屏幕/字段。
- 当团队处于冲刺周期时，您如何预测客户反馈的关键问题。 目前，开发人员必须抽身去支持这些突然出现的红色帐户问题，从而扰乱了冲刺。
关于我们如何改进这一点有什么意见吗？
We have been trying Scrum but for a while now and are trying to formalize it within as our own version of Agile Application Development. Here's how our current process works. There are two main drawbacks to it as it stands right now. Wanted to get input on whether you have a similar approach and if the community has any practical tips for the impediments we currently have.
- Scrum team = 4 Developers, 2 QA, 1 Tech Writer, 1 PO(PM), 1 Scrum Master (Engg Dir)
- Release = 3 Sprints
- Sprint = 2 weeks
PO and customers create product backlog of user stories and related acceptance criteria.
1 week Sprint planning at the start of each iteration
- Day 1# Estimate the Sprint backlog and agree on priority
- Day 2-5# Scrum team discuss stories and work on the details of each story in the Sprint backlog (get the details on the story, process flows if any, identify UE guidelines to apply, details for UI items/fields/widgets and their behavior if anything specific is required, understand acceptance criteria and create tests)
- 2 week Sprint with 15 min daily scrum
- Repeat 3 week cycle
The two major drawbacks we're having in this are:
- The details that are discussed in the spring planning week are not captured effectively and get noted on a wiki. Since there is no standard format for capturing such details in Scrum, often time is wasted in daily scrum or subsequent meetings are required to further understand story details. Whats the best way of capturing story details for a functionally fairly complex product in sprint planning? Most of the issues seem to be around UI and developers inability to decide how screens/fields should be laid out without detailed mocks.
- How do you anticipate critical showstopper bugs that come back from customers when team is in a sprint cycle. Currently the Dev folks have to be pulled away into supporting these Red Account issues that crop up thus disrupting the sprint.
Any inputs on how we can improve this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
记录决策：
用户体验研究：
Bug-Duty：
改进范围：
您需要一个专门负责“客户”角色的人员（或可以代表客户的教练/BA），开发人员可以与他们实时联系。 每日 scrum 会议的时间范围应控制在 30 分钟，并且不应包括故事“澄清”。 坚持三个问题 - 你昨天做了什么？ 今天你在做什么？ 您有什么障碍需要帮助吗？
负责特定故事的开发人员或子团队应与客户/前台合作，以防在处理特定任务时出现疑问。。 他们负责提取细节作为开发工作的一部分。 如果有帮助的话，他们可以向也在相关领域工作过的其他开发人员请求帮助。 与客户合作，保持在正确的轨道上。
华泰
Documenting decisions:
UX Study:
Bug-Duty:
Scope for improvement:
You need a dedicated person in the "customer" role (or coach/BA who can front for the customer) that the developers can get in touch with on a real-time basis. Daily scrum meetings should be timeboxed to 30 mins and shouldn't include story "clarifications". Stick to the 3 questions - What did you do yesterday? What are you doing today? Any obstacles you need help with?
The dev or sub-team in charge of a specific story should work with the Customer/Front in case of doubts while they are working on the specific task. They are responsible for extracting out the details as part of the development effort. They can request for help from other devs who have worked in related areas too if that helps. Work together with the customer to stay on the right track.
HTH
是的。 我注意到，在您的流程中，开发人员没有与实际的最终用户进行倾听/交谈。 这是失败的秘诀。 您不能期望您的“PO”能够捕捉实际用户表达的所有细微差别。
开发人员必须与最终用户交谈。 PO 也应该在那里，以记录发现的内容。 这是我在大多数开发项目中看到的最大问题，开发人员与用户的分离。
Yep. I noted that nowhere in your process were the developers listening / talking to the actual end users. This is a recipe for failure. You cannot expect your "PO" to catch all the nuances that the actual users will express.
Developers must talk to the end users. The PO should be there as well, to document what was discovered. This is the biggest problem I see in most development projects, separation of developers from users.
为什么你要召开为期一周的冲刺计划会议？ 冲刺计划的目标是获得足够的细节，让团队对可以完成的功能感到满意并致力于完成它们。 这通常需要不到一天（约 4 小时）。 实际的实现细节是开发人员在冲刺期间及时发现的。 这就是为什么他们有权访问采购订单和用户是如此重要。 如果你问在哪里捕捉细节，那么你在计划会议上就设计得太多了。 细节应该在冲刺期间直接写入代码中。
什么会是一场精彩的表演？ PO 在每个冲刺结束时（2 周）查看进度，然后决定业务价值是否足以保证发布。 如果存在任何关键问题，那么 PO 可能不会发布该 sprint。 希望您可以让您的 PO 甚至用户在功能完成后每天查看产品，从而减少冲刺结束时出现问题的可能性。
Why are you sprint planning meetings a week long? The goal of sprint planning is to get just enough detail to feel comfortable as a team with the features you can get done and commit to doing them. This usually takes less than a day (~4 hours). The actual implementation details are discovered just in time by the devs during the sprint. That is why it is so important that they have access to the PO and the users. If you are asking where to capture the details, then you are designing to much in the planning meeting. The details should go directly into code during the sprint as they are worked out.
What would be a showstopper? The PO sees the progress at the end of each sprint (2 weeks) and then decides if the business value is enough to warrant a release. If there were any critical issues then the PO would probably not release that sprint. Hopefully you can get your PO and maybe users to look at the product on a daily basis as features are completed and thus reduce the probability of issues at the end of a sprint.