• 人月神话阅读笔记02


      继续人月神话的阅读。

      在书中,作者提到了关于外科手术式的队伍。这点是我刚开始稍微有点不理解的。我们都知道,在现代的开发中,一般不会有个人开发的情况,毕竟一个人不会将事情做得那么全面,无论他是多么的强大,个人能力是多么的突出,他仍然会在一些情况下出现各种各样的问题,所以,我们一般的都是采用的多人参与开发,最少的都是2个人,像我们进行完的双人的结对开发,还有现在进行着的多人的团队开发。这样做的原因一是因为受到我们现在开发项目的大小的限制,还有我们人员的限制,使得我们必须这样,更重要的是,现在的开发中需要这样的简单的小型的精干的团队,因为这样去开发的时候会觉得开发效率更加的高,但是,随着项目的发展,会需要越来越多的功能和人员,这样就逐渐形成了外科型的队伍。

      记得在当时阅读《构建之法》的时候,我们看到过关于一些团队模式的介绍。在我深入读这本书的时候,发现,对于本书中所说的队伍,还是有很大的优势的。在书中,作者提到的是这样的:大型项目应该分为若干部分,每个部分,由一个外科手术式的团队完成开发,在每个团队中,只有一两个人主要负责开发设计工作,其他人负责“外科医生”的协助工作,所有不一致的观点由“外科医生”负责统一,通过这种人员的专业化分工实现高效开发。 这点是让我能够恍然大悟的事情。我本来一直是认为这种模式是一个不好的模式,没想到在作者的笔下通过案例分析,很好的给我们指点了迷津。这让我想到以后的工作,是不是大多数都是这样模式,在我们进行一项工作的时候,我们就会进行这样分配,为了进行工作的充分的资源利用。

      像是我们现在的团队,也是要尽量去向这个模式去靠近,因为我觉的,我们当前的团队在开发的时候很具有盲目性,在开发的过程中没很是容易做一些超过自己工作之外的事情,当其他人在去做同样的事情之后,发现这样的事情已经被人做了,因此就不会再继续去做这个事情,这样会形成一个团队的惰性,对于整个团队的发展是很不利的。因此,我们需要贴近于这中状态,就像是老师说的那样,一个大腿可以抱,但是要抱得有意义。

  • 相关阅读:
    关于Thread ThreadPool Parallel 的一些小测试demo
    VS附加到进程调试
    netcore 实现一个简单的Grpc 服务端和客户端
    CodeSmith 找不到请求的 .Net Framework Data Provider
    ocelot集成consul服务发现
    使用ocelot作为api网关
    关于add migration 报错的问题解决方案
    关于多线程efcore dbcontext 的解决方案。
    docker mysql 容器报too many connections 引发的liunx磁盘扩容操作
    关于liunx 机器脱机环境(netcore)Nuget包迁移的问题
  • 原文地址:https://www.cnblogs.com/yandashan666/p/11071351.html
Copyright © 2020-2023  润新知