每日Scrum会议是敏捷团队的常见会议。 但是我仍然发现,一些产品经理和所有者不确定是否以及何时参加。 这篇文章分享了有关是否,多长时间以及如何参加“每日Scrum”的建议。
提示1:了解全部内容
每日Scrum会议(有时也称为站立会议)希望帮助开发团队管理其工作。 在Scrum中,团队共同同意一个冲刺目标并负责实现该目标 。 这包括每天跟踪工作进度并讨论可能需要的任何更改。 Daily Scrum通过鼓励团队成员谈论以下内容来支持自组织:
- 团队成员取得的进展;
- 人们接下来打算做什么?
- 如果有人需要帮助-如果有任何障碍或阻碍。
Daily Scrum是一次快速的会议,持续时间不超过15分钟。 每天应在同一地点和时间举行; 我发现最好在早上举行会议。
提示2:您应该参加吗?
作为产品负责人,您应该每周至少参加两次“每日Scrum”。 [1]这使您可以了解当前sprint中正在发生的事情,以及是否以及如何可以提供帮助。 例如,您可能会发现一些用户案例已完成并且可以进行审查; 否则您可能会发现团队正在努力接受某些接受标准,需要您的投入。 另外,例如,您可能想请团队帮助完善产品积压项目或更新产品路线图 。 [2]
请注意,会议并非旨在解决任何问题。 因此,请勿将其变成产品积压或路线图研讨会。 例如,如果您听说团队成员对验收标准有疑问,请在会议后回答。 同样,如果您需要团队的帮助来制定产品路线图,请举行单独的研讨会。
此外,别忘了平衡您的各种职责 。 这些不仅包括与开发团队合作,还包括与用户和客户会面,以及与利益相关者互动 。 如果您虔诚地参加Daily Scrum,请检查余额是否仍然正确。
提示3:请勿干涉
认识到会议不适合您,但适合开发团队。 避免干扰团队的自我组织; 不要分配任务或批评个人。 如果您担心冲刺的进度,请诚实但富有建设性地说出来。 不要告诉团队该怎么做。 由团队成员来管理sprint和实现sprint目标,由您来管理产品和整个发行版(由几个sprint组成)。
如果您发现团队成员看着您并告诉您他们做了什么,您就会知道出了点问题:人们向您报告项目状态,而不是负责他们的工作。 因此,与团队分享您所看到的情况,并要求其他人不要对您讲话,而是要彼此讲话。 或者,停止参加会议,直到您在下一个sprint回顾中讨论了应该就流程改进达成一致的问题为止(请参阅下文)。
同样,如果您很难不建议下一步该做什么或该做什么,那么请停止参加会议,以使团队有必要的自主权进行自我组织并完全控制他们的工作。 您还应该调查为什么难以放手并信任团队做得好的事情:您是否渴望实现雄心勃勃的产品目标? 您是否怀疑团队达到冲刺目标的能力? 而您能做些什么来让自己更放松呢?
提示4:让ScrumMaster做好工作
知道确保每日Scrum发生并确保其有效是ScrumMaster的工作 。 但是,如果您觉得出了点问题,团队成员的工作跟踪不佳,人们没有参加会议或迟到,或者每日Scrum经常超载,那么请与您讨论问题开发团队和ScrumMaster在下一个sprint回顾中。 但是不要承担ScrumMaster的职责。
请记住,您的工作是管理产品,而不是团队或过程。 如果您没有ScrumMaster,或者没有个人或没有资格,则可以通过雇用合格的ScrumMaster或帮助现有的ScrumMaster来解决这是实现需要解决的产品成功的障碍。
笔记
[1]如果您负责较大的产品,并与其他产品人员(例如功能部件或组件所有者)一起工作,则通常不会参加Daily Scrums。 而是参加Scrum of Scrums(SoS)会议,这是Daily Scrum的一种变体,通常用于促进多团队开发工作。 我喜欢与团队的每日Scrums之后立即举行的每日SoS会议一起工作,每个开发团队的代表都参与其中。
[2]请注意,此建议与2017版《 Scrum指南》不符。 多年来,会议的定义已更改。 最初,这是一次公开会议,但只允许开发团队成员和ScrumMaster进行交谈(请参阅使用Scrum进行敏捷软件开发 )。 在《 使用Scrum进行敏捷项目管理 》一书中,会议被更改为允许产品所有者做出贡献(请参阅第135和141页)。 无论当前的正式定义是什么,成功的Daily Scrum的关键在于让开发团队完全控制sprint中的工作。
翻译自: https://www.javacodegeeks.com/2017/06/4-daily-scrum-tips-product-owners-product-managers.html