敏捷设计的的4个核心思想

Posted 2023-03-03 小雷FansUnion

来自《互联网产品之美》。

4个核心思想

1、强调面对面的沟通，也就是说沟通很重要，任何人的相互交流胜于任何流程和工具；

2、要把精力集中在可执行的程序上，可以运行的产品胜于综合性文档，也就是强调了原型、模型、演示等的重要性；

3、团队合作和团队激励，合作胜于谈判，敏捷开发能将需求分析、开发、测试等全部团队成员融合成一个整体，大家都是“一条线上的蚂蚱”；

4、团队成员要有超强的适应能力，适应变化胜于按部就班，敏捷开发的特点就是快速，对于互联网行业来说，这点非常重要。

       敏捷设计强调的是团队成员的高度参与，目的就是要让大家统一认识，把团队的目标变成每个人的工作目标，并得到每个团队成员的认同，

形成高度的凝聚力，以达到群策群力、高效协作的效果。

      在敏捷设计过程中，由于没有高度细化的文档，成员之间交互信息的唯一渠道就是面对面沟通，良好的团队氛围和协作关系促进了这种沟通，

并使得消息有效传达。

上面几段话，总体比较靠谱，文档方面值得进一步探讨。

---

下面是自己的3点看法：

1、老外提出的很多概念、想法，可能是有一定的适用场景，也有可能是到了国内就“水土不服”，因为国内极度强调效率等特色化的东西。

懂得自然都懂。

我所经历学习到的：UML统一建模语言、敏捷开发、领域驱动设计、单元测试（国内普遍都是“伪”单元测试）。

概念都挺好，就是难以落地。

2、敏捷开发

国内存在非常推崇敏捷开发的人群，也有很多相关书籍和实际。

在xx厂xx团队期间，有幸参与了“敏捷开发”模式。

总的观点：“新瓶装旧酒，换汤不换药”。其实，很难见到全新的事物和方法论，通常只是名字不同，但内涵其实都差不太多。

比如，敏捷开发的特有实践：早会、晚会、看板、认领工作和工时、master角色。

存在不接地气或者无法“普试”的做法。

1）、快速开发、快速上线。

普遍存在一种现象，很多上游人群对“敏捷开发”的直观认识，就是：我提出一个需求，你们赶紧开发，赶紧上线。

单方面强调，加班加点干活。

“敏捷开发”成了让下游加班干活，快速出成果，廉价劳动力的借口和幌子。

2、早会和晚会

对于很多场景来说，会开多了，没啥意思，除了浪费时间。

1天大概就8小时，除去开会，进度不会那么明显。

频繁的开会，哪有这么快的进度更新。

如果跨部门、跨项目或者人员较多时，每个人的节奏根本就不同，比如上班下班时间点。

3）、看板

需求方或者大家之间，对别人的工作，根本没那么在乎。

如果是需求方和进度管理有需要，直接1个在线Excel表格或wiki页面即可。

纸质看板，写纸条、描述任务、贴纸条，已经过时啦。

通常来说，老板要的是：总的进度计划、里程碑节点、好的结果，提出需要协调解决的问题，任务细节没那个功夫关注。

结果优先。

4）、认领工作和工时

普遍存在一种情况：每个成员的定位角色，就决定了每个人该干嘛。

认领工作适用于自组织的情况？什么场景合适呢？

5）、master角色

一般不就是组长、项目经理、产品经理等人担任么？

做的事情有啥本质区别吗？

还是说只是形式不同，名称不同？

3、事物发展需要的条件和环境

橘生淮南则为橘，橘生淮北则为枳。

事物生长发展，需要相应的环境和土壤。

只吹好处，不讲环境，是无法落地的，最终只是形式而已。

中国的制度、人文环境、行业特点，都需要考虑，否则容易变了味，甚至成了相关人群的单方面道具。