探索技术管理与敏捷管理的一年：到底如何做技术管理和敏捷管理？

2017-01-17 23:08:00

回想2016年初，至今还诚惶诚恐。在那时，Android应用开发团队还一团乱麻，时常有紧急问题发生，在那时，敏捷开发还在蹒跚学步。好在，一年过去了，我们也走出来了，没有原地踏步。

1.如何学做管理

其实，我很不想用“管理”二字，但是用一个新的词语，又未免增加了理解的成本。为什么不想用“管理”二字呢？因为，提到这个词语，我总是会很肤浅的联想到“流程”、“控制”、“绩效”、“计划”、”组织开会“这些工作。然而，我每天跟在团队后面，不断的督促他们完成任务就是管理了吗？这件事情有意义吗，我做这件事能产生多少价值？做这些事情有利于我个人的职业发展吗？这些问题，在开始之初时常在我脑海中荡漾，久久不能平静。

回到原点，公司把我安排在这个位置上，最现实的，也是最基本的，是保障这个领域能高质高效的配合产品项目的研发工作。那么，还管他管理的定义是什么，带领一帮人，达成这个目标，就是管理。是的，我就是这样一个现实主义者。于是乎，所有的管理工作，都将围绕着这个目标去探索，去开展。

在这项工作的开展过程中，有两个人的话影响着我，其中包括：“你自己写程序都能干得那么好，为什么人到你手下后，就不行了呢？“，”现在你们的管理知识，就和小学的数学水平一样。“，”管理是一门实践的艺术。“，在此，不得不感谢这两位导师，促进了我在这一领域的发展。个人的拙见，学做管理要重点关注以下三件事情：

1.培养你的团队成员，目标就是让他们和你一样强，甚至比你还强。

有时，我们会担心团队成员变得比我都还强，那我的位置不是会被他取代？公司还要我干嘛？个人的拙见，这是一个伪命题，这里仅仅是目标让他们变得更强，但是既然是你去培养他们，他们不可能全面超越你，你们各有所长。另外，作为一名管理者，应该有这样的自信和胸怀，我们自身也在不断学习，我们会走得更远。只有他们都变强了，团队才会变得更强，才能把事情做得更好，我们带领团队的价值才能有所体现。

2.加强管理知识的专业化学习，而不是闭门造车，自己摸索，多看书，看好书，多听有经验人士的讲座。

3.针对公司的特点，团队的特点，不断的尝试、总结、调整你所学到的方式方法，在实践中验证和改进它，变成你自身的经验，深入骨髓。

这种机会难得，很多人没有这样的机会去学习管理。

2.如何做Android应用团队管理

Android应用技术团队，专业知识强，技术细分领域多，人员技术能力参差不齐。面对市场上纷繁众多的机型，移动端让人操蛋的网络复杂性，以及让人恶心到爆的运营商，简直是苦不堪言。苦归苦，事情还得做，而且还得做好，于是今年一年经历了以下三个阶段：

第一阶段：全面重构以前那让人难以启齿的代码。
第二阶段：配合永不停歇的敏捷开发，人员迅速激增。
第三阶段：领域化划分，基本走上正轨。

我对Android应用团队的管理的观念，也随着这三个阶段，不断的演变和进化。在接手团队之初，团队人员仅有5人，那是程序代码格外凌乱，耦合严重，连最基本的代码合并都会经常出问题，线上问题也是时常发生，而且是越演越烈的趋势。由于我个人经验有限，当时也就只看到了这些问题，针对问题解决问题。并且当时有这样的观念，只要我把代码整体重构了，保障代码框架清晰易懂，解耦，Android应用团队就会在框架的引导下越来越好。可惜，我错了，我真的错了！虽然，这样做了后，在很大程度上改善了原有的问题，但是并不彻底。整个团队开始暴露新的问题：

框架约束力不够强，部分开发人员在执行过程中有其形，无其实。
部分开发人员基础知识不过关，框架可管不了这个。
svn管理，jenkins编译，gradle，maven等开发工具链问题不能得到较快、较好的解决。
团队对某些领域的技术研究深度不够，导致问题不能得到有效的解决。
敏捷迭代不断，团队成员忙于迭代，缺乏技术积累，人员工作分配不均，开发效率和质量得不到太好的控制。
人员不断增多，但是却不能较好的发挥他们的价值。
等等

就这样，带着这些问题，我走过了前两个阶段，直到到达第三阶段，才有了质的改变。

总结以上问题，核心还是在于团队能力线问题，所以提高团队能力线，才是以上问题的正解。到这里，正如“如何学做管理”中所说，这个问题要通过培养团队成员来解决，那么问题来了，怎么样培养团队成员呢？我们的Android应用开发团队是一个年轻的团队，一些知识体系都还有待完善和建设，作为团队负责人，我有责任和义务给团队成员指明未来的方向。因此，作为培养的第一步，先明确我们团队需要些什么，他们要做些什么，现在能做些什么？我们先来第一步，组织构建：

组织构建

控制组织大小，4到6人为一个小组织。

我们团队有20人，一个20人的团队，任何思想的传达效率都会比较低，协作成本高，根据我个人的开发经验，4到6人的团队沟通成本低（随便找个空地就能开聊），利于互帮互助。

明确各个小组织的领域范畴和责任。

这个点需要一定的技术背景才能操作，我将Android应用领域拆分为8个领域，包括数据与系统对接、网络与性能、界面与国际化、H5与工具链，每个小组织负责2两个领域的持续跟进研究，以及沉淀。

人员责任包括领域研究和产品开发。

对于人员的要求，所有应用开发人员同样需要负责模块功能的开发，同时要兼顾领域研究，让所有人员既有产品观，全局观（了解应用开发需要的所有技术），同时又有自己的核心领域，做到广而精。

这样才划分带来了很多的好处，各个领域的独立，降低了团队成员的心智负担（操心的事情多），每个人都能一门心思的研究自己的领域，遇到非自己领域问题搞不定时，团队里总能找到能提供帮助的人（有所依靠，哈哈）。一个小组织的成立，我们还可以做弱结对编程、代码审查。因为他们的领域相同，知识体系一样，很容易做到这件事，沟通交流更顺心。

另外，附加的收益，由于领域的独立，紧接着领域的沉淀也逐步加强，各种设计文档也很自然的产生（开发人员不是天生都不喜欢写文档，而是不愿意写没有意义的文档），未来新成员培训也是很有希望做到的。这些好像和团队成员培养没关系？嗯，是的，没有直接关系，但是他们是我进行团队培养的基础，是成员成长必不可少的环境，没有这样的设定，团队培养很难落地执行，接下来开始团队培养：

团队培养

识别团队中的核心成员，给他们合适的权力和责任。

想想，一个班里面，除了老师还有班委。为什么呢？层级太多不是也不怎么好么？如果我能同时兼顾20人的所有细节工作，自然不想再构建新的层级。当我们的关注的事务细化到一个层面后，那么精力就不够了，作为领域团队层面，我们的关注点要细化到代码设计甚至编码级别，一个人能搞定吗？至少我搞不定！那么这和培养有什么关系呢？我对培养的定义不仅仅是指导，还包括培养环境的构建。所以这里做的目的主要有两个。第一，给他们更大的发挥空间，发挥更多的价值（构建带领一个小领域开发的学习环境，现在的开发已经很少能单兵作战了），第二，让他们带我传递我的思想和理念，小团队传递效率更高，深度更深。

各领域持续指导和跟进。

各领域成立后，我的精力主要放在和他们沟通上，让他们明白程序应该怎么设计，这个领域需要做哪些事情，应该怎么做，成员如何组织等，反复不断的沟通、总结、改善，持续的做下去，直到我觉得我们大家的思想是一致的，方式方法没有问题（当然，如果我错了，那么问题就大了，我得保证我没有搞错，或者错了及时改正），这样他们才能有效的指导他们领域的成员，带领他们前进。

领域拉通，成员能力挖掘，查漏补缺。

各小领域成立后，并不代表我就可以做甩手掌柜，除了各领域的培养以外，我还需要拉通各个小领域，促使他们有效的协作，降低他们之间的耦合，减少跨领域的成本。同时，还需要持续不断的关注团队成员的学习进展，给与他们合适的建议，以及符合他当前能力的工作，针对有潜力的成员重点指导，针对有问题的成员及时告诉他的问题，促使他改善。

关注新技术，加强自身对技术的学习，带着团队向前走。

细节有很多，这里谈到了主要方面，个人总结能力还是有限啊，主要只想说一点：核心是为了产品的研发，开展基于培养提升团队成员能力，形成自组织，流程、规范、考核均是辅助措施，能无就无，谨慎对待。

3.如何做敏捷项目管理

敏捷团队是一个全功能团队，里面包含了各个领域的成员，由于公司原本组织架构的一些特点，我们并没有像标准敏捷项目团队那样，有产品经理、敏捷教练等职务，与之对应的是规划与交互，项目负责人。虽然“形”对不上，但是如果能对上“神”，也是不错的。

在敏捷之初，我们并没有理解什么叫迭代，我们傻乎乎的定迭代周期为一周，而且还觉得自己在走敏捷的迭代。可惜我们那不是迭代，我们只是每周计划一下需要开发的工作而已，仅此而已。因而带来了很多问题，前端需求人员不知道功能的开发预期和进展，项目负责人也就是协调协调资源，面对纷繁复杂的功能项开发，也不太情况每个功能的开发进展，当前是否正常（除非非常不正常才能发现）。整个项目组感觉都忙忙碌碌，但是却不知道大家都做了些什么？每天晨会大家说的事情都有点不知所云，感觉晨会都快没有实际意义了。问题太多，以至于我们有点迷失方向。

敏捷，宣称要拥抱变化，我们却粗浅的理解为不需要计划，是不是很白痴。我个人现在对拥抱变化的理解为：“及时交付可体验的产品，随时做好调整的准备，日常的工作任务安排，如果发现不合符预期，需要及时调整，重新评估新的任务，而不是掩耳盗铃，觉得不列一个新任务就会快一点”。好了，临近年底，对于敏捷总算有所顿悟，多亏了《敏捷估算和规划》这本书，给予了我很多启发。接下来，谈谈具体的一些实施细节。

由于我们为了保障版本的按时发布，我们采用了版本火车的形式，所以，我们每个发布版本并没有很强的计划（目前还在纠结改善的地方），而常规的敏捷一般包括三个维度的计划工作，最高维度为版本计划，其次而迭代计划，再次为工作任务。所以，针对我们现有的特点，本文仅讨论到迭代计划及其以下维度层面。那么如何做迭代计划呢？我个人觉得一定要遵循以下原则：

迭代的目标是交付可体验的产品，不是完成任务。

所以，迭代计划里面只能是用户故事及需求，而不是某某人的任务，另外迭代并不是完成开发，还包括视觉、测试的工作。

迭代的周期要合理。

针对不同的产品特点，迭代周期一般为2到4周，如果周期过短，就需要把用户故事的粒度拆分到足够小（不是任何产品都能拆到如此小的粒度），因为我们要在一个迭代周期完成开发、视觉、测试的工作，针对我们的产品特性，我们最终改为3周一次迭代。此外，过短的迭代周期，会议也会增加不少呢，还有一些别的非研发工作损耗。

评估故事点。

从长远考虑，评估故事点有利于团队知道自己的速度，如果哪天上版本计划，有了这项基本数据，能更好，更快，更准确的评估版本开发时间。

故事点是对规模的评估，不是时间的评估。

评估故事点需要一定的技巧，我选择10个用户故事，里面包含各种难度的需求，然后给0.1、1、2、3、5、8、13、20、40、100，然后让他们根据这些用户故事的工作量（包含开发、时间、测试的工作量），然后给这些故事分配对应的值，值得重点说明的是0.1和100，在《敏捷估算和规划》一书中采用了0，代表那些基本可以忽略工作量的故事，避免因个别故事太小导致影响后面的相对值，里面重点说到10个0不等于0，因此我干脆改为0.1，更容易体现出10个0.1是有工作量的，至于100嘛，仅仅是为了标记当前故事无法评估，其实目前我们20和40也没有用到，过大的用户故事不利于跟进。

有了这些以后，还有一些问题会困扰我们，一个迭代安排多少用户故事，每日晨会如何开展？迭代发布会，迭代计划会，故事点评审会这些会议怎么组织，在什么时候组织？我们怎么能准确评估一个迭代的工作量，某个领域任务过多怎么办？啊呀，问题实在是太多了，真是人越多问题越多，我们的敏捷团队有20人，20真的和我有缘啊，同时管理两种类型，两个20人的团队也是一种挑战！目前潜意识认为20人的敏捷团队过大，还没有想到太好的拆分计划，还需要不断的总结分析想办法。

上面的问题我就不都解答了，只是想说明敏捷并不是几项简单的流程，它是一个系统化的解决方案，里面有很多细节，就像我们写软件，设计交互一样。现在回想以前自己做软件时，对项目管理人的哪些肤浅的认识真是惭愧。接下来我要重点说明一下在迭代计划下的任务拆分，当我们计划好本次迭代需要完成的用户故事时，下一步任务就是需要将用户故事拆分成实际领域的工作任务，这种任务我们简直是太熟悉了，例如：完成界面编码。那么在做任务拆分时，有哪些需要遵循的原则呢？

任务需要拆分到1到16小时的工作量。

控制任务的粒度，有利于更快的得到任务的进展和反馈。

告诉团队成员，尽量评估准确任务工作量，但是我们允许任务评估不准确，并且我们也认为任务不可能评估那么准确。

拆分任务的目的不是为了评估某个人的工作量和效率，主要目的是基于任务得到反馈，团队事务透明，以及便于拉通各个领域协作。

当发现任务评估不准确时，及时调整任务时间，或者将原有的任务重新拆分为新的任务，或者新的几个任务。

我们要客观的承认任务的难度，这样有利于团队成员更积极的拆解任务，更真实的评估任务时间，让整个团队得到最真实的反馈。

根据任务计算各领域工时，发现迭代瓶颈。

当所有的故事都拆解成各个领域的任务时，我们可以很轻易的发现瓶颈出下哪个领域，并及时作出对应的调整。

根据剩余的总工时量，绘制迭代耗散图。

每日晨会根据看板的任务流动情况，更新迭代耗散图，让团队成员了解到迭代进展和速度。

不要量化团队成员的个人速度，更多的基于团队去考核和引导。

不要通过量化团队成员的速度来对团队成员进行考核，这样很容易引起团队成员各自为政，并且各种评估不合理，我们需要通过其他手段进行成员评估，引导大家基于团队目标进行行动，共同承担责任。

当我们任务拆解已经完成后，接下来就是每日晨会了，开晨会一般是聊昨天做了什么，遇到什么问题，今天要干什么。在没有做这些计划之前，我觉得早上说这三件事很无趣，很无意义。但是，当我们的迭代这样进行后，说这三件事就很自然了。

昨天做了什么？

用于驱动看板上在doing中的任务，是否要挪动到done中。

遇到什么问题？

根据对应任务遇到的具体问题，促使团队成员了解具体的情况，进行交流。

今天要做什么？

用于驱动看板上在todo中的任务，是否要挪动到doing中。

有了这些细粒度的工作任务，晨会就这样开就可以了，由于晨会流程的标准化，我们可以任意安排团队成员主持晨会，好开心！我可以从这件事中解脱出来，在晨会中更专注的关注项目的进展。在任务安排中，同一个人尽量要控制doing中的任务不超过2项，否则不太好及时得到反馈和跟进。这样的晨会，我能很及时的发现项目中的异常点，及时评估和协调，当我告诉测试你们资源不够时，再也不是那么苍白无力，测试也会很悻然的接受我的建议。