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

自觉良好

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

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

咱们负责的项目有开发任务，同时也有很多运维工做。常常会有新需求插入和变动。

咱们效仿一些敏捷形式和方法。有些作得挺好，有些作得不可以长期坚持。

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

咱们虽然每周都有计划，从上面能够看出，咱们没有远期目标。由于个人懒惰，没有从项目上梳理长期的规划。

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

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

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

就比如，你刚毕业就让你负责系统架构同样，我想刚毕业的我有心想作，可是内心仍是会战战兢兢。

冥冥之中的隐患

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

因此二者的结合孕育出了不少的优秀的敏捷实践。

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

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

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

咱们只管往前跑，冥冥之中感受本身在作无用功，甚至说咱们所作的任务价值意义不大。

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

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

须要长远规划

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

须要付出时间和精力来作这些事情，这个比如是架构，一部成长史。参与其中的成长是很是有成就的。

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

好比史诗级别：做为一个运维人员，我但愿有一个后台能够方便个人平常运维工做，来提升处理问题的速度更快地相应客户。

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

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

设卡&评审

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

需求评审

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

代码走查评审

测试用例评审

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

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

二、三个臭皮匠顶一个诸葛亮，你们不一样的智慧的碰撞会发现不少新的坑。

三、是一种态度的输出

其中几个经验是：

一、功夫都在平时准备：好比设计文档、接口规范设计文档、测试用例的用例（这个咱们作的还行，也是须要导师多督促，成员可以主动沟通）

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

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

本身会大约使用多长时间？留给其余人员的讨论时间是多少？

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

三、会议设定一个主持人

（这个很重要也颇有效果，以前没有主持人会议常常超时。关键是超时还以为自豪，自豪会议又讨论出不少东西，自豪发言很踊跃。）

其实仍是为了一个开会的效果，能够找一个资历高一点的把控会议。避免过分讨论。

也就是你们的时间成本和开会的效果尽可能地高效。

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

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

项目回顾

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

好的很差的都须要说。我的来讲也是这样，好的很差的都须要总结。我的提升了也是项目总体提升的一部分。

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

加入测试

由于主要提供接口。一开始咱们的都是本身测试，长此以往就没有让测试加入。

开始以为这样挺好，流程更短。

如今想咱们的3个总结是：

一、咱们其实作得工做并很多，反而多了，由于兼顾了测试的一部分工做

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

三、咱们相信咱们，可是咱们仍是不够专业。就算是接口简单不须要测试人员介入。

可是须要测试思惟，测试的测试角度思惟常常会给咱们当头一棒，很受用。

坚持执行，不断调整

但愿我可以坚持执行，不断反思调整。

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

本身近期看了不少敏捷相关的书籍，最近又看完的这一本，收获仍是很大的，纠正了不少原来的认知。

好比：全部的用户故事必须符合6原则（实际上是容许出现史诗级的用户故事的）

总结

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

本身立一个Flag 立一个愿望，但愿上述咱们项目中存在的问题可以在上半年有所改善。

可以督促系统的成长和发展。

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