敏捷初体验
小编作为初入职场的菜鸟一枚,毕业之后刚进入公司就接触到了炫酷的“敏捷”文化。
敏捷宣言:
看板:
站会:
燃尽图:
小编初识“敏捷”,作为预备Scrum Master,深刻的体会到了“敏捷”带给软件开发的好处,敏捷把产品开发引向了快速迭代、小步快跑的路线上。在团队初期,站会氛围很好,效率较高,用户故事直接站在用户的角度描述需求,每日站会团队成员回答三个问题:昨天做了什么?今天准备做什么?遇到的项目问题?每天进行简洁有效的团队内部沟通。故事看板直观的反映工作进度,故事流转情况。持续集成保障代码随时高质量交付,拥抱需求变化。
敏捷开发中的各轮实践下来,带给团队的好处不言而喻,敏捷开发有点类似于深度学习中的梯度下降法,我们每走一步看一步,每走一步都有及时的测试来验证,走的每一步都很踏实,逐渐趋近于目标。并且敏捷开发最大限度的解决了用户需求描述和产品功能信息不对称的问题,用户可以尽早的得到产品的一部分功能的实际体验,从而尽快的把信息反馈给产品研发团队,这些极具价值的反馈信息将会成为随后产品交付功能的重要参考。因此个人理解敏捷的核心理念就是:价值驱动、快速验证。敏捷的核心理念也反应出了敏捷的优点,就是快速灵活。
发现问题
然而,一个团队自然会经历一个由小变大的过程,随着团队人员的增加,项目需求变得越来越复杂,敏捷实践在团队的增长期通常会出现一些问题:
问题一:需求的快速迭代和功能的复杂实现,导致加班问题,团队满意度降低
加班问题应该是团队增长期比较常见的问题,项目功能变得复杂,需求来的太快,快速的迭代带来了加班的问题,长期的加班必然会引起团队满意度的降低,同时可能会引起代码质量的下降,优秀人才的流失。一连串的问题会导致敏捷开发过程的不可控。
个人认为,可以从需求决策、合理评估、内部团队激励、自我提升四个方面改善:
1.需求决策:管理者需要在策略上迅速行动,确定需求的优先顺序,拟定待办需求清淡,将价值最高的需求分配给开发人员优先解决。
2.合理估算:需要合理估算story point,提升团队运作的透明度,让开发人员获得自主感、掌控感和目标感,加深团队之间的信任值。
3.内部激励:管理人员应该让团队成员认可敏捷理念并且对产品的质量有深刻的责任感,在自身能力范围之内,努力改善产品的质量。
4.自我提升:其实最有效的改善办法是提升开发人员自身开发能力水平,不断积累自身的经验,在各个层面去高效的应对。
其实,在实际的开发实践中,开发人员会不可避免的做一些琐碎的事情,这些琐碎的事情可能会占有工作中的一部分时间。我们需要做的是摆正心态,正确乐观的去看待工作中琐碎的事情,『善于从小事中发现价值、学习经验,将琐碎的工作转化成利于自身成长的有意义的事情』。当然,作为程序员,希望可以预留30% 的buffer作为码农的基本保命措施。
问题二:团队逐步扩大、产品趋于稳定、对于文档的需求与日俱增
敏捷中强调的是轻文档注重沟通,节省大量的文档编写时间,周期加快。团队成立初期,文档对于敏捷开发确实是非必需的,在每一个精确到工时的任务中,口头沟通显然效率更高。然而,当团队规模扩大,新人加入,需要了解产品和技术细节时,团队成员可能会告诉他,要不你去看下代码?或者你去看下之前用户故事?数据库的表字段更新了,我也不记得了。。。等等很模糊的回答。对于新入职的同事可能会不知所措。
其实,当团队逐步扩大,无论从内部协调还是外部沟通上流程化的标准文档需求都与日俱增。文档相较于口头沟通,灵活性较低,但是敏捷的实施并不排斥文档,甚至从长远来看,必要的文档提高了敏捷团队的实施效率,节省了一些常规问题的沟通成本,降低错误的发生概率。并且在团队出现人员流动时,新人可以快速的了解系统,离职人员可以总结之前的研发经验。
在敏捷团队中,我们可以采取分享会的形式定期在团队内部分享系统开发变更信息,并且定期更新系统文档,确保文档跟随系统开发进度持续更新改进。在团队更新换代时,文档可以帮助敏捷团队完整的追溯产品的历程。宏观来看,必要文档的存在以及更新对于敏捷团队也可谓是另一种“灵活”。
敏捷感悟
进入麒麟敏捷团队将近一年的时间,在工作过程中,对敏捷的理解也逐渐深刻。作为Scrum Master,我们的职责是在团队中推进敏捷理念,帮助团队成员更深刻的理解敏捷思维、实践、规则和价值。敏捷所强调的迭代其实不仅仅是对产品的迭代,更是对团队以及整个团队成员的迭代,并且敏捷团队需要兼顾快速反应和团队的长期成长,不能仅仅只是兼顾快速反应,而放弃精细设计和功能完善。
敏捷开发是以人为中心建立的开发的过程和机制,具体问题具体分析,需要根据项目特点制定敏捷计划。按照迭代地方式来做,不断试错,持续改进。『只有整个团队都能深刻的理解敏捷的核心理念并且认可敏捷带给团队的价值增值,才能在团队中长期推进敏捷的演进实施』。最后,希望麒麟敏捷团队以后可以努力成为一个积极的、自我管理的、具备自由交流风格的敏捷开发团队。