大道至简——软件工程实践者的思想读书笔记三
第六章 谁是解结的人
在一个模式化的公司里,体制上最大的敌人其实是模式本身。
在通常情况下,一个团队的特质是管理者在团队生活和行为过程中逐渐形成的。
成功的经验往往最不可信,因为一方面,成功者沉醉于成功的喜悦,并急于与人分享快乐与荣誉,而不关注这些成功的前提与背景。另一方面,听取这些经验的人则因为那些“既有的成功”而丧失了应有的警惕。
经验,是源于对过去的思考,而不是对过去的复制。
只有提出质疑,才能换个角度去看到那些成功经验所依赖的背景,也才能看到某些成功背后的偶然或者关联的因素。
你的团队无论如何都需要有一个远期的目标。
远景更多地侧重于方向性的描述,而阶段性目标的确也是必须的,原因:
明确阶段性目标以便于团队实施和检测
细化的设定目标更加灵活,便于修正
阶段性成功能充分激励团队的士气
项目经理的主体工作是:协调,督促,激励,监督,凝聚。
应该让团队每一个人清楚:“我”必须跑到终点,否则“团队”到不了终点。这是每个个体的责任,没有人可以替代——这是培养责任心和树立价值观的事。
培养一个人最怕的是“教而不习”,你教他,他要么不学,要么不用,但是事情的真相,不见得是这个人“懒”到不学习,而是你过于勤快,让他失去了“习”的机会。所谓学习,就是让他在过程中看到问题,并了解到解决问题的方法,最后加以解决。
于一个人而言,“成功”的激励远大于其他。
过于强调个人能力,会助长团队的惰性。团队管理是促进整体行进的过程。
管理者的责任也包括“监督,发现问题并防止扩散”。因而要主动给自己留下时间和空间来发现问题,在问题出现之前定位它、分析它,并组织人力去解决它,而不是:
等问题出现后再冲到前面
然后在还没有清楚地意识到问题的根源时就试图解决它
最后刚解决了表面问题或者侧面问题,又发现更多的问题挡在前面
最后之最后,你垮掉,团队也垮掉
即使你什么也不做,也比整队人都停下来要强得多。
学会否定矛盾、消化矛盾,看到矛盾产生的内因、外因,转而借之用之,才是解脱的方法。
第七章 从编程到工程
语言只是工具。
从角色的角度上来说,开发经理思考项目的实施方案和管理具体的开发行为,而项目经理则保障团队的稳定性和一致性。
经验来源于回顾、理解和分析,而不是你将要写的下一行代码。
过程说的是很多人(团队)如何组织在一起进行开发的问题。它首先把工程中的环节分解出来。这样,有了环节,就有了角色,有了角色,就有了沟通。因此,过程中的问题就是角色、沟通和环节的问题。哪些环节重要,取决于具体的编程行为,也就是具体的项目。
角色的确定,以及角色间的沟通问题,在项目过程中也同样重要。工程组织是否合理,相互协作是否紧密,是这个项目能否成功的保障。
项目的“复杂”可能要求不同知识领域的角色参与,而“庞大”则要求更多的(人、技术与管理)资源。“团队”作为开发行为的模式,是软件规模和复杂度渐次累积的结果。
团队必将越来越庞大,因为(与工程对应的)软件必将越来越复杂。没有团队意识的软件公司在高度过程化、通晓方法论、拥有大量工具的集团军面前,必将一触即溃。
你必须更关注于对这个(或这些)工程的组织与计划。站在“组织者”这个角色上,你现在要考虑的内容可能会是:
为项目的各个阶段建立计划、并逐渐地细化计划的内容,以及确立项目过程中每一个环节,每一个计划阶段的优先级和复杂度。
确立项目或者产品阶段目标,成果的准确描述、定位,以及整个项目的质量目标及其评核办法。
对团队中的不同角色开展培训,以指导并协调角色间的工作,从而消除因为工作习惯的差异带来的影响。
为每一个人准备他所需要的资源,准确地评估他的工作量,以及决定是否为他增加一个副手。
决定在哪些环节上反复审核和回顾,而在哪些环节上采用较为宽松的方式以加快进度。
习惯于开会、组织更短而有效的会议,以及建立激励机制,当然也不要忘记让每一个成员意识到这一项目的风险。
不要乐观。
好的项目经理并不是不犯错误的人,而是以尽可能少的失败来获得成功的那个人。
回顾每一个项目,或者项目中的每一个阶段,以及与每一个团队成员交流的细节,是你的日常工作。
经营者决定了一个方向,组织者保证决策与这个方向是同步的,而工程是在这样的一个方向、决策的架构下的一个具体行为。
第八章 你看得到工具的本质吗?
工具之于工程,本质在于关注并发挥有益于工程全局的那些特性。
不同的工程角色确实应当有他自己的关注点。这个角色能考虑到别人想不到的问题,固然不错,但如果他恪尽职守,只关注自己的那一部分,也是本分。
一项技术是以完成工程需求为目标的,而不是以彰显个人技术为目标的。
技术容不得取巧,只能点滴累积。“静下心来做代码”是开发人员的良好品质。作为开发人员,我们不应当妄自菲薄,作为管理人员,我们更应该善而用之。
“写代码”并不是解决问题的唯一方式。融通是以一通十,有运用变化的能力。融同,是知工具之大同,信手而得,随心而用。
工程实践中,用或者不用某个工具,仅取决于工程本身的需要,而不取决于喜好,也不取决于现实中的大公司与外来布道者的鼓吹。
于某时某事,适用的就是最好的。前提是你要有看明白这些工具实质的能力。只要能够分辨出所需要的部分并适度地用在你的工程中,就可以了。
识见到工具“设计”所满足的那些“确定的需求”,进而明确工具与项目的关系,才是解脱之法。