扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
10年积累的成都网站建设、网站建设经验,可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你,你也不认识我。但先网站设计制作后付款的网站建设流程,更有仪陇免费网站建设让你可以放心的选择与我们合作。
1.Story的确定
在敏捷开发团队中,产品负责人需要将用户故事放在队列中。这个队列叫做产品订单,由产品负责人负责。
产品负责人决定将什么放进去,什么拿出来。产品负责人还会决定顺序——什么东西需要现在构建,什么可以放在后面进行?这个工作不好做,需要与团队和利益相关者协作完成。
2。一个Sprint中完成的Story的确定
产品负责人需要与团队协作来管理产品订单。
因为资源的限制,有些问题我们一直需要讨论——Story的价值、大小、优先级、划分——所有这些通常叫做“订单梳理”。产品负责人要根据情况梳理订单,并不定期召开订单梳理会,理论上整个团队都会参加,有时一些利益相关者,横向经理人员,决策者也会参加。会议议程会不断变化,有时关注点放在估算上,有时放在故事的划分上,有时还会为讨论验收标准。
产品负责人知道应该构建什么,并向Scrum团队表明这一点。团队会与产品负责人通力协作来确定在一个Sprint中应该开发多少内容。
对于软件产品的开发来说,每个Scrum角色都会有自己的关注点:
各个Scrum角色之间应该保持健康的关系。产品负责人应该关注本次迭代应该完成哪些正确的东西。而团队关注如何快速和正确地构建这些东西。Scrum Master关注效率,包括进度和沟通,并且最大程度上维护敏捷的基本制度。
开发团队除了能按时完成任务外,还要保证开发可持续性。意思是,如果团队积累了所谓的技术债务(比如框架不合理,没有编写测试,没有可持续改进的架构设计),那么团队的开发速度将会随着时间的推移变得越来越慢,这使得后面的预测变得几乎不可能。因此,考虑到团队要负责保持可持续的节奏,产品负责人要注意,不应该对其施加压力导致其走捷径,这种现象经常存在,尤其是团队开发者缺乏强大开发经验的时候。所以信任和鼓励是非常重要的。产品负责人应该唾沫横飞,意气风发,手舞足蹈地,像一个专业的骗子一样向团队灌输他的产品Story,让团队像打了鸡血一样自愿去战斗,而不是唉声叹气,歇斯底里地传送压力。
产品负责人应该避免这么说“我们还有剩下4个Sprint,因此你们必须在这个Sprint中完成1/4的产品订单,否则后面会。。。”。产品负责人的工作是通过清晰、鼓舞人心的目标来激励团队。团队成员最清楚他们自身的开发能力,因此在任何一个迭代中,他们都会从产品订单中选择可以交付的用户故事,产品经理尽量避免讨论这个工作,如果真的有需要,可以借助于 Scrum Master。
3。产品负责人在敏捷组间的协调
大型项目会有多个团队同时工作,当然也会拥有一个以上的产品负责人。所以产品负责人本身之间的协作是非常必要的。
在多团队的情况下,产品负责人还有一个额外的重要职责——团队之间彼此交流!没错,我们当然应该让团队之间的Story只有最小化的依赖或者没有依赖。但事实上总还是会有一些依赖,无论是产品逻辑还是技术实现方面!因此,产品负责人之间应该进行某种同步,这样才能按照顺序构建,避免局部优化而影响整体效率。
产品负责人是一个至关重要的角色,通常需要全职参与才行,一个产品负责人可以兼任一个或者两个敏捷团队,但不能够两个或者以上的产品负责人在一个敏捷团队里面。
4。需求变更
关于需求变更,产品负责人还会与团队就如何管理需求变更这一问题达成一致。
作为理论而言,Scrum团队会承诺完成从产品订单中所选择的用户故事,作为对等要求,产品负责人要承诺不在Sprint中抛出新的需求。
需求可以变更(需求变更是Scrum存在的目的,也是受鼓励的),但只能在Sprint之外变更。
然而,只要有实际敏捷开发工作经验的产品负责人都会觉得,这有时候的确是个难题,尤其是面对业务方的时候。有一个比较好的方法可以大部分解决这个尴尬的问题,在一开始组建团队和设立迭代周期的时候,不要把迭代周期设定的太长。产品经理可以了解业务方的规律,建议敏捷团队设定一个比较断而合理的迭代周期,比如二周,甚至一周。
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流