读《与熊共舞》

《与熊共舞》的重点在于风险管理,从风险的定义,讲到如何发现风险并管理风险,再阐述工具、如何量化等等,结构非常紧凑,例证很多,很有条理,读起来很流畅。熊节的翻译真不是盖的,一级棒!正如简体中文版上封面上所写,它确实算得上和《人件》、《人月神话》等并驾的好书。

在组织或团队中,当你发现风险,你有勇气说出来吗?也许会,也许不会,但请必须学会。风险具现的后果是对项目、组织,甚至社会造成很大的影响,想想航天飞机失事的事故吧。软件开发工程师不能简单的用“加班”做为“风险缓解”手段,有时再怎么加班也无济于事。“职业”的做法就是报告风险,无论项目处在什么阶段。

对于团队的Lead更有挑战的是,要习惯用风险图向自己的老板汇报,而不是拍胸脯说“在某某日这个项目一定做完“。在讲这话时,真的那么有底气吗?需求的不确定,估算的不确定,技术难点的不确定,代码遗留问题的不确定,人员的不确定等等,对于开发都是风险,而且常常发生的过程中。对于开发团队来说,对控制范围之内的风险最好的缓解就是平时多下功夫。和产品工程师做充分的需求分析与确认可以降低需求方面的不确定,代码全员所有会降低估算的不确定,时常的代码重构会降低遗留问题,积极培训可以降低技术风险等。当然这些都是成本、时间、人才,有看的见的,也有看不见的,但对团队和组织,这些活动都非常重要,特别在关键时刻。风险总是存在,只是可大可小。对于无法控制的风险,如需求变化的风险,对R&D,那应该属于”别人的风险“,自己是无法避免。团队还要有自己的风险仓库,项目做得多了,就从慢慢从中受益。

开发的方式也很重要。如使用增量式就可以减少风险,其实很好理解,把一个项目拆成若干个小的单元,范围小了,反馈快了,当然不确定就少了。只是能不能用就难说了,有时不在开发方,很多用户也不一定能接受。

书里提到了很多工具和方法也挺有意思,如”灾难头脑风暴“,用噩梦、水晶球等富有启发性的活动帮助团队发现风险;Riskology的Excel开上去就非常强大,需要的时候不妨一试。

总之,非常推荐大家读一读这本书!

最后附上我做的脑图。

与熊共舞

 

 

读《软件方法》(上册)

《软件方法》(上册)不是只是简单介绍如何使用UML和工具的书,更是教你思考软件的本质,是潘加宇多年工作实践的总结。区区几十元可以读到这样的好书,真是无比值得。

从研究生阶段的项目到现在,我参加软件的研发已有十余年,经历过各种返工,究其原因都是因为需求没有搞清,拍着脑袋写方案。程序员多数都是技术型的,有东西做就想着怎么能更聪明的把工作完成。设计模式、重构、单元测试等各种工具技能都练的烂熟,UML也多数用在设计阶段。时间长了,各种需求的问题就出来了。需求常常“变化”,确如书中所说,需求不是真的;没有Product Owner,需求没有统一管理,大量需求散落在Issue Tracking系统里,无从查起。

《软件方法》让我重新审视软件需求的重要性。UML有很多方法对需求进行建模,一步步的发现业务机会,为用户提供更大的价值。软件工程师一定要搞清什么才是最重要的,不然拍脑袋或“镀金“的情况就会有很多。此外书中关于”阿布思考法“的讲述也无比精彩。

书中的道理归道理,可一个组织的改变谈何容易! :(

 

读《最后期限》

一本挺有意思的老书!作者把项目管理的知识融入了一个离奇的、不可能在现实世界发生的项目(或者叫实验或冒险),最后再加上一个完美的英雄美人式的大结局,让我等IT男屌丝情何以堪啊。 这Project Manager也太美了吧,”财色兼收“啊!

故事之外,有些道理挺好,摘几句有感触的。

  • 度量每个产品的规模,运用各种工具和方法做好估算。
  • 压力之下人无法快速思考。短期的压力对团队可能是有益的,帮助团队成员集中注意,但长期的压力一定是错误的。(深有感触!)
  • 生产力提高来自长期的投资,平时要加强团队学习和建设。(罗马不是一天建成的)
  • 除非必要,否则不要自己去凝聚一个团队:出去找已经成型的团队。(这就是为什么要挖挖一窝吧)
  • 项目开始的浪费一天和Deadline之前浪费的一天,它们的危害是相同的。(珍惜时间)
  • 组织里时常有“神经”的人,提一些不可能的需求,如不可能的deadline. 你不能满足所有Stakeholder的需求,要寻求影响力更大人的帮助,再不然,可以考虑走人了。别想根治一个神经的人。(主人公的做法在现实中是不可取的。)
  • 不要辱骂团队成员,没人能在辱骂之后表现的更好。
  • 拒绝含糊的规格文档。(实现和其他产品一样的功能!OMG)
  • 适当的处理团队中的冲突。
  • 项目需要仪式!

读《程序员的数学》

程序员的数学
程序员的数学

这是本小书,把很多深奥的数学原理结合到了很多小故事中,读起来很轻快,适合在工作忙碌的间隙阅读。

数学是很多程序员常挂在嘴边的东西,并总觉得没有学好,有东西不会,需要提高。这是好事,是某种“越了解越无知”的表现。这时读读书,总能觉得学到了些东西,或者以前学到的知识被加强了。

到底什么是程序员的数学呢,作者主要有总结如下:

  • 简单规则(2进制)
  • 逻辑
  • 有“余数”来分组
  • 数学归纳法
  • 排列组合,递归

其实很多基本方法和思想也都能在日常工作中体现,比如从简单做起,尝试小数,抽象扩展。

《打造Facebook》读后

清明小假,深圳大雨,窝在家把同事推荐的《打造Facebook》读完了。书真的很棒,和程序员的生活很近,感觉亲切,结合日常工作感触很多,此外还大大开阔了眼界。读过本书的同学应该对Facebook都有无限向往吧。

工程师的地位

以前就听说Google里的工程师地位很高,Facebook看来也不类外。这些都直接激发了工程师的各种主动、自发、积极、创新等。但我想也有很多公司里的工程师没有这样的幸运。就我所处的半导体行业,虽然工程师(指主要写软件,行业背景不多的工程师)的作用很大,但说到地位,和Google,Facebook还是也没法比。其实原因也显然易见,因为这个行业讲究背景,讲究经验,除非你的行业背景很深,很多工程师并没有太多发言权。即使是在我们善长的领域,比如前端设计等,也不是每次都可以说服那些定义需求的大佬们。这和互联网行业就有很大的不同。

地位如果别人不给,就自己争吧!如果想提高、想生长,就一定要给自己可以“折腾”的空间,如果没有也要创造。不是说一定要去学习艰深的行业知识(除非你喜欢),工作中总是会遇到问题,技术上的、流程上的,需要不断总结,运用各种手段、方法找到解决的方法。当你解决了问题,取得了一定的成绩,别人不说你的地位也高了。即使这家公司不给,别家也会给的。^_^

工具开发

开发中的工具是非常重要的!我想每个程序员都能体会。完善的Tool Chain会大大的提高工作效率,工作时的心情,会有进行艺术创作的快感。如果你改了行Code,等编译结果要5分钟,我想什么心劲都没了(这是几年前我的经历)。

像我们这种行业背景很深的公司,一般开发人员很难接触到真正的客户。所以就成就感来说,可能开发一个很Cool的工具来得更大一些。但我想使用工具还是要针对目前的大问题,像书中讲到Facebook的工具都是针对他们开发、运维中遇到的大问题,要有明确的目标,认定是值得投资的,特别是在人力资源本来就不多的情况下。

开发流程

Facebook的开发流程有很多Agile的元素,但没有看到书中强调他们使用了Agile,所以我想Agile是种自然的结果,特别是当很多聪明人在一起工作的时候。这几年的工作,也让我越来越体会到,传统的软件开发流程、项目管理本身就不适合现在的软件开发。比如产品经理提了一个很大需求,然后很多人参与讨论,制定Spec,甚至有几轮的Review,几周后终于被Boss finalize了。然后开发人员会根据Spec,做估算,做计划。开发终于开始了,可你很快会发现,几轮Review的Spec还是有问题,一个Demo Meeting之后,大伙各种建议,Spec被改,可能是小的,也可能大的。大的有些会影响你的计划,然后计划也改了。这中间我们浪费了很多资源!为什么不能在大方向有的情况下就开始做一个迭代呢,在开发中发现问题。因为很多问题(特别是细节)只有在动手之后才会发现,对着PPT很难发现什么。这样也许可以省掉几周的时间。

工作中的指导

以前读过《One Minute Manager》,很多做法和书中也有很多一样的。其实做为Leader或Manager就是要帮助下属定义明确的目标,然后及时的给反馈,不管是对的方面还是坏的。目标可以一起讨论,可以借鉴SMART原则,反馈则要根据实事,不要针对个人。

关于招聘

记住了书中那句“Hire Slow,Fire Fast”。人才对于一个技术团队实在是太重要了,一定要慎重,不能降低标准,即使慢点也是值得的。但当发现一个人不合适(观察的过程自然是较长期的),就一定要快!一团合气其实对双方都不好。但如果团队的领导年轻,有时候是很难告诉别人Bad News的,其实是不习惯之后可能的对抗,不管是激烈的还是冷的,所以一定要实事求是,摆事实,做到对事不对人。不适合在这个团队,在别的岗位可能就非常适合,公司就有这样的例子。

书中还有很多大开眼界的地方,比如Facebook的股票分配,天使投资等。下次有机会真想去Facebook看看。:)

 

《Lean from the Trenches》读后

这书是腾讯组织的某次敏捷交流会上组织者准备的小奖品。我因此发现在它。最能吸引我的是“精益”,“看板”,“大型项目”几个词。在工作中引入Agile这几年,我其实一直都疑惑不断,有对方法的,对过程的,对人的,对现状的。现在也很清楚Agile在公司不能真正发挥威力的症结在哪,只是真的很难破除。也没关系,有些东西自己说得也不算,就把自己能做的控制好,开发中不足的地方好好改进一下。

说说书吧。其实英文书名才能真正的表达书中的内容,“来自战壕里的Lean”。作者正是把自己在一个项目的心得与实践分享给了大家,告诉我们在遇到问题时他们如何做的,原因是什么,结果怎么样。这也是很讲Agile书的一个特点,没有很多理论,大家都在讲实践。Agile Development本来就是讲究实践,形式只是浮云,很像武当太极。学到了几招,如“不去估计故事点,只计故事数”,如“技术故事如何处理”,如“大项目的多个团队如何汇总消息”还有“如何使用因果图”。

关于精益。在考PMP的时候学过,源与Toyota。在软件领域,精益开发的很多实践也有很多可取的地方。书中的总结是“全局优化”,“消灭浪费”,“品质当先”,“不断学习”,“尽快交付”,”人人参与”以及“不断提高”。很多提法也不陌生了。

方法再好,实践再棒,还是要靠我们自己去践行!人才是最重要的!

《程序员的职业素养》读后

看了Bob大叔的这本书,只在软件质量上这一点就很汗颜,感觉距离真正的“专业人士”还有很大差距。

以前的项目,常常给自己找些“时间紧,任务重,资源不足”的借口就放低了对质量的要求,很多应该坚持的好东西没有坚持。这个找借口的过程非常自然,好像事情本来就是这样的。之后常常发现项目的质量有问题,BUG很多,或是实现的功能没有满足要求,往往要花费更多的时间和资源来弥补,同时还要承受很大的压力(担心其他BUG出现)。这些做法确实非常不专业!

参加工作以来,5年多时间,经历过两个大的项目。第一个有大量的维护性工作,遗留代码多,代码的结构也相对差,同时工具旧,生产率低。工程师都很“惧怕代码改动”,不会轻易改旧的代码,只好慢慢的改进,效率就更低。第二个项目用了更先进的技术,全新的平台,工具链完备,且从头做起。一开始想着要大干一场,多注意单元测试什么的,可到后来,好多应该有的流程都丢了。产品的BUG很多,代码改动依然很困难。我想资源一定也是问题,我们组一共也就4人,多的时候平台上要做2-3个不同的Release,有时候真的应接不暇。

新的项目就在眼前了,又有了很多期许,还是从最基本的坚持做起:

  • 真正的实现代码规范
  • 推行TDD,做可测试的设计(试试先,阻力可能不小!)
  • 引入验收测试(让SQA的人试试)
  • 对工期不再妥协

加油!