软件工程之美40讲——最佳实践:小团队如何应用软件工程?

软件工程之美40讲——最佳实践:小团队如何应用软件工程?

小团队在软件开发中存在的常见问题

  1. 小团队成本敏感

首先,小团队对成本都很敏感,成本是小团队很多问题的根源,对成本的控制也衍生出一系列大公司可能感受不到的问题。
2. 小团队人少活多

从分工上来说,通常在大厂前端后端几个人合作完成的事,在小团队就得一个人从前端写到后端了,可能甚至都不会有专业的产品设计和功能测试人员,都是开发兼任。从人员构成来说,大厂在组建技术团队时会注意梯队的搭配,整个团队像金字塔的结构,顶部有几个特别资深的开发人员,中间有一些经验丰富的,底部的是有潜力但经验比较少的。而小团队就算是运气好,也可能只有一两个技术大牛,更多的是水平一般、经验比较少的。这样的分工协作和人员构成,导致的问题就是大家每天都很忙,但是感觉技术上积累有限。
3. 小团队缺少流程规范

项目开发比较随意,拿到需求可能就开始直接写代码了,没有严格的需求分析、架构设计,写完了后简单测试一下就上线了,上线后再修修补补;需求变更是家常便饭;多个项目并行的时候,每个项目的负责人都觉得自己的项目是最重要的,希望你能把他的项目进度往前赶一赶;老板权力很大、想法多变,经常会直接干预项目。这样不规范的开发流程,导致的结果通常就是开发效率低下,软件产品质量不高,项目计划难以遵守甚至没有计划。

小团队怎么使用软件工程

小团队如何招人

比较现实的方法就是招有潜力的程序员培养。也不能一味节约成本,还要注意梯队的建设,中间要有几个有经验的技术骨干帮助把控好代码质量。

小团队如何培养人

  1. 师傅带新人的机制其实对小团队一样适用,对新人来说可以快速融入,及时获得指导,对于师傅来说,通过带人,也能促进自身的成长。除了有师傅带,新人的技术成长,

  2. 工作过程中不断实践和总结,在这个过程中,及时准确的反馈很重要。软件工程中,像代码审查、自动化测试、持续集成都可以帮助对工作结果进行及时反馈。

  3. 在小团队推行这样好的开发实践,让团队获得及时准确的反馈,有助于整个团队的成长。

  4. 内部的技术分享也是很好的共同提升的方式,对于听的人来说可以学习到一些新鲜的知识,对于分享的人来说,准备一个技术分享,本身就是最好的学习总结方式。

  5. 还有在分工方面,最好是让“大牛”一半的精力负责一些重要的像架构设计、框架开发的工作任务,同时还要有一半的精力在代码审查、带新人等方面,帮助其他人一起成长,整个团队的发展才能更健康。

小团队如何管理人

  • 小团队的管理,核心在于营造好的氛围,鼓励成员自我驱动去做事。
  • 还要注意的就是遇到线上故障、进度延迟这些不太顺利的情况,更多的是提供帮助,一起总结复盘,而不是甩锅问责。

有关开除人
在应用软件工程的时候,团队中可能有些人会成为障碍,要么是能力不足无法落实,要么是态度有问题抵触软件工程的实施。在这种情况下,首先对于有问题的成员肯定是要努力挽救,如果是能力不足,就给予帮助,给时间成长,对于态度有问题的,明确指出其问题,限期改正。但如果最终结果还是达不到预期的话,那就必须要果断地将这些成员淘汰。

流程建设

选择适合你的软件开发模型

首先在开发周期上,应该缩短交付的时间,使用快速迭代的开发模型。因为小团队的一个特点是需求变化快,要求交付的速度快,那么快速迭代或敏捷开发就是一个合适的开发方式。具体在实施上,可以缩短并固定开发周期,比如说每 2~4 周可以发布一个版本。在做迭代的规划时,优先选择当前最核心最重要的功能;在一个版本内,不轻易接受新的需求变更,有需求变更放到下一个迭代中;在迭代时间结束了,无论新功能是否开发完成,都按时发布新版本,没完成的放入下一个迭代。另外在会议上,敏捷 Scrum 的几个会议也可以借鉴,像每日站立会议,可以帮助团队及时了解项目进展,解决进度上的障碍;每个迭代的计划会议,可以让大家一起参与到计划的制定中;每个迭代的验收会议,可以让业务部门、老板及时的验收工作成果,看到大家的工作进展;每个迭代的回顾会议,可以帮助阶段性复盘总结,不断优化开发流程。还有基于看板的任务可视化,也可以帮助团队直观的看到当前迭代中的任务进度,可以主动选取任务,而不需要去问项目经理下一步该做什么。

构建基于源代码管理工具的开发流程

很多小团队开发质量低,开发混乱的一个原因就是没有使用源代码管理,也没有一套基于源代码管理的开发流程。在专栏文章《26 | 持续交付:如何做到随时发布新版本到生产环境?》和《30 | 用好源代码管理工具,让你的协作更高效》中,对于如何基于源代码管理工具构建和开发已经有了非常详细的介绍,这些开发流程一样适用于小型团队。有一点要注意的是,小型团队完全没有必要自己去从头搭建自己的源代码管理工具、持续集成工具,应该尽可能采用在线托管的服务,这样可以节约大量搭建、维护工具的人力和时间成本。类似的策略也应体现在技术选型上,小团队应该尽可能使用现成的工具、框架,而避免自己造轮子,把主要精力放在业务功能的开发上面。

建立外部提交需求和任务的流程

小团队在流程规范上混乱的一个体现是,业务部门包括老板对于提交开发任务非常随意,可能直接找某个开发人员私下让改一个需求,增加一个功能,导致开发人员不能专注于任务开发,经常被打断。如果一个业务团队的开发任务特别紧急要插队,那么意味着其他业务团队的任务就必须要受影响,那么就需要大家一起去协调。对于提交需求和任务的人,也能通过任务跟踪系统,及时的了解到任务的进展。在团队之外推行这样的流程是会有一定阻力的,最好是能事先去找几个关键的业务负责人私下沟通,取得理解和支持,让他们知道这样做对他们的好处,比如说可以更好地跟踪任务的进展,让开发效率更高,更好地为他们完成任务。

posted @ 2021-01-22 23:53  段志轩  阅读(14)  评论(0编辑  收藏