没事写写博客，没事拍拍照片。。。
去年，在去夏威夷的飞机，拜读了一下海明威的《老人与海》。小说不长，5个多小时的飞行绰绰有余。读完后，最难忘的是老人的那份坚持。
不就是捕鱼嘛，管它是大还是小，为什么要这么拼命？！老人坚定地用毕生积累的经验和那条大鱼斗到底，哪怕是最后鱼死网破。不能输给一条鱼！这是一个渔夫的惯性思维？老人在捍卫着他的尊严，那是他所剩无几的东西。想想自己，有没有捍卫的“鱼”？应该有，自己好像一直在别人眼中简单且微不足道的技术或项目上花精力和时间，自己好像也进入了一个惯性的思维。捕鱼自然没有那么简单，那些项目其实也充满挑战。怕的是，自己进入一种惯性。自己是否真的喜欢捕鱼，也许不！好在，自己还有很多时间可以学习别的领域，可以去尝试。需要的只是一份勇气吧！
老人和大鱼的争斗非常惊心动魄，但很庆幸，老人最终可以回到那个属于他的港湾，有那个等他回家的男孩。希望将来的自己在一番拼杀后，也能回到一个安静的港湾吧！
《与熊共舞》的重点在于风险管理，从风险的定义，讲到如何发现风险并管理风险，再阐述工具、如何量化等等，结构非常紧凑，例证很多，很有条理，读起来很流畅。熊节的翻译真不是盖的，一级棒！正如简体中文版上封面上所写，它确实算得上和《人件》、《人月神话》等并驾的好书。
在组织或团队中，当你发现风险，你有勇气说出来吗？也许会，也许不会，但请必须学会。风险具现的后果是对项目、组织，甚至社会造成很大的影响，想想航天飞机失事的事故吧。软件开发工程师不能简单的用“加班”做为“风险缓解”手段，有时再怎么加班也无济于事。“职业”的做法就是报告风险，无论项目处在什么阶段。
对于团队的Lead更有挑战的是，要习惯用风险图向自己的老板汇报，而不是拍胸脯说“在某某日这个项目一定做完“。在讲这话时，真的那么有底气吗？需求的不确定，估算的不确定，技术难点的不确定，代码遗留问题的不确定，人员的不确定等等，对于开发都是风险，而且常常发生的过程中。对于开发团队来说，对控制范围之内的风险最好的缓解就是平时多下功夫。和产品工程师做充分的需求分析与确认可以降低需求方面的不确定，代码全员所有会降低估算的不确定，时常的代码重构会降低遗留问题，积极培训可以降低技术风险等。当然这些都是成本、时间、人才，有看的见的，也有看不见的，但对团队和组织，这些活动都非常重要，特别在关键时刻。风险总是存在，只是可大可小。对于无法控制的风险，如需求变化的风险，对R&D，那应该属于”别人的风险“，自己是无法避免。团队还要有自己的风险仓库，项目做得多了，就从慢慢从中受益。
开发的方式也很重要。如使用增量式就可以减少风险，其实很好理解，把一个项目拆成若干个小的单元，范围小了，反馈快了，当然不确定就少了。只是能不能用就难说了，有时不在开发方，很多用户也不一定能接受。
书里提到了很多工具和方法也挺有意思，如”灾难头脑风暴“，用噩梦、水晶球等富有启发性的活动帮助团队发现风险；Riskology的Excel开上去就非常强大，需要的时候不妨一试。
总之，非常推荐大家读一读这本书！
最后附上我做的脑图。
《软件方法》（上册）不是只是简单介绍如何使用UML和工具的书，更是教你思考软件的本质，是潘加宇多年工作实践的总结。区区几十元可以读到这样的好书，真是无比值得。
从研究生阶段的项目到现在，我参加软件的研发已有十余年，经历过各种返工，究其原因都是因为需求没有搞清，拍着脑袋写方案。程序员多数都是技术型的，有东西做就想着怎么能更聪明的把工作完成。设计模式、重构、单元测试等各种工具技能都练的烂熟，UML也多数用在设计阶段。时间长了，各种需求的问题就出来了。需求常常“变化”，确如书中所说，需求不是真的；没有Product Owner，需求没有统一管理，大量需求散落在Issue Tracking系统里，无从查起。
《软件方法》让我重新审视软件需求的重要性。UML有很多方法对需求进行建模，一步步的发现业务机会，为用户提供更大的价值。软件工程师一定要搞清什么才是最重要的，不然拍脑袋或“镀金“的情况就会有很多。此外书中关于”阿布思考法“的讲述也无比精彩。
书中的道理归道理，可一个组织的改变谈何容易! 🙁
一本挺有意思的老书！作者把项目管理的知识融入了一个离奇的、不可能在现实世界发生的项目（或者叫实验或冒险），最后再加上一个完美的英雄美人式的大结局，让我等IT男屌丝情何以堪啊。 这Project Manager也太美了吧，”财色兼收“啊！
故事之外，有些道理挺好，摘几句有感触的。
这是本小书，把很多深奥的数学原理结合到了很多小故事中，读起来很轻快，适合在工作忙碌的间隙阅读。
数学是很多程序员常挂在嘴边的东西，并总觉得没有学好，有东西不会，需要提高。这是好事，是某种“越了解越无知”的表现。这时读读书，总能觉得学到了些东西，或者以前学到的知识被加强了。
到底什么是程序员的数学呢，作者主要有总结如下：
其实很多基本方法和思想也都能在日常工作中体现，比如从简单做起，尝试小数，抽象扩展。
清明小假，深圳大雨，窝在家把同事推荐的《打造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看看。:)
这书是腾讯组织的某次敏捷交流会上组织者准备的小奖品。我因此发现在它。最能吸引我的是“精益”，“看板”，“大型项目”几个词。在工作中引入Agile这几年，我其实一直都疑惑不断，有对方法的，对过程的，对人的，对现状的。现在也很清楚Agile在公司不能真正发挥威力的症结在哪，只是真的很难破除。也没关系，有些东西自己说得也不算，就把自己能做的控制好，开发中不足的地方好好改进一下。
说说书吧。其实英文书名才能真正的表达书中的内容，“来自战壕里的Lean”。作者正是把自己在一个项目的心得与实践分享给了大家，告诉我们在遇到问题时他们如何做的，原因是什么，结果怎么样。这也是很讲Agile书的一个特点，没有很多理论，大家都在讲实践。Agile Development本来就是讲究实践，形式只是浮云，很像武当太极。学到了几招，如“不去估计故事点，只计故事数”，如“技术故事如何处理”，如“大项目的多个团队如何汇总消息”还有“如何使用因果图”。
关于精益。在考PMP的时候学过，源与Toyota。在软件领域，精益开发的很多实践也有很多可取的地方。书中的总结是“全局优化”，“消灭浪费”，“品质当先”，“不断学习”，“尽快交付”，”人人参与”以及“不断提高”。很多提法也不陌生了。
方法再好，实践再棒，还是要靠我们自己去践行！人才是最重要的！
看了Bob大叔的这本书，只在软件质量上这一点就很汗颜，感觉距离真正的“专业人士”还有很大差距。
以前的项目，常常给自己找些“时间紧，任务重，资源不足”的借口就放低了对质量的要求，很多应该坚持的好东西没有坚持。这个找借口的过程非常自然，好像事情本来就是这样的。之后常常发现项目的质量有问题，BUG很多，或是实现的功能没有满足要求，往往要花费更多的时间和资源来弥补，同时还要承受很大的压力（担心其他BUG出现）。这些做法确实非常不专业！
参加工作以来，5年多时间，经历过两个大的项目。第一个有大量的维护性工作，遗留代码多，代码的结构也相对差，同时工具旧，生产率低。工程师都很“惧怕代码改动”，不会轻易改旧的代码，只好慢慢的改进，效率就更低。第二个项目用了更先进的技术，全新的平台，工具链完备，且从头做起。一开始想着要大干一场，多注意单元测试什么的，可到后来，好多应该有的流程都丢了。产品的BUG很多，代码改动依然很困难。我想资源一定也是问题，我们组一共也就4人，多的时候平台上要做2-3个不同的Release，有时候真的应接不暇。
新的项目就在眼前了，又有了很多期许，还是从最基本的坚持做起：
加油！
