《大道至简》读书笔记 收藏 此文于2010-12-15被推荐到CSDN首页
如何被推荐?
最近发现一本有意思的项目开发书籍,晚上睡不着的时候读,特别提神。
为了不金玉与内,特摘录其中一些片段,供大家玩味,书名叫做《大道至简》,作者是谁,大家网上查一下就知道了:)
以下为引用,虽然不是每句都对,但可以带给我们思考: (觉得不过瘾可以参照附件,不过请下班后再看哦)
1.一接到任务就开始Coding的程序员,通常就是加班最多的程序员。
记住:积极工作和勤于思考都要占时间。
2.做管理起码需要能承担责任,这是最基本的素质。
3.你的项目经理职位又没有让给别人做,你拿的经理级工资又没有分给别人,那项目失败了,你为什么要把责任推到别人头上呢?
4.经验丰富的工程师能尽可能接近地预估工期,但没有办法保障(预估的)工期是绝对合理的。那么进一步的推论是,由于没有绝对
合理的工期,所以项目的完成时间可能总是
被进度变更所修正,所以项目也就总是不能“成功”。项目工期的问题不能解决,就不能保证项目成功。只有经验更加丰富,才能
更尽可能地逼近“合理的工期”。因此在此之前,项目
经理面临的就是失败。这个失败可能不是项目经理本身能力所决定,或者也不是团队成员的工作所决定,而是在一开始,那份给客
户的项目协议就签错了。
5.软件工程中有专门的学科来研究项目的工期问题。学者们试图寻找公式来计算项目的复杂度,从而计算出所需的工时和人月。然
而在实践中,这被认为是不可行的
6.如果员工在工作中出了纰漏:
没有制度,你没有办法和依据来惩戒员工,因此是管理者的过失;
有了制度而没有惩戒他,是执行者和监督者的过失;
一而再、再而三地犯错,又一而再、再而三地被惩戒,那就是教而不改,就真正是员工的品性和素质的问题了
7.在任何错误被归咎于员工之前,管理者应该先想想是不是自己的问题。是的。你可能很快发现问题出在了管理者。因为管理者没
有
确定组织机构模式,或者没有为组织中的成员进行角色定位和分工。如果这样,出现“既不能令,又不受命”的人就是必然的事了
8.一个至少由三个人构成团队:项目经理,开发经理和开发人员。其中,在开发经理和开发人员之间,既存在主从关系,也存在协
作
关系。而项目经理,则在团队中处于领导者、组织者和团队保障者的地位。如果非得要精简到两个角色的团队模式,那么这种情况
下,通常是开发经理兼任项目经理,因此这位开发经理一定要能清楚地区分这种双层角色的身份:在任何时候,明确自己是在进行
“团队内协作”、还是“团队管理(和组织)”、还是在与“团队外交流”。如果这个开发经理总是混淆自己的角色,那么,我建议
,换人吧。
9.团队真的需要管理吗?
这经常是“经营”开发团队的管理者最容易给错答案的问题。这些管理者兢兢业业,试图细化每一个管理环节,将自己的意愿贯彻
到??EN,CPU里去。
实际上,开发团队并不需管理。或者说,在你还没有弄清楚状况之前,不要去管它。
10.禀性难移,要改变一个人都难,何况是改变一个团队的既定习惯。
如果有一群开发人员象蚂蚁一样辛勒地工作着,那么,先不要打扰他们。你应该跟随他们,看看他们是如何做的。发现规律,分析
这个规律的价值,最后再尝试改变它们(的一些负面价值的规律)。
11.尽管弹性分工非常有效,然而真正做弹性分工却并非易事。
更好的选择是明确分工,而不是弹性分工。你应该明白,重要角色的更替通常是极具风险的,例如项目经理或
者开发经理;频繁的开发人员的调度也会直接影响到工程的质量和进度。
12.维护旧项目比做新项目更难,许多人深有同感。然而这些“有同感”的人又何曾想过,自己在做“新项目”的时候,要为“项目
维护”这种还不存在的角色,留下一个沟道、对话的渠道呢?
我把项目的History作为跟这种“不存在的角色”沟通的一种方式。History的丰富和准确为项目的后继开发、维护提供了可能。
13.UML的确是解决沟通问题的最佳手段之一。然而如果项目一开始就不能用它,那么强求的结果必然是痛苦的。——要让UML在一个
没有经过相关培训的团队及其各个角色之间用起来,几乎是不可能的事。即使用得起来,也存在经验问题。千万不要指望仅仅一个
项目,就能让你的组员深刻的理解UML的思想。使用与不使用UML,其根本的问题在于沟通方式的选择。只要是行之有效的、能在各
个项目角色间通用的,就是好的沟通方式。
14.流于形式的沟通,可能是使得你的项目被不断推翻和不断延迟的最直接原因。
15.相对于瀑布模型,V模型有改变了什么吗?是的。源于实际的需要,它把测试(和评审)阶段抽取出来,于是就成了V模型。
16.用RUP用不好的人,总会说自己终归还有一堆文档模板可以抄
17. 如果懂得了所谓的模型原本都演化自那个简单的瀑布,那么文档是按XP写还是按RUP写,也就可以应时、应需,因地置宜,择善
而从了。
18. RUP中,真正精髓的东西,既不是那个R(Rational),那是人家的招牌;也不是那个U(Unified),那是人家的广告。而是那个P
(Process),那才是实实在在的东西。
19.无论是你的团队成员,还是你的老板,对重复的错误以及可预料的错误都是不会宽容的。——在一个团队中,失去了组员的信任
比失去老板的信任更为可怕。所以回顾每一个项目,或者项目中的每一个阶段,以及与每一个团队成员交流的细节,是你的日常工
作。
20. RUP其实就象一个杂物箱一样“包容”了全部的已知理论。
21. 总之一件事,没有人会跳出来说:我们原本就错了。然而事实上可能真的出在源头:我们把目标定错了。
我们看到,在项目的平衡三角(时间、资源和功能)中讨论的是目标问题,但并不讨论质量问题。也就是说,经典教材中总是关注:
如何更快的完成项目,并减少资源占用,以及实现更多的功能。然而,即使平衡了这种关系,项目的结果仍可能产生一个天生的残
障。
因为目标可能在平衡中确立,但质量却要在过程中控制。即使在时间、资源和功能三者中取得了平衡,即使客户、项目组和公司同
样满意于这个平衡“目标”,它仍然有可能是“不能实施”的。
如果原定的目标(的整体)本身就过大,那么无论如何平衡这三者之间的关系,其结果仍旧是保障不了质量。
22.大多数情况下,管理人员有责任去审核、评估其它成员的工作成果。这个时候可以讨论“细节决定成败”这样的问题,因为这决
定了产品的最终质量,而质量是工程的目标之一。
而在另一些情况下,例如管理人员做事件的决策的时候,就必须要学会忽略枝节问题。
23. 从惯于“实做”的程序员一路走来的工程人员,很难分清自己什么时候是在“工作”,而什么时候又是在“决策”。
因此我只好用最笨的方法提示管理者:别管它是细节还是枝节,只要你感到你的脚趾已经沾上了泥淖,就快点回头。
用脚趾去感觉,有时比用头脑去思维来得有效。
本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请
点击举报。