敏捷的协作

缺乏、安全感 2023-08-17 17:38 54阅读 0赞

# 敏捷协作 #

## 定期安排会面时间 ##

也许你个人很讨厌开会，但是沟通是项目成功的关键。我们不只要跟客户谈话，还应该与其他开发人员进行良好的沟通。

立会（站着开的会议）是将团队召集在一起，并让每个人了解当下进展状况的好办法。顾名思义，参与者们不允许在立会中就做，这可以保证会议快速进行。一个人坐下来之后，会由于感到舒适而让会议持续更长的时间。

要保证会议议题不会发散，每个人都应该只回答下述三个问题：

*  昨天有什么收获？
 *  今天计划要做哪些工作？
 *  面临着哪些障碍？

只能给予每个参与者很少的发言时间（大约2分钟）。也许要用计时器来帮助某些收不住话头的人。如果要详细讨论某些问题，可以在立会结束之后，再召集相关人员。

通常，立会都是在每个工作日的早些时候，且大家都在上班时举行。但是不要把它安排为上班后的第一件事。要让大家有机会从刚才混乱的交通状况中回复状态，喝点咖啡，删除一些垃圾邮件什么的。要保证会议结束后又足够的时间，让大家在午餐之前做不少工作，同时也不要开始得过早，让每个人巴不得赶紧结束会议，去喝点东西。一般来说，在大家到公司之后的半个小时到一个小时之内举行，是个不错的选择。

参与会议的人要遵守一些规则，以保证彼此不会分神，而且会议也不会跑题。这些规则有：

*  只有团队成员可以发言。他们必须回答上面的3个问题，而且不能展开深入讨论。
 *  管理层可以把要解决的问题记下来，但是不能试图将会议从每个人要回答的三个问题引开。

每日立会有诸多好处：

*  让大家尽快投入到一天的工作中来。
 *  如果某个开发人员在某一点上有问题，他可以趁此机会将问题公开，并积极寻求帮助。
 *  帮助团队带头人或管理层了解哪些领域需要更多的帮助，并重新分配人手。
 *  让团队成员知道项目其他部分的进展情况。
 *  帮助团队识别是否在某些东西上有重复劳动而耗费了精力，或者是不是某个问题有人已有现成的解决方案。
 *  通过促进代码和思路的共享，来提升开发速度。
 *  鼓励向前的动力：看到别人报告的进度都在前进，会对彼此形成激励。

### 具体技巧 ###

*  会议会占用开发时间，所以要尽量保证投入的时间有较大的产出。立会的时间最长不能超过30分钟，10~15分钟比较理想。
 *  如果要使用需提前预定的会议室，就把预定的时间设定为1小时吧。这样就有机会在15分钟的立会结束后，马上召开更小规模的会议。
 *  虽然大多数团队需要每天都碰头，但对于小型团队来说，这样做可能有点过头了。不妨两天举行一次，或者一周两次，这对小团队来说足够了。
 *  要注意报告的细节。在会议中要给出具体的进度，但是不要陷入细节之中。
 *  迅速地开始可以保证会议短小。不要浪费时间等着会议开始。
 *  如果觉得立会是在浪费时间，那可能是大家还没有形成真正的团队意识。这并不是坏事，有利于针对问题进行改进。

## 架构师必须写代码 ##

架构师应该负责设计和指导。作为架构师，不应该只是画一些看起来很漂亮的设计图，说一些像黑话一样的词汇，使用一大堆设计模式——这样的设计通常不会有效的。

一个设计要解决的是眼前面临的特定问题，随着设计的实现，对问题的理解也会发生改变。想在开始实现之前，就做出一个很有效的详细设计是非常困难的。因为没有足够的上下文，能得到的反馈页很少，甚至没有。设计会随着时间而演进，如果忽略了应用的现状，要想设计一个新的功能，或者完成某个功能的提升是不可能的。

作为设计人员，如果不能理解系统的具体细节，就不可能做出有效的设计。只通过一些高度高阔的、粗略的设计图无法很好地理解系统。

> 可逆性
> 
> 不存在所谓的最终决策。没有哪个决策做出之后就是板上钉钉了。实际上，就时间性来看，不妨把每个重要的决策，都看作是在变化之前所做出的预先规划。

好的设计者必须能够卷起袖子，加入开发队伍，毫不犹豫地参与实际编程。

要鼓励程序员参与设计。主力程序员应该试着担任架构师的角色，而且可以从事多种不同的角色。它会负责解决设计上的问题，同时也不会放弃编码的工作。程序员在拒绝设计的同时，也就放弃了思考。

### 具体技巧 ###

*  如果有一位首席架构师，他可能没有足够的时间来参与编码工作。还是要让他参与，但是别让他开发在项目关键路径上的、工作量最大的代码。
 *  不要允许任何人单独进行设计，特别是你自己。

## 实行代码集体所有制 ##

任何具备一定规模的应用，都需要多人协作进行开发。在这种状况下，不应该像国家宣称对领土的所有权一样，声明个人对代码的所有权。任何一位团队成员，只要理解某段代码的来龙去脉，就应该可以对其进行处理。如果某一段代码只有一位开发人员能够处理，项目的风险无形中也就增加了。

相比找出谁的主意最好、谁的代码实现很烂而言，解决问题，并让应用满足用户的期望要更为重要。

当多人同时开发时，代码会被频繁地检查、重构以及维护。如果需要修复bug，任何一名开发人员都可以完成这项工作。同时有两个或两个以上的人，可以处理应用中不同部分的代码，可以让项目的日程安排也变得更为容易。

在团队中实行任务轮换制，让每个成员都可以接触到不同部分的代码，可以提升团队整体的知识和专业技能。当Joe接过Sally的代码，他可以对其进行重构，消除待处理的问题。在试图理解代码的时候，他会问些有用的问题，今早开始对问题领域的深入理解。

另一方面，知道别人将会接过自己的代码，就意味着自己要更守规矩。当知道别人在注意时，一定会更加小心。

可能有人会说，如果一个开发者专门应对某一领域中的任务，他就可以精通该领域，并让后续的开发任务更加高效。这没错，但是眼光放长远一点，有好几双眼睛盯着某一段代码，是一定可以带来好处的。这样可以提升代码的整体质量，使其易于维护和理解，并降低出错率。

### 具体技巧 ###

*  不要无意间丧失了团队的专家技能。如果某个开发人员在某个领域中机器精通，不妨让他作为这方面的驻留专家，而且系统的其他部分代码也对他开放，这样对团队和项目都很有帮助。
 *  在大型项目中，如果每个人都可以随意改变任何代码，一定会把项目弄得一团糟。代码集体所有制并不意味着可以随心所欲、到处破坏。
 *  开发人员不必了解项目每一部分的每个细节，但是也不能因为要处理某个模块的代码而感到惊恐。
 *  有些场合是不能采用代码集体所有制的。也许代码需要某些特定的知识、对特定领域的了解，比如一个高难度的实时控制系统。这些时候，人多了反而容易误事。
 *  任何人都可能遭遇到诸如车祸等突发的灾难事故，或者有可能被竞争对手雇佣。如果不向整个团队分享知识，反而增加了丧失知识的风险。

## 成为指导者 ##

> 教学相长  
> Knowledge grows when given.

与团队其他人一起共事是很好的学习机会。知识有一些很独特的属性；假设你给别人钱的话，最后你的钱会变少，而他们的财富会增多。但如果是去教育别人，那双方都可以得到更多的知识。

通过详细解释自己知道的东西，可以使自己的理解更深入。当别人提出问题时，也可以发现不同的角度。也许可以发现一些新技巧——听到一个声音这样告诉自己：“我以前还没有这样思考过这个问题。”

与别人共事，激励他们变得更出色，同时可以提升团队的整体实力。遇到无法回答的问题时，说明这个领域的知识还不够完善，需要在这方面进一步增强。好的指导者在为他人提供建议时会做笔记。如果遇到需要花时间进一步观察和思考的问题，不妨先草草记录下来。此后将这些笔记加入到每日日志中。

成为指导者，并不意味着要手把手教团队成员怎么做，也不是说要在白板前进行讲座，或是开展小测验说明的，可以在进行自备午餐会时展开讨论。多数时候，成为指导者，是指在帮助团队成员提升水平的同时也提高自己。

这个过程不必局限于自己的团队。可以开设个人博客，贴一些代码和技术在上面。不一定是多么伟大的项目，即使是一小段代码和解释，对别人也可能是有帮助的。

成为指导者意味着要分享——而不是固守——自己的知识、经验和体会。意味着要对别人的所学和工作感兴趣，同时愿意为团队增加价值。一切都是为了提高队友和你的能力与水平，而不是为了毁掉团队。

### 具体技巧 ###

*  如果一直在就同一个主题向不通过的人反复阐述，不妨记录笔记，此后就此主题写一篇文章，甚至是一本书。
 *  成为指导者是向团队进行投资的一种极佳的方式。
 *  结对编程是一种进行高效指导的、很自然的环境。
 *  如果总是被一些懒于自己寻找答案的人打扰。
 *  为团队成员在寻求帮助之前陷入某个问题的时间设定一个时限，一个小时应该是不错的选择。

## 允许大家自己想办法 ##

“授人以鱼，三餐之需；授人以渔，终生之用。”告诉团队成员解决问题的方法，页要让他们知道如何解决问题的思路，这也是成为指导者的一部分。

了解上个实践——成为指导者——之后，也许有人会倾向于直接给同事一个答案，以继续完成工作任务。要是只提供一些指引给他们，让他们自己想办法找到答案，这并不是多么麻烦的事情。这样做有下面几点好处：

*  你在帮助他们学会如何解决问题。
 *  除了答案之外，他们可以学到更多东西。
 *  他们不会再就类似的问题反复问你。
 *  这样做，可以帮助他们在你不能回答问题时自己想办法。
 *  他们可能想出你没有考虑到的解决方法或主意。这是最有趣的——你也可以学到新东西。

如果有人还是没有任何线索，那就给更多提示吧（或者甚至是答案）。如果有人提出来某些想法，不妨帮他们分析每种想法的优劣之处。如果有人给出的答案或解决方法更好，那就从中汲取经验，然后分享你的体会吧。这对双方来说都是极佳的学习经验。

### 具体技巧 ###

*  用问题回答问题，可以引导提问的人走上正确的道路。
 *  如果有人真的陷入胶着状态，就不要折磨他们了。告诉他们答案，再解释为什么是这样。

## 准备好后再共享代码 ##

相对不使用版本控制系统，更坏的状况是什么？答案是：错误地使用了版本控制系统。使用版本控制系统的方式，会影响生产力、产品稳定性、产品质量和开发日程。特别地，诸如代码提交频率这样简单的东西都会有很大影响。

完成一项任务后，应该马上提交代码，不应该让代码在开发及其上多停留一分钟。如果代码不能被别人集成使用，那又有什么用处呢？应该赶紧发布出去，并开始收集反馈。

另一方面，如果在任务完成之前就提交代码，会带来很多风险。这些代码可能还有编译错误，或者对其所做的某些变化与系统其它部分的代码不兼容。当其它开发者获取最新版本的代码时，也会受到这些代码的影响。

通常情况下，提交的文件应该与一个特定的任务或是一个bug的解决相关。而且应该是同时提交相关的文件，并注有日志信息，将来页能够知道修改了哪些地方，以及为什么要做修改。一旦需要对变更采取回滚操作，这种“原子”提交也是有帮助的。

要保证在提交代码之前，所有的单元测试都是可以通过的。使用持续集成是保证源代码控制系统中代码没有问题的一种良好方式。

> 代码不执行提交操作的其他安全选择
> 
>  *  使用远程访问
>  *  随身携带：U盘
>  *  使用有带底座扩展的笔记本电脑：解决多台电脑上开发造成的延续性问题
>  *  使用源代码控制系统的特性：分支与合并。可以将代码分为主干和开发者分支。

### 具体技巧 ###

*  有些源代码控制系统会区分“提交”和“可公开访问”两种代码权限。此时，完全可以进行临时的提交操作。（VS中TFS的搁置集？）
 *  有些人希望代码在提交之前可以进行复查操作。只要不会过久拖延提交代码的时间就没有问题。如果流程的某个部分产生了拖延，那就修正流程吧。
 *  仍然应该频繁提交代码。不能用“代码尚未完成”作为避免提交代码的借口。（至少在开发分支上是如此。）

## 做代码复查 ##

代码刚刚完成时，是寻找问题的最佳时机。如果放任不管，它也不会变得更好。

> 代码复查和缺陷移除
> 
> 要寻找深藏不露的程序bug，正式地进行代码检查，其效果是任何已知形式测试的两倍，而且是移除80%缺陷的唯一已知方法。

管理层担心进行代码复查所耗费的时间。他们不希望团队停止编码，而去参加长时间的代码复查会议。开发人员对代码复查感到担心，允许别人看他们的代码，会让他们有受威胁的感觉。

通过严格的代码复查过程，可以提交质量极高而且稳定的代码。当开发人员完成某项任务的编码和测试后，在签入源代码控制系统之前，会有另一名开发人员对代码做彻底的复查。这个过程修复了很多问题，代码复查不只针对初级开发者编写的代码——团队中每个开发人员的代码都应该进行复查，无论其经验丰富与否。

那该如何进行代码复查呢？

*  通宵复查：不太敏捷，不建议这种方式。
 *  捡拾游戏：当某些代码编写完成、通过编译、完成测试，并准备签入时，其他开发人员就可以捡拾起这些代码开始复查。是一种快速而非正式的方式，保证代码在提交之前是可以被接受的。为了消除行为上的惯性，要在开发人员之间进行轮换。
 *  结对编程：在极限编程中，不存在一个人独立进行编码的情况，编程总是成对进行的。

在代码复查中要看什么呢？

*  代码能否被读懂和理解？
 *  是否有任何明显的错误？
 *  代码是否会对应用的其他部分产生不良影响？
 *  是否存在重复的代码？
 *  是否存在可以改进或重构的部分？

此外，还可以考虑使用代码分析工具。如果这些工具产生的静态分析结果对项目有帮助，就把他们集成到持续构建中去吧。

### 具体技巧 ###

*  不进行思考、类似于橡皮图章一样的代码复审没有任何价值。
 *  代码复查需要积极评估代码的设计和清晰程度，而不只是考量变量名和代码格式是否符合组织的标准。
 *  同样的功能，不同开发人员的代码实现可能不同。差异并不意味着不好。除非你可以让某段代码明确变得更好，否则不要随意批评别人的代码。
 *  如果不及时跟进讨论中给的建议，代码复查是没有任何实际价值的。可安排跟进会议，或者使用代码标记系统，来标识需要完成的工作，跟踪已经处理完的部分。
 *  要确保代码复查参与人员得到每次复查活动的反馈。作为结果，要让每个人知道复查完成后所采取的行动。

## 及时通报进展与问题 ##

接受一个任务，页就意味着做出了要准时交付的承诺。不过，遇到各种问题从而导致延迟，这种情形并不少见。截止日期来临，大家都等着你在演示会议上展示工作成果。如果你到会后通知大家工作还没有完成，会有什么后果？除了感到窘迫，这对你的事业发展也没有什么好处。

如果等到截止时间才发布坏消息，就等于是为经理和技术主管提供了对你进行微观管理的机会。他们会担心你再次让他们失望，并开始每天多次检查你的工作进度。

假定现在你手上有一个进行了一半的任务，由于技术上的难题，看起来不能准时完成了。如果这时积极通知其他相关各方，就等于给机会让他们提前找出解决问题的方案。也许他们可以向另外的开发人员寻求帮助，也许他们可以将工作重新分配给更加熟悉相关技术的人，也许他们可以提供更多需要的资源，或者调整目前这个迭代中要完成的工作范围。客户会愿意将这个任务用其他同等重要的任务进行交换的。

及时通报进展与问题，有情况发生时，就不会让别人感到突然，而且他们也很愿意了解目前的进展状况。他们会知道何时应该提供帮助，而且你也获得了他们的信任。

发送电子邮件，用即时贴传递信息，或快速电话通知，这都是通报大家的传统方式。还可以使用“信息辐射器”，类似于墙体上的海报，提供变更的信息，路人可以很方便地了解其中的内容。以推送的方式（海报、网站、Wiki、博客或者RSS Feed）传递信息，他们就不必再来问问题了。只要让人们可以有规律地查看到需要的信息，这就可以了。

整个团队可以使用信息辐射器来发布他们的状态、代码设计、研究出的好点子等内容。现在只要绕着团队的工作区走一圈，就可以学到不少新东西，而且管理层也就可以知道目前的状况如何了。

### 具体技巧 ###

*  每日立会可以让每个人都能明确了解最新的进展和形势。
 *  在展示进度状况时，要照顾到受众关注的细节程度。比如，领导是不会关心一些实现细节的。
 *  别花费太多时间在进展与问题通报上面，还是应该保证开发任务的顺利完成。
 *  经常抬头看看四周，而不是只埋头于自己的工作。

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