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

2019/04/10 10:10
阅读数 24

自觉良好

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

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

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

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

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

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

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

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

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

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

冥冥之中的隐患

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

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

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

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

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

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

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

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

需要长远规划

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

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

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

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

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

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

设卡&评审

关于评审,比如 核心模块的设计评审(思路和技术点)

需求评审

接口协议的设计评审(命名,出入参)

代码走查评审

测试用例评审

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

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

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

3、是一种态度的输出

其中几个经验是:

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

2、会前,发布一个会议大纲。(这个做得也行,这个都会说一下)

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

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

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

3、会议设定一个主持人

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

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

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

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

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

项目回顾

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

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

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

加入测试

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

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

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

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

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

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

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

坚持执行,不断调整

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

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

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

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

总结

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

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

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

(喝茶水有点多,睡不着,深夜发个文章催眠一下)

原文出处:https://www.cnblogs.com/sunchong/p/12318704.html

展开阅读全文
打赏
0
1 收藏
分享
加载中
更多评论
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部