敏捷开发：最近的收获和站会上的小黄鸭

Posted 2021-04-25 梯形

最近

在博客园经常分享一些心得，有幸在另一个平台做了一场直播。

自己精心准备了很长时间，从素材和文章以及一字一句。

过程中感觉自信满满，后期再去回顾发现其实硬货还需要再硬一点。

dbaplus的分享

自己在这个社区进行分享的时候，开始自己照着自己的演讲稿念，没多久自己发现根据演讲稿导致思路不够连贯。

自己扔掉演讲稿根据之前自己准备的主体脉络进行分享，有准备但是还是觉得临场发挥思路更加连贯和清晰。

一个半小时过去了，我的分享完毕，这种直播的压力确实是比较大的，因为你要直接面对听众，会遇到一些突发事情。

期间就发生了2次离线，还有你要关注评论的同时也不能让评论影响你的节奏，

对于一些重要的评论在分享过程中随时回复还是记录下来？

直播结束后，第二天我又重新听了一下自己的分享，总结一下直播的经验。

过程比结果收获更大。期间还有一件事让我很是纠结。

心中的那种不自信的感觉完全战胜了一切。自己不是技术最牛的，自己也不是这个管理经验最丰富的。

我对自己这种纠结懊悔了很久，正常地做自己就好了，又不是做给别人看的。

下次再有机会我会更加自信，即便不是最专业，那也需要一份对自己努力的自信。

另一个话题

没有一丝防备，我们直接切换另一个话题。

上面算是给自己这3个月没写博客划一个句号。我们来看看最近我们在敏捷一些什么？

我们项目组组织了读书分享，当时组织这个读书分享我也是很纠结。

作为项目经理不是职能经理，自己到底组织一场读书分享合不合适？

我把我的疑惑和需求说给了我们项目群经理，希望从他那里能够得到一些经验。

疑惑：我们从项目角度出发来组织学习，会不会触碰了职能经理的职能边界？

（比如让大家阅读《Scrum精髓：敏捷转型指南》，会不会触碰产品职能的边界？）

需求：我希望大家能够系统地认识敏捷和框架。
从中能够学习到一些东西来应用到项目中，其次大家对于这种项目内的分享形式是拥抱的态度

经理的建议是可以尝试一下。我们项目组开了一个会，约定了一下。

在不占用大家太多的时间，我们挑选值得阅读的章节么一个项目中带着一次分享，每次分享大约1-2个章节。

是的，我们迈出了第一步

我们其实是在项目结束后一周内，确定好阅读范围，确定好分享人，确定好分享时长两小时。

流程分为依次提问和自由提问，分享人可以拿任何的分享资料分享（doc,表格）都行。

目的就是让大家心里有一定的概念并对当前最容易实行的一个敏捷方法进行深入讨论。

这是当时分享人的一个分享大纲

第一次分享，大家也在适应遮掩的一种分享状态。

整体过程很顺利也够味，如果能够再放松一些那就更好了，大家说着说着就说成了项目总结会~

从这次会议中的一些启发

从有了开这种分享会的想法到实行，总结下来就是如果大家都抱有期待并且准备充足那就先试试。有想法就尝试。

一些之前的想去执行的想法，当下就会执行尝试。

站会上的小鸭子

终于到了标题中的这一部分。之前读敏捷相关的书籍时，很多会提到站会上需要一个像权力交接棒的实际物品来标识你的权力~

以前我们开站会，时间和习惯都不错，到时间我提醒大家开会，大家凑一堆开始开会。

但是，总觉得缺少一些什么让整个会议显得有点太过于形式。

我想起了开始的那句话：有一个实际的权力物品来做交接。

看吧，就是这只小鸭子

改变

每天的站会，不同的主持人，主持人的象征就是拥有这只小鸭子~

就是谁拿到这只小鸭子，谁就是站会的负责人和支持人。

8：40 他会在群里喊，然后会议上主持，结束后流动到另一位组织者手里~

大家对站会接受度更高了，对这个项目也有了一些感情，团队的人的默契和氛围会默默提高很多。

这种感觉是潜移默化的，也是需要我们随时提醒和建立的。

再回过头来说那次敏捷分享的效果，我们之前是开发，然后测试，最后上线。

我们虽然是分阶段提测但是没有执行分阶段测试。

所以这次新版本中我们“打成”一致尝试分阶段提测后分阶段测试。就是 开发-测试交替进行。

有没有难度呢？有，就是大家的时间和专注度会受到冲击。

对于实践这个开发、测试交替进行我们承认一些东西也相信一些东西。

我们组内也承认起初实践起来肯定会比之前的模式有一定的不适应，但是我们依然信心。

希望可以踊跃暴漏问题不管是个人还是团队不管是心情还是问题，都暴露出来。

我们组内达成了一致默默尝试了一下，我们重视了组内的冲刺总结会，其实从总结会上我们收获还是很多的。

一些开发和沟通问题，组内他们能够自组织去主动解决，根据目前组内的主动性，我觉得我不需要关心。

我重点解决了一下时间和专注度冲突的问题。

开发正在开发下一个阶段，测试正在测试你上一个阶段，突然一个bug给你你烦不烦？开不开心？

--你是马上断开思路去改正？还是抱着忐忑的心情继续开发？

开发修复完bug，马上回给测试，测试此时正在测试下一个阶段，

--你是断开思路马上去回归？还是思索着会不会影响后面的功能的心情测试下去？

达成一致

我们就问题讨论，最终达成一致

当然我们还依然坚信，刚开始实践期间肯定会有不适应和一些问题。

但是我们还坚持要解决问题并把问题的根因找出来，想办法解决。这是毋庸置疑的。

分阶段提测，大家达成一致是因为每一次提交的功能不是很多，测试测试之前可以先在群里发出通知。

开发就一些工作进行微调，便于后面的bug修改。

测试发通知--3：00统一提bug--开发4：00开始修复--测试最晚明天进行回归

还有一点就是，对于流程和严重bug，随时支持，没有理由。这个大家也是认可的。

总结

其实这一段时间对于我到其他社区进行了一次敏捷分享；

对于项目组，我们使用权力交接棒--小黄鸭，进行大家主人翁意识的交接培养。

对于项目，我们实践冲刺，我们开始重视每一次的冲刺总结会，

我们希望团队中任何一个人都可以发现问题并自己发起会议（当然也是集中遇到问题或者集中解决问题）

我们实践开发-测试交替进行的模式，为什么呢？

这个原因我们的测试总结得很好，缩短时间其次，重要的是测试可以提前参与，提前发现问题，而不是最后采取发现问题。

我理解的是通过测试的力量在过程中来保驾护航，而不是在项目最后去修修补补。

最近感触很大，当一些行动获得大家认可的时候，大家互相能理解，大家也都互相提建议。

为了让项目更好，让我们更加自主，你好，我好，项目好。你提高，我提高，项目也提高。

当前的应届生的学习能力和融合能力确实很强。

作为项目经理除了要保证项目交付这个基本目标以外，也是希望大家从项目中能够获得一些东西。我更希望是自驱的动力~

如果可以，可以把项目中的好的实践带到其他项目中去，去默默影响他人。

坚持自己，坚持自己的那些原则。获得好的优秀的经验，慢慢影响他人。