敏捷的协做

敏捷协做

按期安排会面时间

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

立会（站着开的会议）是将团队召集在一块儿，并让每一个人了解当下进展情况的好办法。顾名思义，参与者们不容许在立会中就作，这能够保证会议快速进行。一我的坐下来以后，会因为感到温馨而让会议持续更长的时间。

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

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

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

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

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

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

每日立会有诸多好处：

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

具体技巧

• 会议会占用开发时间，因此要尽可能保证投入的时间有较大的产出。立会的时间最长不能超过30分钟，10~15分钟比较理想。
• 若是要使用需提早预约的会议室，就把预约的时间设定为1小时吧。这样就有机会在15分钟的立会结束后，立刻召开更小规模的会议。
• 虽然大多数团队须要天天都碰头，但对于小型团队来讲，这样作可能有点过头了。不妨两天举行一次，或者一周两次，这对小团队来讲足够了。
• 要注意报告的细节。在会议中要给出具体的进度，可是不要陷入细节之中。
• 迅速地开始能够保证会议短小。不要浪费时间等着会议开始。
• 若是以为立会是在浪费时间，那多是你们尚未造成真正的团队意识。这并非坏事，有利于针对问题进行改进。

架构师必须写代码

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

一个设计要解决的是眼前面临的特定问题，随着设计的实现，对问题的理解也会发生改变。想在开始实现以前，就作出一个颇有效的详细设计是很是困难的。由于没有足够的上下文，能获得的反馈页不多，甚至没有。设计会随着时间而演进，若是忽略了应用的现状，要想设计一个新的功能，或者完成某个功能的提高是不可能的。

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

可逆性

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

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

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

具体技巧

• 若是有一位首席架构师，他可能没有足够的时间来参与编码工做。仍是要让他参与，可是别让他开发在项目关键路径上的、工做量最大的代码。
• 不要容许任何人单独进行设计，特别是你本身。

实行代码集体全部制

任何具有必定规模的应用，都须要多人协做进行开发。在这种情况下，不该该像国家宣称对领土的全部权同样，声明我的对代码的全部权。任何一位团队成员，只要理解某段代码的前因后果，就应该能够对其进行处理。若是某一段代码只有一位开发人员可以处理，项目的风险无形中也就增长了。

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

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

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

另外一方面，知作别人将会接过本身的代码，就意味着本身要更守规矩。当知作别人在注意时，必定会更加当心。

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

具体技巧

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

成为指导者

教学相长
Knowledge grows when given.

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

经过详细解释本身知道的东西，可使本身的理解更深刻。当别人提出问题时，也能够发现不一样的角度。也许能够发现一些新技巧——听到一个声音这样告诉本身：“我之前尚未这样思考过这个问题。”

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

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

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

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

具体技巧

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

容许你们本身想办法

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

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

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

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

具体技巧

• 用问题回答问题，能够引导提问的人走上正确的道路。
• 若是有人真的陷入胶着状态，就不要折磨他们了。告诉他们答案，再解释为何是这样。

准备好后再共享代码

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

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

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

一般状况下，提交的文件应该与一个特定的任务或是一个bug的解决相关。并且应该是同时提交相关的文件，并注有日志信息，未来页可以知道修改了哪些地方，以及为何要作修改。一旦须要对变动采起回滚操做，这种“原子”提交也是有帮助的。

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

代码不执行提交操做的其余安全选择

• 使用远程访问
• 随身携带：U盘
• 使用有带底座扩展的笔记本电脑：解决多台电脑上开发形成的延续性问题
• 使用源代码控制系统的特性：分支与合并。能够将代码分为主干和开发者分支。

具体技巧

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

作代码复查

代码刚刚完成时，是寻找问题的最佳时机。若是听任无论，它也不会变得更好。

代码复查和缺陷移除

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

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

经过严格的代码复查过程，能够提交质量极高并且稳定的代码。当开发人员完成某项任务的编码和测试后，在签入源代码控制系统以前，会有另外一名开发人员对代码作完全的复查。这个过程修复了不少问题，代码复查不仅针对初级开发者编写的代码——团队中每一个开发人员的代码都应该进行复查，不管其经验丰富与否。

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

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

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

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

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

具体技巧

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

及时通报进展与问题

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

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

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

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

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

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

具体技巧

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