敏捷开发文库-落地敏捷典型问题(六):沟通、技术决策和评审

  • 格式:pdf
  • 大小:126.72 KB
  • 文档页数:2

落地敏捷典型问题(六):沟通、技术决策和评审
在敏捷实践中,经常会遇到如下的问题:
1)敏捷需要客户的高度参与,但是即便PO也很难有机会和客户经常沟通
2)在做技术决策时,怎么降低个人的影响力?
3)怎么提高评审效率、避免评审流于形式?一个评审涉及不同部门的很多人,组织评审的
成本高,收效低,评审的人对评审不直接负有责任、有很多优先级更高的事情要忙,会议评审可以姗姗来迟,邮件评审可以不吭声。

以下是我们推荐的一些做法:
对于#1:
①组建PO组,由PO、架构师、资深测试(如果没有资深测试,由SM代替)组成
②按照系统级-架构级-开发级等三级需求的方式和客户沟通需求,保证在有限的沟通机
会中获得最有价值的部分,具体方式参考
/con/3511281768693712
③在有限的和客户沟通之前,对所有的问题会事先给出1~3个建议,这样可以保证客户
对问题有明确的回复,而不至于客户说“哦,我还没有想好,等下次吧”。

对于#2:
①经验最丰富的最后发言
②关键的或者有争议的模块,可以用计划扑克的方式
③尽量不要让不参与编码和测试的行政领导参与评估
④特别对于架构的决策,由评审做第一步,由测试做第二步。

架构师的工作结束标准不是
设计文档,而是由非功能性测试等各种测试报告来决定,而测试工作往往在开发最开始效果最好
对于#3:
①减少评审的数量,集中几个关键评审即可,多了就疲了。

②增加评审人员对评审的责任。

我们的一个做法是把公共的信息作为平台来开发,评审人
员对平台的设计和质量负责,而开发团队直接用这个平台作为产品的一部分。

评审只有和最终的交付绑定,评审才会有意义
③下放评审的权力。

不是所有的项目都需要评审委员会来决定,一些非核心项目由项目组
评审即可
④增加评审的透明,利用专家的时间碎片。

有一个评审会议的平台,规定一个评审周期,
把关键的项目信息放在平台上供评审,确定项目的接口人,每一个评审人员可以在规定的评审周期内提出自己的意见,也可以在平台上进行讨论。

这样可以利用专家的时间碎片。

最后再有一个正式的评审会议,确定结果。

⑤有高层的督导会更有帮助,不过难以强求。