【心得体悟】浅谈带团队心得 - 挑战篇
人生总有高潮和低谷，团队也是这样，有的时候表现好，有的时候表现欠佳。在带队的过程中，我遇到了一系列的挑战。
进度慢
在一个 Sprint 两周的时间内，我给开发人员 Bob （化名）总共安排了三个活 A， B， C。根据以往的表现和能力， Bob 应该能够完成这些东西，并且还有一些富余。
但是在实际的开发过程中， Bob 在 task A 和 task B 上花了过分多的时间，导致最终来不及做 task C 。并且，这已经不是 Bob 第一次没有按时交付了。
为了解决问题，首先，我私下和 Bob 沟通，委婉地谈到了进度慢的问题，想要确认是不是最近有一些烦心事，导致他效率低下，得到了否定的回答。
其次，我和他认真分析了一下 task A 和 task B ，难点痛点在哪，为什么需要花额外的时间解决。有没有什么我可以帮忙的地方。
经过这些，他意识到了最近自己的变化，然后及时地调整状态，在接下来的几个开发周期内慢慢恢复了效率。
糟糕的实现
我给开发人员 Alice （化名）分了一个活，是对项目 A 做一些 refactoring ，然后将其中通用的一些 utils 方法移动到一个单独的 utils project B 中。
Project A -> (UTILS) -> Project B
到了 code review 阶段一看，我傻眼了，因为 utils_a 使用了 project A 中的 POJO ，所以她原封不动地把 project A 作为依赖引入到 utils project B 中。
Project A <- Project B / (UTILS)
这是一个糟糕的实现，因为虽然从结果上看，它达到了预期的要求。但是，这种实现方式和我们的设计理念背道而驰。
这个需求的背后的设计理念是：
- 将各个 App 模块的共用的方法，剥离出来，单独做一个 utils 模块。
- 各个 App 模块之间是独立的，互相没有依赖。
- utils 模块也应当尽可能地独立，不依赖 App 模块。
我把反馈信息告诉 Alice 之后，很快，她就做出了相应地修改。
经过这次，以后任务分配时，我还会和他们讨论与分享背后的设计思想。因为只有理解了原理，做出来的东西才会更好。
过于细节的需求描述
紧接上一个话题，有时候，为了快速地完成开发，我在写任务描述的时候，会过于具体。比如：在 class_a 中修改 method_b ，删改 xxx 内容。
有三个坏处：
- 过于 technical ，导致测试和验收起来困难。难道是让 QA 去检查 code 看这一行改了没有吗？
- 如果有后续其它修改，需要重新分析。
- 不利于培养组员自己分析和解决问题的能力。
所以，我知道，写 user story 也是有讲究的，需要结果导向，而不是 实现/代码 导向。
如上例，我可以这么写，当用户做 操作a 的时候，目前他能得到 结果b ，经过修改，他应该能得到 结果c 。
争论与否决
很多时候，争论不可避免，特别是当组内成员来自世界各地的时候。
我给开发人员 Charles （化名）安排了一个活，是写一个脚本，支持在服务器端零活地修改所有项目的配置文件。使用场景是，原先，所有项目连接到了 DB_01 ，使用脚本可以将其修改为 DB_02 。
Charles 做出来了一个版本，但是，使用上有一点缺陷，用户需要知道并传入参数 DB_01 。从开发的角度，这样实现可能是最快最简便的。
但是，从用户的角度来说，用户其实不关心原先的 DB 名称，他只关心最终想要的 DB 名称，所以 DB_01 不应该作为一个参数。
当有分歧的时候，不免就有争论，而这个时候 team lead 需要站在全局，充分考虑两边的意见，给出优劣势分析，然后最终拍板。
可能最终的决定会一定程度上否定某一方的意见，这个时候就需要单独再沟通安抚。
总结
遇到困难不要怕，迎难而上，遇山开山，遇水搭桥。而遇到"人"的问题时，不要怕麻烦，多沟通。
