微软研发致胜策略 01:尊定基础

这是一本老书,作者 Steve Maguire 在微软工作期间写了这本书,英文版于 1994 年发布。我们看到的标题是中译版名字,英文版的名字是《Debugging the Development Process》,这本书详细阐述了软件开发过程中的常见问题及其解决方案,强调团队合作、项目管理和开发流程的优化。该书成为软件开发和项目管理领域的经典著作,受到了广泛的认可和赞誉。

作者 Steve Maguire 曾在微软担任高级项目经理和软件工程师,这是他写的第二本书。第一本书是之前文章已经介绍过的《编程精粹—— Microsoft 编写优质无错 C 程序秘诀》,在《编程精粹》中,作者关注的是开发过程中最严重的 “BUG”:太多的软件 BUG。而本书是《编程精粹》的补充,是为每个团队成员准备的:如果一个软件项目要取得成功,每个团队成员都必须理解那些能够按时交付高质量软件的原则、指南和策略。本书中的建议对开发过程进行了微调,重点介绍了软件团队可以使用的技术和策略,以实现持续的成功。本书包含许多轶事性例子,大多数来自微软的经验。

成功的项目维系在每位组员身上,才能如期完成高品质的软件。本书所提供的技巧和策略,不是软件开发主管会用就够了,每位组员都必须充 分了解。除非每个人都懂得如何在合理的工作时间内做出 高品质的软件,否则项目仍是不会成功的。


不记录,等于没读。


成功的软件项目负责人都牢记一些原则。其中最重要的一个是,程序员应该只从事那些直接或间接改进产品的任务。负责人的工作是为其他团队成员的主要工作扫清障碍,通过无情地消除那些妨碍产品改进的工作——例如,过度的状态报告和会议,或开发对产品或公司没有战略意义的功能。为了便于确定哪些任务是战略性的,哪些是浪费精力的,负责人应制定详细的项目目标和优先事项。目标和优先事项越详细,就越容易发现浪费的工作。

如何使项目的进行更有效率?

要让项目提高效率,需要长时间、一点一滴地累积非常多的知识、技巧和信念,尤其新手更是如此。这种能力的培养需要很大的耐心和毅力,需要从错误中学习。如果能善用前人的经验,学习前人已经归纳出来的知识,避免犯下同样的错误,可以快速提升你的技能。本章首先介绍前人的经验,这是软件开发部门的基本观念,也是往后几章的基础

1. 专心改善产品

软件开发的真理是:任何不能改善产品的工作,都是潜在的浪费或是错误的努力。公司付薪水给程序设计师,是要他们在合理时间内做出品质精良的软件,不要让无关的事情占用他们的时间。

你要专心研究、设计和测试产品。开会、写设计文档、写进度报告等等,都是在浪费时间,因为这些事情不能改善产品。这些浪费时间的事情,往往是领导下的命令:让组员交工作周报、每周一小时会议,讨论各自的工作内容,并要求写书面报告交给经理。这会让团队被无意义的工作压得无法喘息。报告真那么重要吗?经理不能主动收集组员的工作内容吗?

软件开发领导者的基本守则是:努力消除程序设计师工作上的一切障碍,让程序设计师全力专注在真正重要的工作——改善产品

思考如何设计、测试程序和接受培训虽然不是直接投入在改善产品上,但对产品质量却有重大深远的影响。有些团队的活动,可以让团队成员在愉快的环境中工作,提供程序设计师的生产力和士气,虽然看似与产品无关,最后还是对产品质量与工作效率有正面帮助。

2.排除干扰

如果希望团队在期限内完成任务,就必须尽可能排除一切不必要的工作,在将任务分配给组员前,想一下这件工作有没有必要、能不能由你做

  • 那些不能不做、却与产品无关的工作,最好由主管主动接手,让设计师专心在软件上面。
  • 凡是能有主管出席的会议或能有主管执笔的报告,都不应该丢给程序设计师,最好能把这些开会、报告都废除。
  • 如果管理者将工作分出去的目的仅仅是为了减轻个人负担,实质上你做的是伤害团队生产力的事情。

保护程序设计师不受任何阻碍和干扰。身为主管的重大责任就是让属下专心做他该做的事,无论他该做的是写程序、测软件还是写文件。

3. 一定有更好的方法可以减少干扰

因为太容易被不重要的工作拉偏方向,所以在项目的每个阶段问自己:“我努力的目的究竟是什么?”努力的目的应该是改善产品,所有与这个目标不一致的行为都要警惕,要想办法减少这种行为。

掌控项目的进度不一定非要动员全体人员开会和写进度报告。进度报告是必要的,因为经理要了解项目是否出问题。但进度报告绝对不会对产品有任何帮助。这种必要但对产品没有帮助的工作,我们需要想一个更好的方法,即保有这项工作的好处,又消除它的缺点。对于进度报告,一些更好的方法有:

  • 每当有人完成了一项新功能或特色,就发个 e-mail 给大家 (简短的描述,只发给同组的几个人)
  • 每当进度快要落后了,就到主管的办公室私下讨论原因,一起寻求解决之道
  • 可以使用版本控制工具,每次提交都有说明,管理者也可以方便查看代码和测试。

4 明确的说出目标

“在我合作过的团队中,有 6 个在失败边缘苦苦挣扎,他们都有一个共同特征:目标太模糊!”

某小组任务是编写图形函数库,这个库给另外 20 个左右的小组使用。但使用者对这个库并不满意:既笨重、BUG 也多。

他们组长认为自己小组的任务是: 为 MS-DOS 应用程序提供图形接口库

但这个库包含很多某个小组需要但其他小组不需要的特殊函数,因为只要有人提出需求,他都来着不拒,后果就是函数库越来越笨重。另外一个问题是函数库在发布新版本的时候还经常的修改函数名,因为他们发现了更好的名字或者要强调修改的差异部分。这会导致使用者更换新版本时会链接错误,让使用者无所适从。

只要在作出决定之前想一想,“我要这个函数库能做到什么?项目目标是什么?”只要组长把目标整理的清楚些,整个项目的方向就会有惊人的改变,这个项目更具体化的目标是:为 MS-DOS 应用程序提供图形接口库,只包含对所有小组都有用的函数,并且保持版本向后兼容

项目失控最有可能的原因是小组之间工作上的相互依赖: 一方必须依赖另一方把工作做完才能进行自己的工作,而且若是彼此的配合或沟通不够好,整体工作必然受到不利的影响,依赖愈多,愈容易失控。使用共享函数库有很多好处,这是人尽皆知的事。但是身为组长的人,必须衡量是否该把这部分的程序代码放进项目中,所获得的好处与必须忍受的缺点——让其他的工作依赖于它, 孰轻孰重。任何领导者,必须牢记并且实践以下的座右铭:尽可能减少项目对其它组的依赖

5 努力要有收获

设定目标 就是把“你要完成的事”用清晰的语言描述出来,让每个人都有明确的概念

目标越是明确,达成目标的过程就会越有效率,因为你能马上拒绝任何与你脑海中的画面不符的东西;明确的目标之所以带来效率,正是由于它能帮你挡掉别的项目丢过来的不相干的垃圾,使你专注在本项目的策略性事项上。但是在开发过程中,庞大的压力迫使领导者没有时间思考,因而忽略了设定目标这么重要的事。不要因为工作漫无目标,而让你的组员长期加班、饱受压力,以至于他们的努力没有收获。

6 确定软件开发遵循的优先顺序

每一位程序设计师的侧重点并不相同,有人侧重执行速度,有人侧重代码尺寸,也有人侧重稳定性。如果程序设计师心目中理想的优先顺序与项目目标不一致,通常不会产出好的产品。作为管理者,你需要建立你们小组最适当的软件开发应遵循的优先顺序,并让所有人确实遵守。可以从以下侧重点中考虑:大小、速度、可靠性、安全、可测试、可维护、可移植。关键是你必须事先决定编码的优先级和质量标准,否则团队将不得不浪费时间重写错误或不合格的代码。

你可能听过很多极为成功的人士都有当机立断的倾向。如果普通人做出快速决策,大都是颜面尽失的悲惨下场。与普通人的区别在于,这些成功人士有 明确的目标清晰的优先事项。如果你给这些人一个问题或提议,他们会立即将其与脑海中铭刻的目标和优先事项进行比较,立刻就会有答案。他们目标和优先事项的清晰性也解释了这些人的另一个众所周知的特征:一旦做出决定,他们很少改变主意。改变主意意味着背叛他们的信念。这些成功人士实际上并不是在做出仓促决定——这个想法暗示没有经过思考。只是这些人对自己的目标和优先事项非常了解,以至于他们不必为不符合他们标准的事情浪费时间。结果是:他们不必花太多时间来做决定,而是花时间去做已经决定的事

7 严守基本原则

软件开发的基本观念:

  • 确定你要达成什么目标及如何去做,让每一位组员都明白目标,并专注地朝这个目标努力;
  • 确定开发遵循的优先顺序,以及相对应的指令规范指导。

这些都是很基本很简单的观念,但就是很少人能严格遵守。

要点

公司聘请程序设计师,是为了开发高品质的软件,但如果经常被杂事打扰、分心,就无法保持专注在真正该做的事情上。主管必须确定程序设计师能专心投入在具有策略价值的工作上,而不是打杂。凡是会阻碍软件开发的东西,主管应该毫不犹豫地把它排除。

然而,有很多杂事其实是无法避免的,大公司尤其如此,那就只好将它的负面效应尽量减少,方法是不断自问:“我到底想要完成什么?”、“我该怎么做才能既保持这件工作的好处,又能避免它的坏处?”要满足实质上的需求,而不是表面上的作业程序。

拥有明确目标所带来的好处虽然不是立竿见影,但没有明确目标所造成的混乱绝对是显而易见。没错,建立明确目标是一件费力又无趣的工作,但比起项目延误或失控的危险,肯定是值得付出的。请记住用户界面函数库例子,项目目标只要稍微改好一些,就会明显地减轻压力,项目目标再修正一次,问题就几乎都迎刃而解了。

每一位成员都必须有一致的软件开发应遵循的优先顺序,程序的可维护性是最重要的吗?可移植性?大小?速度?为了让软件符合项目的目标,必须让程序设计师明白本项目应遵循的优先顺序,这样他们在程序设计时才知道该如何取舍。同时,你还得对每一项优先考虑点事先建立质量规范指导,以避免到时候质量不合格又得重写部分程序,导致时间浪费和项目延误。越早定出质量规范指南,越能省时省力。






每一份打赏,都是对创作者劳动的肯定与回报。
千金难买知识,但可以买好多奶粉

相关推荐

最近更新

  1. docker php8.1+nginx base 镜像 dockerfile 配置

    2024-07-20 13:16:02       52 阅读
  2. Could not load dynamic library ‘cudart64_100.dll‘

    2024-07-20 13:16:02       54 阅读
  3. 在Django里面运行非项目文件

    2024-07-20 13:16:02       45 阅读
  4. Python语言-面向对象

    2024-07-20 13:16:02       55 阅读

热门阅读

  1. spring-gateway整合swagger2统一微服务接口文档

    2024-07-20 13:16:02       16 阅读
  2. 定个小目标之刷LeetCode热题(45)

    2024-07-20 13:16:02       20 阅读
  3. 人工势场法路径规划算法

    2024-07-20 13:16:02       13 阅读
  4. Android笔试面试题AI答之Activity(2)

    2024-07-20 13:16:02       17 阅读
  5. HIVE:使用get_json_object解析json对象

    2024-07-20 13:16:02       18 阅读
  6. Elasticsearch索引管理和生命周期管理

    2024-07-20 13:16:02       18 阅读
  7. 现代生活背景下陶瓷艺术设计的延伸与发展

    2024-07-20 13:16:02       19 阅读
  8. LeetCode 2956.找到两个数组中的公共元素:哈希表

    2024-07-20 13:16:02       18 阅读
  9. 麦芒30全新绽放,中国电信勾勒出AI手机的新方向

    2024-07-20 13:16:02       20 阅读
  10. Prometheus 运维中实际的故障案例以及解决办法

    2024-07-20 13:16:02       15 阅读
  11. Gmsh应用程序编程接口

    2024-07-20 13:16:02       12 阅读
  12. 【Go系列】RPC和grpc

    2024-07-20 13:16:02       16 阅读