敏捷的世界观

川长思鸟来 2023-08-17 17:38 119阅读 0赞

# 敏捷的世界观 #

有一种相当流行的软件方法学要求对一个项目分配35种不同的角色，包括架构师、设计人员、编码人员、文档管理者等。敏捷方法却背道而驰，只需一个角色：软件开发者，也就是你。项目需要什么你就做什么，你的任务就是与客户紧密协作，一起开发软件。敏捷依赖人，而不是依赖于项目的甘特图和里程表。

> 这大概是全栈工程师吧，哈哈哈~

## 为做事而工作 ##

> 恶魔：“出了问题，第一重要的是确定元凶。找到那个白痴！一旦证实了是他的错误，就可以保证这样的问题永远不会再发生了。”

在敏捷的团队中，大家的重点是做事。你应该把重点放到解决问题上，而不是指责犯错者上面纠缠。

你可以从自己先做起。如果一个开发者带着抱怨或问题来找你，你要了解具体的问题，询问他你能提供什么样的帮助。这样简单的一个行为就清晰地表明你的目的是解决问题，而不是追究责任，这样就会消除他的顾虑。你是给他们帮忙的。这样，他们会知道每次走近你的时候，你会真心帮助他们解决。他们可以来找你把问题解决了，当然还可以继续去别处求助。

如果你找人帮忙，却没有人积极响应，那么你应该主动引导对话。解释清楚你想要什么,并清晰地表明你的目的是解决问题，而不是指责他人或者进行争辩。

> 天使：把矛头对准解决问题的办法，而不是人。这是真正由用处的正面效应。

### 切身感受 ###

*  勇于承认自己不知道答案，这会让人感觉放心。
 *  一个重大的错误应当被当作是一次学习而不是指责他人的机会。
 *  团队成员们在一起工作，应互相帮助，而不是互相指责。

### 平衡的艺术 ###

*  “这不是我的错”这句话不对，“这都是你的错”这句话更不对
 *  如果你没有犯过任何错误，就说明你可能没有努力去工作。
 *  开发者和质量工程师争论某个问题是系统本身的缺陷还是系统增强功能导致的，通常没有多大的意义。与其如此，不如赶紧去修复它。
 *  如果一个团队成员误解了一个需求、一个API调用，或者最近一次会议做的决策，那么也许就意味着团队的其他成员也有相同的误解。要确保整个团队尽快消除误解。
 *  如果一个团队成员的行为一再伤害了团队，则他表现得很不职业。那么，他就不是在帮助团队向解决问题的方向前进。在这种情况下，我们必须要求他离开这个团队。
 *  如果大部分团队成员（特别是开发领导者）的行为都不职业，并且他们对团队目标都不感兴趣，你就应该主动从这个团队中离开，寻找更适合自己发展的团队（这是一个有远见的想法，没必要眼睁睁地看着自己陷入一个“死亡之旅”的项目中。

## 欲速则不达 ##

> 恶魔：“你不需要真正地理解那块代码，它只要能够工作就可以了。哦，它需要一个小小的调整。只要再结果中再加上几行代码，它就可以工作了。开工吧！就把那几行代码加进去，它应该可以工作。”

我们经常会遇到这种情况，出现一个Bug并且时间紧迫。快速修复确实可以解决它——只要新加一行代码或者忽略那个列表上的最后一个条目，它就可以工作了。拙劣的代码工人会不假思索地改完代码，然后快速转向下一个问题。优秀的程序员会挖掘更深一层，尽力去理解为什么这里必须要加一，更重要的是，他会想明白会产生什么其他影响。

> Beware of land mines

在工作压力之下，不去深入了解真正的问题以及可能的后果，就快速修改代码，这样只是解决表面问题，最终会引发大问题。短期看，它似乎是有效的。但从长远来看，通过几年的积累，代码里有着成千上万的补丁修复，在这样脏乱的代码中添加新的功能或修复Bug，会让开发者难逃脱发的噩运。

> Don't Code in isolation

孤立非常危险，不要让开发人员完全孤立地编写代码。如果团队成员花些时间阅读其他同事写的代码，他们就能确保代码是可读和可理解的，并且不会随意打补丁的代码。实行**代码评审**，不仅有助于代码更好理解，而且是发现bug最有效的方法之一。

> Use unit tests

另一种防止代码难懂的重要技术就是**单元测试**。单元测试帮助你很自然地把代码分层，分成很多可管理的小块，这样就会得到设计更好、更清晰的代码。更深入项目的时候，你可以直接阅读单元测试——它们是一种可执行的文档。有了单元测试，你会看到更小、更易于理解的代码模块，运行和使用代码，能够帮助你彻底理解这些代码。

> 天使：“不要坠入快速的简单修复之中。要投入时间和精力保持代码的整洁、敞亮。”

### 切身感受 ###

*  在项目中，代码应该是很亮堂的，不应该由黑暗死角。
 *  你也许不知道每块代码的每个细节，或者每个算法的每个步骤，但是你对整体的相关知识有很好的了解。
 *  没有任何一块代码被警戒线或者“切勿入内”的标志隔离开。

### 平衡的艺术 ###

*  你必须要理解一块代码是如何工作的，但是不一定需要成为一位专家。只要你能使用它进行有效的工作就足够了，不需要把它当作毕生事业。
 *  如果有一位团队成员宣布，有一块代码其他人都很难看懂，这就意味着任何人（包括原作者）都很难维护它。请让它变得简单些。
 *  不要急于修复一段没能真正理解的代码。这种补丁的病症始于无形，但是很快就会让代码一团糟。要解决真正的问题，不要治标不治本。
 *  所有的大型系统都非常复杂，因此没有一个人能完全明白所有的代码。除了深入了解你正在开发的那部分代码之外，你还需要从更高的层面来了解大部分代码的功能，这样就可以理解系统各个功能块之间是如何交互的。
 *  如果系统的代码已经恶化，可以参考**排除万难，奋勇前进**一章

## 对事不对人 ##

> 恶魔：“你在这个设计上投入了很多精力，为它付出很多心血。你坚信它比其他任何人的设计都棒。别听他们的，他们只会把问题变得更糟糕。”

你很可能见过，对方案设计的讨论失控变成了情绪化的指责——做决定是基于谁提出了这个观点，而不是权衡观点本身的利弊。我们来看看对一个明显的错误有哪些常见的反应。

*  否定个人能力。
 *  指出明显的缺点，并否定其观点。
 *  询问你的队友，并提出你的顾虑。

第一种方法是不可能成功的。你那样指出问题根本不会对他的水平有任何提高，反而会导致他以后再也不会提出自己的任何想法了。第二种方法至少观点明确，但也不会给多少帮助，甚至遭来反驳导致被打脸。而第三种方法，没有谴责，没有评判，只是简单地表达自己的观点。

在一个需要紧密合作的开发团队中，如果能稍加注意礼貌对待他人，将会有益于整个团队关注真正有价值的问题，而不是勾心斗角，误入歧途。我们每个人都能有一些极好的创新想法，同样也会萌生一些很愚蠢的想法。

> Negativity kills innovation

负面的评论和态度扼杀了创新。我们每个人都会有好的想法，也会有不对的想法，团队中的每个人都需要自由地表达观点。即使你的建议不被全盘接受，也能对最终解决问题有所帮助。不要害怕受到批评。记住，任何一个专家都是从这里开始的。

> 你不需要很出色才能起步，但是你必须起步才能变得很出色。

**集体决策**确实非常有效，但也有一些最好的创新源于很有见地的个人的独立思考。如果你是一个有远见的人，就一定要特别尊重别人的意见。我们并不是建议你限制会议决策，只是你不应该成为一意孤行的首席架构师的傀儡。

> 能欣赏自己并不接受的想法，表明你的头脑足够有学识。

下面是一些有效的特殊技术：

*  **设定最终期限**：如果你正在参加设计方案讨论会，或者是寻找解决方案时遇到问题，请设定一个明确的最终期限，这样的时间限制可以防止人们陷入无休止的理论争辩之中，保证团队工作的顺利进行。同时应该现实一点：没有最好的答案，只有更合适的方案。设定期限能够帮你在为难的时候果断做出决策，让工作可以继续进行。
 *  **逆向思维**：团队中的每个成员都应该意识到权衡的必要性。一种客观对待问题的办法是：先是积极地看到它的正面。然后再努力地从反面去认识它。目的是要找出优点最多缺点最少的那个方案，而这个好办法可以尽可能地发现其优缺点，这也有助于少带个人感情。
 *  **设立仲裁人**：在会议的开始，选择一个仲裁人作为本次会议的决策者。每个人都要有机会针对问题畅所欲言。仲裁人的责任就是确保每个人都有发言的机会，并维持会议的正常进行。仲裁人可以防止明星员工操纵会议，并及时打断假大空式发言。如果你自己没有积极参与这次讨论活动，那么最好退一步做会议的监督者。仲裁人应该专注于调停，而不是发表自己的观点（理想情况下不应在整个项目中有既得利益）。当然这项任务不需要严格的技术技能，需要的是和他人打交道的能力。
 *  **支持已经做出的决定**：一旦方案被确定了，每个团队成员都必须通力合作，努力实现这个方案。每个人都要时刻记住，我们的目标是让项目陈工满足用户需求。客户并不关心这是谁的主意——他们关心的是，这个软件是否可以工作，并且是否符合他们的期望。结果最重要。设计充满了妥协（生活本身也是如此），成功属于意识到这一点的团队。工作中不感情用事是需要克制力的。

> 天使：“对事不对人。让我们骄傲的应该是解决了问题，而不是比较谁的主意更好。”

### 切身感受 ###

*  一个团队能够很公正地讨论一些方案的优点和缺点
 *  你不会因为拒绝了有太多却显得方案而伤害别人
 *  也不会因为采纳了某个不甚完美（但是更好的）解决的方案而被人忌恨

### 平衡的艺术 ###

*  尽力贡献自己的好想法，如果你的想法没有被采纳也无需生气。不要因为只是想体现自己的想法而对拟定的好思路画蛇添足。
 *  脱离实际的反方观点会使争论变味。若对一个想法有成见，你很容易提出一堆不太可能发生或不太实际的情形去批驳它。这时，请先扪心自问：类似问题以前发生过吗？是否经常发生？
 *  也就是说，你必须评判那些场景发生的可能性有多大。想要支持或者反驳一个观点，有时候你必须先做一个原型或者调查出它有多少的同意者或反对者。
 *  在开始寻找最好的解决方案之前，大家对“最好”的含义要先达成共识。在开发者眼中的最好，不一定就是用户认为最好的，反之亦然。
 *  只有更好，没有最好。尽管“最佳实践”这个术语到处在用，但实际上不存在“最佳”，只有在某个特定条件下更好的实践。
 *  不带个人情绪并不是要盲目地接受所有的观点。用合适的词和理由去解释为什么你不赞同这个观点或方案，并提出明确的问题。

## 排除万难，奋勇前进 ##

> 恶魔：“如果你发现其他人的代码有问题，只要你自己心里知道就可以了。毕竟，你不想伤害它们，或者惹来麻烦。如果他说你的老板，更要格外谨慎，只要按照他的命令执行就可以了。”

假如要你修复其他人编写的代码，而代码很难理解也不好使用。你说应该继续修复工作，保留这些脏乱的代码呢，还是应该告诉你的老板，这些代码太烂了，应该统统扔掉呢？

也许你会跳起来告诉周围的人，那些代码说多么糟糕，但那只是抱怨和发泄，并不能解决问题。相反，你应该重写这些代码，并比较重写前后的优缺点。动手证明（不要只是嚷嚷）最有效的方式，是把糟糕的代码放到一边，立刻重写。列出重写的理解，会有助于你的老板（以及同事）认清当前形势，帮助他们得到正确的解决方案。

当发现问题时，不要试图掩盖这些问题。而要有勇气站起来，说：“我现在知道了，我过去使用的方法不对。我想到了一些方法，可以解决这个问题——如果你有更好的想法，我也很乐意听一听——但可能会花多些时间。”你已经把所有对问题的负面情绪哦爱猪脑后，你的意图很清楚，就是寻找解决方案。既然你提出大家努力来解决问题，那就不会有任何争辩的余地。这样会促进大家去解决问题。也许，他们就会主动走近，提供帮助。更重要的是，这显示出了你的真诚和勇气，同事你也赢得了他们的信任。

> 天使：“做正确的事。要诚实，要有勇气去说出实情。有时，这样做很困难，所以我们要求足够的勇气。”

### 切身感受 ###

*  勇气会让人觉得有点不自在，提前鼓足勇气更需要魄力
 *  但有些时候，它是扫除障碍的唯一途径，否则问题就会进一步恶化下去。
 *  鼓起勇气，能让你从恐惧中解脱出来
    
    ### 平衡的艺术 ###
 *  如果你说天快要塌下来了，但其他团队成员都不赞同。反思一下，也许你说正确的，但你没有解释清楚自己的理由。
 *  如果你说天快要塌下来了，但其他团队成员都不赞同。考虑一下，他们也许是对的。
 *  如果设计或代码中出现了奇怪的问题，花时间去理解为什么代码会是这样的。如果你找到了解决方法，但代码仍然令人费解，唯一的解决办法是重构代码，让它可读性更强。如果你没有马上理解那段代码，不要轻易地否定和重写它们。那不是勇气，而是鲁莽。
 *  当你勇敢的站出来时，如果受到了缺乏背景知识的抉择者的地址，你需要用他们能够听懂的话语表达。“更清晰的代码”是无法打动生意人的。节约资金、获得更好的投资回报，避免诉讼以及增加用户利益，会让论点更有说服力。
 *  如果你在压力下要对代码质量作出妥协，你可以指出，作为一名开发者，你没有职权毁坏公司的资产（所有代码）。

转载于:https://www.cnblogs.com/fr-ruiyang/p/11380360.html