2016年作为项目经理管理了一个40多人的xxxx项目，从需求调研到产品上线、出票历经三个多月。项目实施是一个临时抽调研发、产品、测试的研发团队开展敏捷的项目，为了完成这个项目用了各种能想到的办法（敏捷、看板管理、封闭开发等等），经历各种项目风险，回头来看还是有很多宝贵的经验。

在项目上线后POST-MORTEM问卷中，有研发人员写到：

1研发：我们最大的问题在于变化太快，没有想好的需求就去实现以至于最后返工。

2产品：我们的困难在于沟通，我需要一遍遍的讲解需求才能让研发、测试人员理解。我们甚至在每天的早晨都要过一遍相关的事情。晨会的时候我发现对方压根没理解。

3子项目经理：我们有很大的项目依赖，要实现这个功能，我要修改abcdefg内部各系统。至少三个月改完，并且还需要abcdefg部门配合我修改，并且在我上线前改完：（目前对方没有回复我的邮件）。

4群众：我觉得这个项目不是真正敏捷。

最后一个意见对我的打击比较大，因为这个项目的所有研发经理都参加过项目经理培训。至少在项目共识上是没问题的。为什么研发人员对此过程有这么大的意见？我开始反思敏捷的意义。

形：在敏捷方法中，尚未完成的工作被称为backlog积压工作。如果您开始将工作分配给小交付增量（被称为sprint冲刺），分配给某个冲刺的工作被称为冲刺积压（sprint backlog）。分配给未来冲刺的剩余工作被称为项目积压（projectbacklog）。我们在实施的时候，尽可能将更多的变更分解为合理的backlog，并且安排资源在sprint中去实现这些被人工安排的sprint backlog。对于形来说项目经理只是一个做庖丁解牛的屠夫和烹饪的大师傅。

知其形而不理解其意才会误解自己所做的事情，不是真正的敏捷。实际的意是什么？

意：敏捷概念是将工作拆分成为易于管理的小块。更加容易的去管理这种小块；以及更早地改正错误；更科学的隔离风险。这样可以避免它们稍后在项目中发展成为更大、更难解决的问题。好处之一是能够提供在项目时间表中多个日期进行构建和测试的更小的功能性发布。通过验证分片的交付，每个交付都降低了项目风险。另一个显而易见的好处是应付突如其来的变更，部分变不能影响全局。

经历过痛苦的项目过程后，我开始将敏捷的管理思路投入到实际研发过程管理中。

1实际遇到的管理问题在于第一个管理的面太大，需要切分成块进行管理。合而为之；分而治之。各块需要管理好自己的事情。对于改变世界的程序员来说，dogfooding自己的狗粮自己吃。

2管理方式需要根据团队实际情况，了解同行后发现各个互联网公司全面实行敏捷的并不多。这其中原因很多，主要问题还是资源足够多，对质量要求比较高。另一个实际原因是目前研发团队达不到有一个统管全局的Scrummaster和一个解决所有问题的fire man。我们实际要的是把事情做成，对形式并不在乎。只要能够达到敏捷管理的意，并不需要太重于形。

3需要一步步解决实际问题，不能只看到冰山一角忽视了水下风险。很多事情只是表面问题，闹哄哄的争执，实际并不是提测晚了可能是研发资源不够。如果要是只关注当下不去解决实际问题。可能下次你还会遇到。

对于CI

(continuous integration)来说，敏捷管理、持续集成、自动化测试是最为关键的三部分。重点分享下目前我们的敏捷管理、和自动化测试部分的经验。（以下不涉及技术层面，单列讨论）

1管理手段：告别人工管理进入自动化系统管理。首先是度量，没有度量就没有管理（引用：彼得格鲁克）。如果不知道目前现有的研发水平你会无从下手。第一件事情就是要建立起研发管理体系，将所有研发过程数据进入监控。我们分批次分优先级，经历了半年多将50多个过程指标纳入过程管理。并建立起项目、测试、质量三种维度的报表。

2研发过程的管理次序：优先保证结果，再看过程。我们是先从上线抓起的。做好上线管理加强测试、上线计划和过程的结果，优先做好交付部分。结果保证后，加强过程管理。通过研发管理系统保障，从研发后期的阶段往前推进，做好提测、编码、需求等等各种过程。一步步来，先做好后面一步再往前推进。

3研发过程的层次：研发部分错综复杂，需要分层次管理。长期的优先级高的走项目管理，上线后正常运营的走迭代需求管理。特别高层次的项目需求，安排专人跟踪进入重点项目和总裁需求管理。分层次、不同管理方式将各种品类、研发过程建立起高速、省道、和航线。高速的在天上飞，低速的在地面跑。第一流的团队优先承担高优先级项目，新人多、不成熟的团队先从迭代练起。另一个要讲的就是要有始有终，进入研发管理。就需要从开始到结束，不能做到一半就不管了。所有的项目、需求从开始必须走到结束或者暂停、延期。

4质量管控：

4.1做好了过程，结果自然有；质量并不是测试人员一个角色能够搞定的。从研发过程就有质量意识，做好测试覆盖、上线管理以及线上质量保证。质量管控并不是很难的事情。看你是不是重视质量，投入多少资源去做。

4.2先做好研发质量再看产品质量，通过业务监控，正向的推动产品质量的进一步完善。形成业务、质量的双向正向循环。

4领导力的层次要求：领导力的五个层次至少需要达到第三层贡献。认同和贡献是相辅相成的。认同你所作出的贡献，配合你的工作。这样各种角色才能够互相协作起来，把事情做好。很多人只埋头做事情，并不重视影响力，这也是很多时候工作难以推进的地方！

5自动化测试实践：自动化测试作为工作重点，需要长期的投入。互联网变化快，需要大量的regressiontest。资源却只能刚刚满足feature test,每周几百个变更如何保证质量？显而易见的自动化回归必须做起来，将正确的功能和变更部分隔离开。这里的思路和GIT（配置管理工具）的思路是一致的，知道变更在哪，隔离风险。对于遇到各种疑难杂症的时候常用大绝招不过于重启、回滚和扩容三招，那么自动化测试对于CI来说太关键了。重启、回滚压根没有必要上到生产才发现，我们在后端的环境就能察觉，这种风险变更压根不会发到生产区。另一个要强调的就是自动化测试强调执行和持续改进。

6展望：哈哈太多了，只想一步步把眼前事情做好。

喜欢和大家沟通，欢迎多提意见。谢谢大家对工作的理解。

请勿转发