关于敏捷讨论的感想

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了关于敏捷讨论的感想相关的知识,希望对你有一定的参考价值。

两种过度

讨论的确是必要的,很多时候,只有经过大家详细的讨论,集思广益,才能定出‘最优’的设计方案。

但沟通有时也是毫无生产力的,尤其是当我们陷入了对实现细节的争论时。

大连和武汉(我们公司的两个分部),在这方面可谓是两个极端,所以也体现出各自不同的优缺点。或者说真正的善,必须要做到不偏不倚,把握好度。 

 

武汉大多数情况是没有讨论的,产品经理大概的过一下需求,开发人员很快凭直觉给出了解决方案。这样做的缺点很明显,会经常有需求或者设计方案的变动。

但是也有自己的优点,就是能够快速投入开发,哪怕开始的方案是错误的。因为如果你的代码足够优雅,经常变动的方案并不会浪费你太多时间,有时相对于‘无休止的争论’,快速开发还是值得的。

(足够优雅是指,项目的每个小模块,做到高内聚,低耦合,且尽量无业务,无状态。当需要修改方案的时候,这些核心的原子模块已经实现了,修改方案不过是一些微调,不过是另一种组装。)

接下来说一下第二个优点。开发之前,无论你怎么讨论,所有的方案都只是假设,没有开发,很多的坑,很多的不合理,你根本就想不到;没有开发,你根本就想不到,很多的坑,很多的不合理,根本就不存在。

有时实实在在的开发,才能拨开迷雾,让真正的问题显现出来。

 

大连这边讨论的比较多(印象中想找大连的伙伴了解问题,大多是在开会^_^)。这次来大连,亲身体验 感受很多——特别是关于讨论。

第一次迭代关于课次的设计,考虑到上传和转码的耗时,从最开始的一个页面到最后的两个页面拆分,考虑到并发的情况,用写入version检查,最终的方案可谓是完全变了个样子,但是却是一个近乎完美的方案。第二次迭代,在修改上架课程班级,考虑到上架信息必须完整,也是改成了更好方案。
这种充分讨论带来的结果,给我的冲击很大——武汉是没有这样的,所以总是要花精力去调整方案,或和产品经理协调沟通!

当然大连这边有时讨论会过多。有好几次,明显感觉到不需要继续了,可是讨论却没有停止的迹象,时间就在无意义的讨论中流逝。好在这方面,大连已经意识到了,并且正在改进。

探寻解决方案

到底该讨论什么?

这不是一个好问题。因为讨论不只是和内容有关。


如果仔细推敲的话,讨论任何内容包括需求细节,技术实现,设计方案等,在某些时候是浪费时间,在某些时候却能给你的方案带来gift。大量的讨论经验也说明了这一点,任何内容都不是绝对的。
经常回想之前开会讨论的种种细节,想给这个问题写出一个答案,但是发现这根本不可能。

但是有一点是肯定的,人员的技术水平,表达能力,个人修养,做事态度,非常重要——优秀的人是开放的去交流,能大胆的抛出问题,更能及时的止住自己的交流欲望(或说服欲望)。及时的止住自己的欲望,既节省了时间,也照顾了别人!

 

还有一点可以肯定的是,有意义的讨论带来结果是 对既定方案进行修改和优化。
而这一点似乎是可以预见的。有时候明显的感觉到讨论是在浪费时间,可是讨论者却乐在其中。有时后讨论明显不足,方案明显不够确切,却匆匆进入了开发。

我们并不能要求每一个人员都是全方位的优秀,但是却可以让一个头脑清晰的人调控讨论的趋势。这也是我强烈建议的——安排一个主持人,并建议主持人不要是讨论的主角(讨论的主角是指,需求 方案 的关键阐述者和制定者)!

 

我的另一个建议是会议人员的互补,特别是性格上的互补。不同性格的人,思维方式,看问题的角度,做事风格不一样,正因为这样,‘完美’的方案才变得可能;但也正因为这样,融合好各个性格的人,是有一定的挑战的,这就是一个团队的魅力了。

外向性格的人,有发起讨论,并让讨论尽可能全面的可能,而内向性格的人,有制止讨论,并综合出完美方案的可能。遗憾的是武汉人员较少,性格基本相似,这也是武汉一直做不好的重要原因。

以上是关于关于敏捷讨论的感想的主要内容,如果未能解决你的问题,请参考以下文章

敏捷开发感想

关于最近996.icu的一点感想

敏捷的一些感想

一些讨论读书的感想

阅览敏捷开发的感想

软件工程到敏捷开发的一点小感想