敏捷开发：我们这段时间好像是伪敏捷

自觉良好

就在之前几篇的时候，我们已经默默开始给小团队灌输敏捷知识。

这个团队很小，产品：快一年经验；开发：毕业一年，初级程序员；还有一个有些经验的我。

我们负责的项目有开发任务，同时也有不少运维工作。经常会有新需求插入和变更。

我们效仿一些敏捷形式和方法。有些做得挺好，有些做得不能够长期坚持。

我们产品列表比较混乱，没有做整理细化，有一个摞一个。从外面看整个产品是混乱的，看不清未来方向的。

我们虽然每周都有计划，从上面可以看出，我们没有远期目标。因为我的懒惰，没有从项目上梳理长期的规划。

自认为需求频繁变动，所以没必要清晰的长期规划。也不是说没有想过，讨论过，也达成一致过。但是没有落实到产品列表中。

你从产品列表中不会看到未来系统的模样。

应届生的产品做么？他一直也是这么做的，只是有时我们稍微缺少了引导就会止步不前，不是积极性问题，是他有时真的无法下手。

就好比，你刚毕业就让你负责系统架构一样，我想刚毕业的我有心想做，但是心里还是会战战兢兢。

冥冥之中的隐患

其实说到底还是项目管理的问题。我现在隐隐体会到，敏捷是指导原则，实际贯穿主线的还是项目管理。

所以两者的结合孕育出了很多的优秀的敏捷实践。

我们省去了产品列表的规划，只有零星的周计划。我们甚至没有了项目回顾会议。

我们起初所认为的快 —— 实际上是省去了各种产品列表的优先级排列：史诗级、主题级、冲刺级，由粗到细的用户故事的拆分。

我们虽然将周期调整为一周一个计划，来应对频繁的运维需求的变更。但是我们也缺少了项目相关的评审会议、回顾会议。

我们只管往前跑，冥冥之中感觉自己在做无用功，甚至说我们所做的任务价值意义不大。

导致这种错觉的，一个是很大程度上是没有长远规划，另一个是各种评审和关键点没有设卡，还有一个是没有了回顾和反省。

所以要遵循项目管理的主要规律和重要的实践，虽然这些操作时间上付出是有一定的成本，这些付出是值得的。

需要长远规划

就好比大家没有了共同的目标，这个不利于团队的士气，不利于项目的发展。

需要付出时间和精力来做这些事情，这个好比是架构，一部成长史。参与其中的成长是非常有成就的。

产品列表：史诗级用户故事；主题级用户故事；冲刺级用户故事。冲刺级别是具体可执行的任务。

比如史诗级别：作为一个运维人员，我希望有一个后台可以方便我的日常运维工作，来提高处理问题的速度更快地相应客户。

比如主题级别：作为一个用户，我想我发起的任务可以并行调度而不是长时间等待顺序排队，这样才能很快并陆续收到反馈。

比如冲刺级别：作为一个运维人员，我在系统中能够拥有在线对账的权限，这样利于月中对账，而不是每次都需要写邮件给DBA申请导出.

设卡&评审

关于评审，比如 核心模块的设计评审（思路和技术点）

需求评审

接口协议的设计评审（命名，出入参）

代码走查评审

测试用例评审

从各种评审中我收获到的几个基本的好处是：

1、对于被评审人员，专业技能上是一个肉眼可见的提升。

2、三个臭皮匠顶一个诸葛亮，大家不同的智慧的碰撞会发现很多新的坑。

3、是一种态度的输出

其中几个经验是：

1、功夫都在平时准备：比如设计文档、接口规范设计文档、测试用例的用例（这个我们做的还行，也是需要导师多督促，成员能够主动沟通）

2、会前，发布一个会议大纲。（这个做得也行，这个都会说一下）

比如会议的主要讨论主题是什么？会议的时间是多久？

自己会大约使用多长时间？留给其他人员的讨论时间是多少？

开会只是一个对当前结果的一个讨论。

3、会议设定一个主持人

（这个很重要也很有效果，之前没有主持人会议经常超时。关键是超时还觉得自豪，自豪会议又讨论出很多东西，自豪发言很踊跃。）

其实还是为了一个开会的效果，可以找一个资历高一点的把控会议。避免过度讨论。

也就是大家的时间成本和开会的效果尽量地高效。

4、结束后整理会议纪要（这个执行得算是及格，但是不够坚持）

其实会议纪要是次要的，主要是对会议讨论的结果负责，最好有产出物或者结论。

项目回顾

项目上的回顾，总结过去，计划未来。

好的不好的都需要说。个人来说也是这样，好的不好的都需要总结。个人提高了也是项目整体提高的一部分。

再就是计划一下接下来的工作，明确下一个版本的目标。

加入测试

因为主要提供接口。一开始我们的都是自己测试，久而久之就没有让测试加入。

开始觉得这样挺好，流程更短。

现在想我们的3个总结是：

1、我们其实做得工作并不少，反而多了，因为兼顾了测试的一部分工作

2、任务多了，有可能影响了工期和质量

3、我们相信我们，但是我们还是不够专业。就算是接口简单不需要测试人员介入。

但是需要测试思维，测试的测试角度思维经常会给我们当头一棒，很受用。

坚持执行，不断调整

希望我能够坚持执行，不断反思调整。

根据成员能力和专业程度采用相关的敏捷实践，不是所有市面上好的都有效。

自己近期看了很多敏捷相关的书籍，最近又看完的这一本，收获还是很大的，纠正了很多原来的认知。

比如：所有的用户故事必须符合6原则（其实是允许出现史诗级的用户故事的）

总结

项目管理，甚至说软件工程需要我们不断吸收并反复琢磨实践。

自己立一个Flag 立一个愿望，希望上述我们项目中存在的问题能够在上半年有所改善。

能够督促系统的成长和发展。

（喝茶水有点多，睡不着，深夜发个文章催眠一下）