Open zw334 opened 4 years ago
Q1：有一个矛盾点，开始讲产品需求的时候，基本都是很笼统，细节很少甚至基本没有，测试的时候，所有细节都有，所以现在的问题是：产品讲完了，技术去开发，按照原来的需求都搞好了，到测试的时候，开始产品需求没讲的，技术也没想到的，问题就都出现了。敏捷教练遇到这样的情况，如何处理？ A1：产品评审不够细致？只是产品讲其他人只是听？ A2：这种现象要分情况：1、产品真的想不了那么细致；2、产品压根就只想了解个大概；那么针对以上情况，我们团队在做的就是，第一步：产品原型出来，由技术负责先跟产品过一遍，提出问题，产品修改，然后在跟团队过。第二步：过完需求，开发开始编写技术方案，并进行技术方案评审，在评审的时候就可以倒推有些考虑的细节。第三步：测试编写测试方案，并且团队参与评审。通过这几步下来，基本上就没什么遗漏了。还有一种就是，如果Scrummaster不懂技术，那么在团队内部你可以挑选一个信的过的技术负责人，如果产品在过需求的时候，大家都很沉默，不提问题，那么很多问题都会遗留到测试时才会发现。 A3：测试不是由方案评审么，这就解决产品细节问题，另外要求开发做自测，这就解决开发对细节把握不当问题，落地开发自测，需要开发TL和项目经理还有测试一起形成共识，这是devOPS的基本观念。 A4：需求沟通应该不是一次性的呀，是个持续过程。 A5：需求过大需要拆，魔鬼都在细节里。 A6：满足DOD了吗？必须满足的业务有哪些？先保证必须满足的业务流程跑通，再限制其他异常问题，细节是持续性的，主题需求应该是一致性确定的，否则大家在一条自以为正确（最后发现是错误）的路上越走越远。 A7：产品经理不能讲很多细节的需求，我们之前是开发者写详细需求，很像测试用例，测试组会review，这样细节问题出得很少，但现在是粗的需求测试组会测出很多细节问题，很多都是开发者没想到的，关键在于前面是否给开发者时间去写详细需求。 Q2：我头一次觉得将SM的问题 ，提到这群里简直太正确了。。。感谢大家。 不一一谢过了。。大家思路都很棒，主意真正。有两个观点特别好：第一，细节是持续的涌现的。第二，开发，测试提前熟悉产品方案。这里面还有一个问题，就是需求颗粒度问题。产品经理讲需求是拿什么讲。PRD吗，流程图吗，还是原型？ A1：我们是拿原型 A2：最好是对着原型，如果大家能确保还原度的话，对着PRD也没意见 A3：所谓开发说的细节的点，其实原型能讲清楚。但是PRD或流程图未必，对着流程需要设计规范高度严格才可以。 A4：不是有影响地图吗？影响地图对于实现来说太抽象了。 Q3：有推荐的做法么？ 1、我们当初就是对着原型，大家澄清也是对着原型澄清，少很多事，产品做个大方向，有疑问的拉着相关开发先小范围聊聊，等梳理的时候听大家的看法。 2、嗯嗯，很细节的问题还是免不了沟通，尤其相关 UIUE、前后端开发、测试的沟通。 Q4：实践过程中，一个用户故事细节渐进明细，但只要现有的细节满足了用户的实际需求，价值得到体现是否也可行？ 1、影响地图出来个大的。然后再每个功能来切吧？这样主线业务就很清晰 2、实际的矛盾是开发不关心主线，产品想拉着主线却被开发拖进细节，于是产品就精分了 3、开发往往关注自己的地 4、实际上不是每个人都只关注自己的地吗？影响地图我觉得 还行吧，比较适合做产品，项目就算了。 Q5：从大到小，拆分下来不会脱离主线吧？ A1：会的，每个人都从自己的角度“优化”一点，流程就有问题这种事发生过。 Q6：这个问题是不是要由系统工程师去整体把控啊？ 1、严格来讲架构或者技术经理负责平衡，实际上方案太大的时候也很难盖住，而方案小了这角色又干脆没有。 2、嗯，确实有这个问题。 3、我渐渐的开始感觉到为啥做敏捷金字塔上面是文化，理念。。。实践还好推。但是思想的局限达不到能够顺畅推进敏捷需要的那种open 和 主动，很多实践推起来也会走样和鸡肋。 4、实践里很多时候产品兼非技术的架构工作，然后技术性架构需要决定的事也要依赖过来，产品就很头疼还有另一个极端，就是让技术架构兼产品，第二个我们自己栽过跟头，第一个可能是今天讨论遇到的场景的一部分 5、 open和主动/还是免不了沟通，感受到了吗？ 6、其实“沟通”这个词儿本身 也被大家曲解很多。想清楚-表达清楚-对方听清楚-确认一致。 7、是的，有些人觉得我跟你讲了=咱沟通了，对方一脸？？ 8、我说了，你听着，沟通常态…… 9、现在很多沟通变得也很鸡肋。产品很委屈，我一开始就给开发讲需求，但是那时候开发还没开始做功能，所以大家抱着很轻松的心态。实际吸收力没有那么好。产品清楚的记得自己讲过的细节。过程中开发忘记的有，开发没听到的有，开发自己理解也有。大家可能以为做在一起“ 面对面了 ”说了 ，有了沟通的过程了就OK ,没有几个人真的会去想沟通的效果，对沟通效果负责才是对团队协作有意义的，要不然就是无休息的聊。一个之前说过的功能，真正做时候就跟没讲过一样，还要聊半天，大家也可以想想，这样低效的沟通，还哪有时间去真正写代码。所以，我认同需求应该是涌现式的，但是不赞成没章法的沟通。 10、你讲完需求一定要让开发者整理出来，你再review一次，这样才能保证他们是否真正理解了没有。 11、很好。我们执行的类似，开发反讲嘛。不过这个要看时机。如果不是真正上手做，脑补不出具体问题的。 12、一般是写出来的时候才会进行思考的，沟通完了要落在文档里啊，以文档为准。 Q7：写代码的最讨厌写文档，众所周知。。。这个还真没尝试过。一条需求让开发要写什么文档呢？ 1、每次开会都有主题 结果。这些要记录下来啊。还有哪些是确认。开会前要先梳理好。才能高效。每次会议只解决一个问题。 2、prd应该让产品出啊 3、需求都是 项目经理或产品写。如果是比较复杂的。需要 开发那边写一个设计文档。评审过后 没问题就实现，后续测试可以拿着这两份文档去测试。 4、设计文档我一般不看的，开发自己约定好就是… 5、这样不行的。到时喷起来没证据 6、会和测试同学约定一些测试通过与否的约定…验收标准必须产品出，满足验收标准就算过 7、我觉得产品还是有必要参与 实现方式的讨论的。还是需要形成文档记录下来。虽然麻烦点，但是后期拼起来就是产品白皮书。 8、还是要定下来完成的定义和验收标准嘛… 9、不管是文档形式还是邮件形式，一定要写出来，以他为准 10、所以讨论的发起是产品，开发和测试现场反讲的结果整理到文档（可以是文字、录音、录屏……）并且上传到知识库上作为开发依据，需求验收的时候验证文档一致性。不一致看PO验收产品还是文档，验收文档改产品，验收产品改文档，两个都不对就是产品的问题了，先找到偏差小的统一过去，再补充需求条目修补偏差。 Q8：我在外企很多年从未听过反讲这个词，后来接触民企才知道这个词。根源还没搞明白 1、确认双方理解是否一致，反讲是一种很好的方式 2、我理解可能是中文博大精深，一个词语有多种解释方式，所以需要双方确认；英文相对比较明确，所以不会有这方面的问题 3、哪怕文字写出来也有理解不一样导致做出来的也不一样的现象，只是写出来会减少很多这种概率 4、不过老外很多时候喜欢举例子，例子类比一下，很多时候就很清晰了 5、单讲规格或者概念，加上中文神奇的断句，的确很难统一理解的 6、 我倒觉得由于书面原因导致的错误理解的几率更大 7、agile原则还有例如用户故事都鼓励有效交流 8、不会的，文字发出来没有提异议就认为大家都认可这个了，文字是在大家讨论后整理出来的，所以不会错误理解的 一些想法：
Q1：有一个矛盾点，开始讲产品需求的时候，基本都是很笼统，细节很少甚至基本没有，测试的时候，所有细节都有，所以现在的问题是：产品讲完了，技术去开发，按照原来的需求都搞好了，到测试的时候，开始产品需求没讲的，技术也没想到的，问题就都出现了。敏捷教练遇到这样的情况，如何处理？ A1：产品评审不够细致？只是产品讲其他人只是听？ A2：这种现象要分情况：1、产品真的想不了那么细致；2、产品压根就只想了解个大概；那么针对以上情况，我们团队在做的就是，第一步：产品原型出来，由技术负责先跟产品过一遍，提出问题，产品修改，然后在跟团队过。第二步：过完需求，开发开始编写技术方案，并进行技术方案评审，在评审的时候就可以倒推有些考虑的细节。第三步：测试编写测试方案，并且团队参与评审。通过这几步下来，基本上就没什么遗漏了。还有一种就是，如果Scrummaster不懂技术，那么在团队内部你可以挑选一个信的过的技术负责人，如果产品在过需求的时候，大家都很沉默，不提问题，那么很多问题都会遗留到测试时才会发现。 A3：测试不是由方案评审么，这就解决产品细节问题，另外要求开发做自测，这就解决开发对细节把握不当问题，落地开发自测，需要开发TL和项目经理还有测试一起形成共识，这是devOPS的基本观念。 A4：需求沟通应该不是一次性的呀，是个持续过程。 A5：需求过大需要拆，魔鬼都在细节里。 A6：满足DOD了吗？必须满足的业务有哪些？先保证必须满足的业务流程跑通，再限制其他异常问题，细节是持续性的，主题需求应该是一致性确定的，否则大家在一条自以为正确（最后发现是错误）的路上越走越远。 A7：产品经理不能讲很多细节的需求，我们之前是开发者写详细需求，很像测试用例，测试组会review，这样细节问题出得很少，但现在是粗的需求测试组会测出很多细节问题，很多都是开发者没想到的，关键在于前面是否给开发者时间去写详细需求。 Q2：我头一次觉得将SM的问题 ，提到这群里简直太正确了。。。感谢大家。 不一一谢过了。。大家思路都很棒，主意真正。有两个观点特别好：第一，细节是持续的涌现的。第二，开发，测试提前熟悉产品方案。这里面还有一个问题，就是需求颗粒度问题。产品经理讲需求是拿什么讲。PRD吗，流程图吗，还是原型？ A1：我们是拿原型 A2：最好是对着原型，如果大家能确保还原度的话，对着PRD也没意见 A3：所谓开发说的细节的点，其实原型能讲清楚。但是PRD或流程图未必，对着流程需要设计规范高度严格才可以。 A4：不是有影响地图吗？影响地图对于实现来说太抽象了。 Q3：有推荐的做法么？ 1、我们当初就是对着原型，大家澄清也是对着原型澄清，少很多事，产品做个大方向，有疑问的拉着相关开发先小范围聊聊，等梳理的时候听大家的看法。 2、嗯嗯，很细节的问题还是免不了沟通，尤其相关 UIUE、前后端开发、测试的沟通。 Q4：实践过程中，一个用户故事细节渐进明细，但只要现有的细节满足了用户的实际需求，价值得到体现是否也可行？ 1、影响地图出来个大的。然后再每个功能来切吧？这样主线业务就很清晰 2、实际的矛盾是开发不关心主线，产品想拉着主线却被开发拖进细节，于是产品就精分了 3、开发往往关注自己的地 4、实际上不是每个人都只关注自己的地吗？影响地图我觉得 还行吧，比较适合做产品，项目就算了。 Q5：从大到小，拆分下来不会脱离主线吧？ A1：会的，每个人都从自己的角度“优化”一点，流程就有问题这种事发生过。 Q6：这个问题是不是要由系统工程师去整体把控啊？ 1、严格来讲架构或者技术经理负责平衡，实际上方案太大的时候也很难盖住，而方案小了这角色又干脆没有。 2、嗯，确实有这个问题。 3、我渐渐的开始感觉到为啥做敏捷金字塔上面是文化，理念。。。实践还好推。但是思想的局限达不到能够顺畅推进敏捷需要的那种open 和 主动，很多实践推起来也会走样和鸡肋。 4、实践里很多时候产品兼非技术的架构工作，然后技术性架构需要决定的事也要依赖过来，产品就很头疼还有另一个极端，就是让技术架构兼产品，第二个我们自己栽过跟头，第一个可能是今天讨论遇到的场景的一部分 5、 open和主动/还是免不了沟通，感受到了吗？ 6、其实“沟通”这个词儿本身 也被大家曲解很多。想清楚-表达清楚-对方听清楚-确认一致。 7、是的，有些人觉得我跟你讲了=咱沟通了，对方一脸？？ 8、我说了，你听着，沟通常态…… 9、现在很多沟通变得也很鸡肋。产品很委屈，我一开始就给开发讲需求，但是那时候开发还没开始做功能，所以大家抱着很轻松的心态。实际吸收力没有那么好。产品清楚的记得自己讲过的细节。过程中开发忘记的有，开发没听到的有，开发自己理解也有。大家可能以为做在一起“ 面对面了 ”说了 ，有了沟通的过程了就OK ,没有几个人真的会去想沟通的效果，对沟通效果负责才是对团队协作有意义的，要不然就是无休息的聊。一个之前说过的功能，真正做时候就跟没讲过一样，还要聊半天，大家也可以想想，这样低效的沟通，还哪有时间去真正写代码。所以，我认同需求应该是涌现式的，但是不赞成没章法的沟通。 10、你讲完需求一定要让开发者整理出来，你再review一次，这样才能保证他们是否真正理解了没有。 11、很好。我们执行的类似，开发反讲嘛。不过这个要看时机。如果不是真正上手做，脑补不出具体问题的。 12、一般是写出来的时候才会进行思考的，沟通完了要落在文档里啊，以文档为准。 Q7：写代码的最讨厌写文档，众所周知。。。这个还真没尝试过。一条需求让开发要写什么文档呢？ 1、每次开会都有主题 结果。这些要记录下来啊。还有哪些是确认。开会前要先梳理好。才能高效。每次会议只解决一个问题。 2、prd应该让产品出啊 3、需求都是 项目经理或产品写。如果是比较复杂的。需要 开发那边写一个设计文档。评审过后 没问题就实现，后续测试可以拿着这两份文档去测试。 4、设计文档我一般不看的，开发自己约定好就是… 5、这样不行的。到时喷起来没证据 6、会和测试同学约定一些测试通过与否的约定…验收标准必须产品出，满足验收标准就算过 7、我觉得产品还是有必要参与 实现方式的讨论的。还是需要形成文档记录下来。虽然麻烦点，但是后期拼起来就是产品白皮书。 8、还是要定下来完成的定义和验收标准嘛… 9、不管是文档形式还是邮件形式，一定要写出来，以他为准 10、所以讨论的发起是产品，开发和测试现场反讲的结果整理到文档（可以是文字、录音、录屏……）并且上传到知识库上作为开发依据，需求验收的时候验证文档一致性。不一致看PO验收产品还是文档，验收文档改产品，验收产品改文档，两个都不对就是产品的问题了，先找到偏差小的统一过去，再补充需求条目修补偏差。 Q8：我在外企很多年从未听过反讲这个词，后来接触民企才知道这个词。根源还没搞明白 1、确认双方理解是否一致，反讲是一种很好的方式 2、我理解可能是中文博大精深，一个词语有多种解释方式，所以需要双方确认；英文相对比较明确，所以不会有这方面的问题 3、哪怕文字写出来也有理解不一样导致做出来的也不一样的现象，只是写出来会减少很多这种概率 4、不过老外很多时候喜欢举例子，例子类比一下，很多时候就很清晰了 5、单讲规格或者概念，加上中文神奇的断句，的确很难统一理解的 6、 我倒觉得由于书面原因导致的错误理解的几率更大 7、agile原则还有例如用户故事都鼓励有效交流 8、不会的，文字发出来没有提异议就认为大家都认可这个了，文字是在大家讨论后整理出来的，所以不会错误理解的 一些想法：