第一章 敏捷----高效软件开发之道
不管路走了多远,错了就要重新返回。
敏捷开发宣言
1、个体和交互胜过过程和工具
2、可工作的软件胜过面面俱到的文档
3、客户协作胜过合同谈判
4、响应变化胜过遵循计划
先难后易,我们首先要解决困难的问题,把简单的问题留到最后。
第二章 态度决定一切
选定了要走的路,就是选定了它通往的目的地。
我们会专注于那些真正的目标。集中精力,你是为做事而工作。
1、做事
出了问题,你想把寻找罪魁祸首设为最高优先级,难道不是吗?肯定的答案是:不,最高优先级应该是解决问题。也许你不相信,但确实有些人常常不把解决问题放在最高优先级上。也许你也没有。先自我反省一下,当有问题出现时,“第一”反应究竟是什么。
指责不能修复bug ,把矛头对准问题的解决办法,而不是人。这是真正有用处的正面效应。
勇于承认自己不知道啊答案,这会让人感觉放心。一个重大的错误应该被当作是一次学习而不是指责他人的机会。团队成员们在一起工作,应互相帮助,而不是互相指责。
2、欲速则不达
在工作压力之下,不去深入了解真正的问题以及可能的后果,就快速修改代码,这样只是解决表面问题,最终会引发大问题。
---------2020.1.13-----------
要理解开发过程
尽管我们在谈论理解代码,特别是在修改代码之前一定要很好的理解它,然而同样的道理,你也需要了解团队的开发方法或者开发过程。
你必须要理解团队采用的开发方法,你必须理解如何恰如其分地使用这种方法,为何它们是这样的,以及如何成为这样的。
只有理解了这些问题,你才能进行有效的改变。
不要孤立地编码。
3、对事不对人
要专业而不是自我
多年以前,在我担任系统管理员的第一天,一位资深的管理员和我一起安装一些软件,我突然按错了一个按钮,把服务器给关掉了,没几分钟,几位不爽的用户就在敲门了。
这时,我的导师赢得了我的信任和尊重,他并没有指责我,而是对他们说:“对不起,我们正在查找是什么地方出错了。系统就会在几分钟之内启动起来。”这让我学到了难忘的重要一课。
在一个需要紧密合作的开发团队中,如果能稍加注意礼貌对待他人,将会有益于整个团队关注真正有价值的问题,而不是勾心斗角,误入歧途。我们每个人都能有一些极好的创新想法,同样也会萌生一些很愚蠢的想法。
好的软件开发作品和好的软件设计,都需要大量的创造力和洞察力。分享并融合各种不同的想法和观点,远远胜于单个想法为项目带来的价值。
我们每个人都会有好的想法,也会有不对的想法,团队中的每个人都需要自由地表达观点。即使你的建议不被全盘接受。也能对最终解决问题有所帮助。不要害怕受到批评。记住,任何一个专家都是从这里开始的。“你不需要很出色才能起步,但是你必须起步才能变得很出色。”
团队决策的骆驼
集体决策确实非常有效,但也有一些最好的创新源于很有远见地个人的独立思考,如果你是一个有远见的人,就一定要特别尊重别人的意见。你是一个掌舵者,一定要把握方向,深思熟虑,吸取各方的意见。
一些有效的特殊技术
设定最终期限:防止人们陷入无休止的理论争辩之中,保证团队工作的顺序进行。
逆向思维:一种客观对待问题的办法是–先是积极地看到它的正面,然后再努力地从反面去认识它。目的是要找出优点最多缺点最少的那个方案。有助于少带个人感情。
设立仲裁人:防止明星员工操纵会议并及时打断假大空式发言。
支持已经做出的决定:一旦方案被确定了,每个团队成员都必须通力合作,努力实现这个方案。
对事不对人。让我们骄傲做的应该是解决了问题,而不是比较出谁的主意更好。
#
尽力贡献自己的好想法。
#
脱离实际的反方观点会使争论变味。
#
想要支持或反驳一个观点,有时候你必须先做一个原型或者调查出它有多少的同意者或者反对者。
#
在开发者眼中的最好,不一定就是用户认为最好的,反之亦然。
#
只有更好,没有最好。只有在某个特定条件下更好的实践。
#
不带个人情绪并不是盲目的接受所有的观点。
############2020.1.16
4、排除万难,奋勇前进
有时,绝妙的计划会因为勇气不足而最终失败。尽管前方很危险----不管是真的鱼雷或者只是一个比喻-----你必须有勇气向前冲锋,做你认为对的事情。
假如要你修复其他人编写的代码,而代码很难理解也不好使用。你是应该继续修复工作,保留这些脏乱的代码呢,还是应该告诉你的老板,这些代码太烂了,应该通通扔掉呢?
也许你会跳起来告诉周围的人,那些代码是多么糟糕,但那只是抱怨和发泄,并不能解决问题。相反,你应该重写这些代码,并把糟糕的代码放到一边,立刻重写。列出重写的理由,会有助于你的老板(以及同事)认清当前形势,帮助他们得到正确的解决方案。
第三章
学无止境