京麦敏捷团队解密一

京麦团队从2014年在敏捷教练的指导下进行敏捷转型,至今团队已经进化为部门内的标杆,产品也上升到了部门战略级。

京麦团队敏捷视频 —— (在如下的视频中,你将领略到,我们团队是如何进行敏捷实践的!)

前言

在团队的早期,团队远远没有现在团队那么多人,只有4个研发做一个"鸡肋"的产品。为什么说是鸡肋,并不是没人用,而是竞品很多,给用户产生的价值不凸显。

原来的开发节奏是一、二个月发布一个版本,你要知道这个节奏,在现在大鱼吃小鱼,更是快鱼吃慢鱼的时代,已经是致命的了。同时,竞品又是很强势,如何在激烈的竞争中活下去?

死亡行军的救命稻草

市场是未知的,团队是小团队。我们如何花费最小的成本去验证我们的假设是正确的,我们做的产品如何直抵用户痛点!我们没有充裕的时间、经费和人力去开发一个大而全的产品,然后投放市场进行验证!如果产品定位失败(没人用你的产品),团队和产品面临的都将是毁灭的!

于是,我们结识了敏捷!我们进行了变革,由此拉开了敏捷转型的序幕。面对变革,前途未知,所以我们将这次敏捷转型之路定义为死亡行军,而敏捷就是这最后的救命稻草。

到现在转型敏捷是非常成功,不管是产品还是团队。而这一路走来,敏捷到底给我们带来了什么改变?为什么我们成功了?这期间,我们进行太多内部敏捷培训和敏捷工程实践。

简单来说,敏捷的变化:

1. 小步快跑:小版本发布,从一、二月缩短到1、2周,这其中涉及到产品需求的细粒度拆分、快速抢占市场、用最小的成本在市场上对产品进行假设的验证。这在与竞品的赛跑中,效果显著,距离越拉越大!

2. 团队激情:为了高效的沟通,Face To Face 的讨论;为了保障代码质量,进行 Code Review。并且在工作上,通过看板实现工作透明、自认领、及时反馈,最重要的一点,是让领导从关注空闲人转而关注空闲任务,这都让团队富有激情和创造力。

3. 极限反馈和部署流水线:引入大量的富有效果的敏捷实践工作,包括持续集成、自动化部署、静态代码分析、监控报警等等,这些都大大释放了团队资源,减少了无效的工具。我们是单分支开发,团队任何一个人提交一行代码,都会先进行编译构建、进行自动化测试、进行静态代码分析、最后进行自动化部署,有问题,准确定位快速反馈。

还有太多的故事内容会与大家分享!也请关注持续更新,会有更多的爆料,希望对正在做敏捷转型的团队,或创业中的在产品试水的团队有所帮助。

—————————— 本文同步发布于 ZHANGSR 我的个人博客  ——————————

时间: 2024-10-21 15:44:07

京麦敏捷团队解密一的相关文章

敏捷团队的规范与准则

敏捷团队的规范与准则 阅读目录 1.序言 2. 敏捷团队的共识 3.Worktile的使用规范 4. 计划会议的规范 5.评审会议的规范 6.代码规范 7.设计原则与规范 回到顶部 1.序言 打造一个金诚所至的敏捷团队,需要大家自发的来遵守以及完善相应的规范.大家在自我约束的前提下,彼此之间互相影响,由下而上推动团队的建设.所以规矩.准则应该是越少越好,通过良好的自我约束驱动团队的成长. 在阅读本文档之前,假设你已经了解了敏捷开发(Scrum)的相关知识,若从未接触过敏捷开发,请先查阅 <敏捷开

成熟的敏捷团队该如何看待产品(系统)的缺陷?

何不乐观的看待产品(系统)缺陷? 藉由演算法, 电脑现在可以作曲, 人脸识别, 看病, 预测某人在某个议题上的决策--等等. 所以, 可不可能开发个软件, 经由该软件中的演算法, 会自动的找出产品(系统)中的所有缺陷? 答案是--否定的, 不可能的. 因为, 要能有个软件, 能找出产品(系统)的所有的缺陷, 那就必需先要有个"无缺陷的软件". 当然, 这是永远不可能的. 所以, 缺陷永远找不完, 缺陷也就永远不可被避免.那我们应如何看待缺陷? "任何的产品(系统)上的缺陷,

敏捷团队谁负责?

中国人常说一句话:责任到人,否则就是无人负责.敏捷团队则提倡自组织团队,团队负责.那么敏捷团队是否就是无人负责?我在Linkedin的Scrum Alliance, Inc.组内提出了这个问题,下面有关此问题的一些回答: 从传统式的“命令-控制”式管理到敏捷,首先应该是观念上的转变.这个非常困难.敏捷团队中不存在“我”,或者说“小我”,而是“我们”.无论是成功还是失败,都是“我们”.——Tushar Jain 巴西足球队输给了德国队,谁对此负责?那么又谁对德国队赢得冠军负责?是那个得分的队员么?

敏捷团队中测试人员的角色

Karen Greaves和Sam Laing将会在Agile Testing Days 2015上发表主旨演讲,演讲题目为"测试人员正在消亡",Agile Testing Days 2015将于11月9日至12日德国Potsdam举行.小编将会覆盖本次会议报道. 小编对二人进行了采访,关于敏捷是如何影响测试人员角色的,为了缩短测试交付周期,测试人员可以采取哪些措施,敏捷团队中测试人员与其他团队成员之间的协作,敏捷团队中测试人员可以贡献的价值. 小编:我的经验是,敏捷更广泛的普及率正在

测试人员在敏捷团队中扮演的角色

对于开发模式,现在大部分互联网公司都完成了从传统瀑布开发模式到敏捷开发模式的转型,这种转型相对传统的测试人员来说,不论是在角色定位还是在技能栈方面都提出了更大的挑战,那么测试人员应该如何应对呢?下面根据我平时工作的一些总结体会来说说测试人员应该发力的方向,供大家参考: 角色 1: 培训人员 在转型初期,测试人员应该针对开发人员的薄弱环节(即业务技能)进行培训和指导.由于工作任务的差别,开发人员对负责的模块业务和具体实现细节非常了解,但是对周边模块或者业务并不是非常清楚,主要体现在配置和使用方面.

软硬件通包的产品级敏捷团队

2015.6.4,在武汉.和比自己聪明的人.一起做产品.永远是种最大的幸福. "软硬件通包的产品级敏捷团队"-- 团队不同角色的协作.建立起软硬件的核心信息,经由软硬件的核心信息,软硬件通包的产品级敏捷团队便能马上-- 分析出在新的硬件规格下,新增的业务场景为何? 在新增硬件的规格下,为提升用户的惬意度.分析出所需的架构的 Qualityof Service 为何? 架构上所需的新的技术验证点为何? 识别在新增硬件现行的进度状态下,可马上投入开发的场景为何? 架构为何? 測试场景为何?

多个敏捷团队之间的版本控制

http://www.infoq.com/cn/articles/agile-version-control/ 多个敏捷团队之间的版本控制 如果我们有多个敏捷团队在同一个代码库上工作时,如何将彼此之间代码互相冲突的风险最小化?如何确保每个迭代结束时拥有一个干净的.可发布的软件版本?本文讲述了关于如何在敏捷的环境中与多个团队共同进行版本控制工作的实例——这正是我们在<Scrum and XP from the Trenches>中描述的公司所采纳的方式. 本文并非专为版本控制专家所写,实际上这样

使用国产优秀的敏捷团队协作工具LEANGOO开展SCRUM看板工作

之前的这篇文章里我介绍了国外优秀的看板协作工具Trello,可以帮助我们管理团队任务或者自己的任务安排,并形象化的把这些任务放到看板上,更加直观的看到任务的状态.今天我想介绍给大家的是国产的优秀的敏捷团队协作工具LEANGOO,和Trello不同的是,LEANGOO加入了更多敏捷开发中用到的元素,例如任务的点数.Sprint周期.燃尽图等,下面就把我的使用体验分享给大家: 1.LEANGOO中自定义看板的栏位数量和名称 和Trello一样,在LEANGOO中我们也可以自定义看板的栏位数量和栏位名

敏捷团队成员应具备的素质

A very good team player 很好的团队合作者.敏捷强调团队,如果只是个人能力强而不懂得合作,这样的人在敏捷团队里就没法混. Excellent communication skills 优秀的沟通能力.这一点的重要性不言而喻,敏捷里最强调的就是沟通,最有效的沟通方式就是面对面的交流.那种只会埋头干活,不会沟通的不要. Open minded, pro-active, and self-motivated 敏捷团队成员必须能够敞开思想,随时接受新事物,积极主动,自我激励 [摘抄