说透敏捷
宋宁
IBM资深敏捷教练
立即订阅
5968 人已学习
课程目录
已完结 12 讲
开篇词 (1讲)
开篇词 | 重识敏捷,让你的研发管理少走一些弯路
免费
原理篇 (2讲)
01 | 灵魂拷问:如何利用敏捷思维更好地解决实际问题?
02 | 老生常谈:你真的知道敏捷到底是什么吗?
实战篇 (4讲)
03 | 评估诊断:成功迈出敏捷推进的第一步
04 | 团队试点(一):让你的敏捷实践“事半功倍”
05 | 团队试点(二):打造一支无往不胜的敏捷团队
06 | 规模化推广:复制粘贴试点的经验就够了吗?
策略篇 (2讲)
07 | 填坑指南:填好这4个坑,快速做对敏捷
08 | 避雷策略:如何防止你的敏捷变为“小瀑布”?
管理篇 (2讲)
09 | 内部教练:守护敏捷实践,求人不如求己
10 | 服务型领导:在敏捷中你该怎样提升自己的领导力?
结束语 (1讲)
结束语 | 用敏捷提升自己,从敏捷走向未来
说透敏捷
登录|注册

01 | 灵魂拷问:如何利用敏捷思维更好地解决实际问题?

宋宁 2020-01-06
你好,我是宋宁。
今天是专栏的第一讲,在为你讲解怎么做敏捷之前,我想先用几个案例给你讲讲敏捷的价值。
敏捷在国内推进得如火如荼,我知道很多公司的研发团队都在使用敏捷,并且尝到了其中的甜头。但也有些公司,看别人做得挺好的,就照搬过来,结果却不奏效,因为探索地不是很成功,就觉得敏捷不好用,不适用于他们公司,开始怀疑敏捷的价值。
作为一个过来人,我想谈一下我的看法:我认为敏捷确实是很好的,只是推进它确实不容易。
为什么这么说呢?因为敏捷毕竟是一场变革,它本身涉及很多人的因素,比如人的习惯、团队文化的改变等等,而且它的核心点是持续改进,可以说是一场没有终点的旅行。况且它有一定的章法,但是若想运用好它,你又不能拘泥于它的章法。如果你只是了解敏捷的表面做法,就开始邯郸学步,那注定会失败。
所以,在这里我更想让你了解的是敏捷的思维,多理解一些 why,你自然就能够把敏捷融入到工作中,举一反三。但切记,千万不要为了敏捷而敏捷,所以在这篇文章中我也并不想说服你全盘使用敏捷,如果你觉得敏捷方法多,有些繁杂,不是所有都用得上,那也可以从中借鉴一些去解决你的实际问题。总之,能够更好地解决问题就好。
刚才我说我觉得敏捷很好,这话不具体,接下来我想和你讲一个故事。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《说透敏捷》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(39)

  • 丁丁历险记
    一定要早点把客户拉下水。让客户早点确认各种细节。这样就不会后期唧唧歪歪了。

    作者回复: 赞一个

    2020-01-07
    2
    19
  • 李永智
    敏捷方法使用过,虽然效率有提升,开发理解需求有极大改善,但也做了测试驱动,尽管代价不小,发现有些产品交付质量差,经分析,主要是人员水平造成的,应该是敏捷相比瀑布开发对人员的要求多和高,但现实人员更换受限的情况下,如何提升?或者是我上述的归因有偏差,那问题可能出在哪里,针对这些,有啥应对原则?

    作者回复: 这是个好问题,关于人员培养的问题是个永恒的话题。这里面涉及2个方面,一个是态度转变,一个是能力提升。态度转变的话我们其实有很多方法可以让员工有参与感,参与到转型过程中,如后面05会有一些方法,让员工进到我们的转型过程,有参与感,同时也要意识到自己的能力需要提升,这样很多员工都有提升的动力;第二个问题,能力提升的问题方法也非常多,可以组织拆书会等等快速地了解一个领域的知识,也可以互相之间分享,老带新,反讲,建立辅导机制,能力高的辅导能力低的等等,非常多的方法,只要人发动起来,方法总能找得到。最后记住一点是,人毕生都是在发展的,减少对人的刻板印象,鼓励发动他动起来学起来跟上来,这个很重要。

    2020-01-07
    2
    11
  • qinhua-冰糖橙自产自销
    特点:快速响应变化,允许试错,小步快跑。
    做法:固定小团队,优先级的需求池,客户参入,实时验收。
    2020-01-07
    5
  • 阡陌
    一直想尝试,但是总是事与愿违。说到底还是需要公司高层的支持和底层人员的不断尝试才行。
    2020-01-07
    5
  • 吴言乱语
    利用敏捷的方法缩短项目开发时间是我们一直努力的方向,公司在高速成长,产品迭代必须紧跟业务发展,常常遇到的情况是业务部门临时的排版需求上线时间。
    在实现过程中,产品经理会在同业务确定需求完成后的第一时间组织立项会议,UI,开发,测试共同参与,进行需求宣导。
    接下来,
    产品团队的方案设计,UI团队的界面交互设计,开发团队的技术实现拆分,测试团队的测试用例会同步并行开展。如果遇到需要外部协作,也是先沟通确定合作方案,然后各自开发最终联调,将等待时间不断的压缩,缩短项目开发周期
    2020-01-07
    3
  • 王刚
    老师,请教几个问题:
    1.团队拆分为特性小组的标准是什么?多少人为一组为最佳呢?
    2.使用敏捷模式,开发前期的接口文档要不要省略呢?
    3.业务参与需求分析,是不是就是确定原型图的过程?

    作者回复: 第一个问题,我们在04里有一些关于组织的说明,特性团队拆分在敏捷里如上面朋友所说,确实没有固定的死的标准,但有些原则可供你参考。一个是团队大小,是5-9个人,大了要进行拆分;第二个是全功能团队。
    第二个问题,文档的留与否,需要根据实际情况来做剪裁,在剪裁前,评估文档为产品开发带来的价值大小和实际工作量,一般而言不建议省略接口文档,接口文档是开发中的重要文档,但如果团队找到了更好的工作方法替代这个文档除外。

    2020-01-07
    4
    3
  • 桃子-夏勇杰
    第一步组建特性团队就是一个难题,这是一个思维方式的转变,改变了开发团队原有的开发习惯和思维惯性。宋老师是如何说服团队做这样的转变的呢?

    作者回复: 思维方式转变确实是比较难的,仅靠口头说服是远远不够的,所以除了宣讲以外,我采取的方式有很多:带他们参观已经转型的团队,有一些感性认识;必要的时候带他们打个胜仗,团队在不同阶段需要的辅助也是不同的,还有我们在05团队试点里的一些方法等等重要的是要让他们觉得是他们需要改变而不是“我”作为咨询师或者敏捷推动者让他们改变。

    2020-01-07
    1
    2
  • escray
    我对于,“敏捷确实好,但是推进不容易”这个说法深表认同。如果真的落实敏捷,对于研发人员的要求还是比较高的,对于每个开发的工作会有定性和定量的尺度,上班摸鱼就没那么方便了;对于组织架构来说,可能也需要进行一定的调整,比如作者说的划分小团队,但是更主要的可能还是思想上的变革。

    其实如果能够照着一成不变的需求文档或者详细设计来写代码,对于开发人员来说是相对简单的,但是往往做出来的东西,并不是用户真正想要的。

    不过从另一方面,如果是类似于火箭发射或者是精密仪器之类的软硬件研发,还是瀑布模式更合适,主要是因为这一类项目的需求规格相对比较稳定。

    还有一点,个人感觉其实小团队更容易实行敏捷,主要是比较容易形成共识。

    但是现在似乎把敏捷的范围扩展了,只要采用了一部分敏捷的方法,就可以定义为敏捷。

    在体制内单位,其中也有项目的外包方采用了迭代开发、滚动上线的方式,也可以说“敏捷”起来了。但是,没有单元测试、配置管理、持续继承、版本控制……这样也可以算是敏捷么?

    作者回复: 现实中没有完美的敏捷模式,虽然这是我们一直追求的目标,但大家都走在路上,推进敏捷的方式有激进式的“貌似一步到位”,但其实后面也有很多工作,另一种渐进式的则是解决一个旧问题出现一个新问题,其实一直在做持续改进,有的企业先做了“形式”上的敏捷,后面发现痛点之后继续改进一步一步地推进了更多的技术实践来助力研发

    2020-01-07
    2
    2
  • solaris
    1. 研发过程中遇到的难题
         1. 团队有在跑scrum,但是感觉成员态度比较随意,并且容易乐观估计时间点
         2. 需求和顶层设计,有时候会面临调整,导致大范围改动,成员抵触情绪比较大,应该如何解决呢?
         3.团队沟通不够充分,随着迭代次数变多,对系统模型、设计、实现的认识不太对齐

     2. 使用敏捷方法或借鉴敏捷思想的经历
         1. 先把主流程跑通,再优化
         2. 不要有太多的流程和条条框框,快速迭代,快速试错
         3.项目分解成几期,每期完成阶段性目标,找不同的业务团队来试用
    2020-01-13
    1
    1
  • J
    作为研发人员,宋老师列举的案例是真的感同身受。当时团队没有任何规范的研发流程,并且没有测试。按照瀑布模式,做出来的东西很自然遭到客户投诉。
    后面复盘以及处理各个环节如需求挖掘,沟通力度,用人方向等所暴露问题。
    而为了整顿就引入了敏捷开发的概念,各个环节的问题都没有妥善解决,最后整个系统虽然还是上线了,但时不时会就遭到客户不同岗位角色对于某一功能缺陷提了好几个月都没解决好的投诉。
    2020-01-13
    1
  • jeffery
    devops和敏捷的区别是啥、听说devops是敏捷2.0
    2020-01-10
    1
    1
  • 原点
    有点多线程同步的感觉
    2020-01-09
    1
  • 海棠
    特性团队对于团队成员的要求其实是非常高的,自己的公司也是FT制,但距离理想的FT状态还差很远,感觉更像是组件团队与特性团队的中间态。所以,不仅推行敏捷难,转型特性团队也很难,在推行FT化的过程中,有什么心得吗?

    作者回复: 首先是组织设计问题,其次是人员培养问题和带团队的问题,我们后面有涉及,细看一下咱们专栏的实战篇

    2020-01-07
    1
  • 桃子-夏勇杰
    什么是敏捷思维?要解决什么问题?首先要回答好这个问题,否则,不存在所谓的灵魂拷问。
    2020-01-07
    1
  • 再不吃胖我们就老了
    不管是瀑布还是敏捷,对于人员的要求都是有的,只不过敏捷因为是快速迭代的,要求会更高。N年前接触敏捷,今天看完这篇发现现在的项目已经是敏捷式的开发了。现在大家都对MVP、迭代这些习以为常了。
    2020-01-07
    1
  • Mark
    组建一个个小的特性团队的优势再具体描述一下吧

    作者回复: 所谓船小好调头,每个小团队的协作效率更高一些,而且当我们把需求拆下以后,对应这样的小特性团队会让整个开发过程更加的灵活。
    04有讲具体怎么做。

    2020-01-18
  • Geek_wei
    哪些项目适合敏捷,哪些项目不适合呢?比如一些大型系统的系统架构环节是否适合敏捷呢?
    2020-01-18
  • 镜花水月
    宋老师,我有两个问题希望得到解答。
    1.没有做过开发的人能胜任敏捷教练吗?
    2.来到现在的团队时已经引入了敏捷,一个团队如何转型敏捷并没有亲自参与实践的经验,感觉不是通过看书能够获得实际经验的,这个怎么办。

    作者回复: 1. 可以的,只要能够跟开发兄弟沟通,能够听懂他们的语言。
    2.虽然团队已经引入了敏捷,但是一般而言,引入以后一般不能一步到位,团队还需要慢慢带领和培养,可以在后面的工作中慢慢体会和参与引导,从引导团队对话中慢慢地体会敏捷。

    2020-01-17
  • Binds.Chen
    让客户参与进来经常碰到的问题是他一开始只想要一碗羊肉面,做着做着想法就变了,最后就变成要满汉全席了。这个改如何解决呢?毕竟项目的时间和经济成本不会因为客户的想法深化而追加。

    作者回复: 这涉及一个客户期望管理的问题。始终要对客户灌输价值理念,让他自己挑选价值最大的需求,以及向其可视化你们的工作,让他理解到在有限的时间内,有限的资源不能完成所有的事情,但我们能保证的是在给定的资源和时间内给他最好的。

    2020-01-16
  • 海子
    老师你好,今天刚和同事再聊起敏捷,我们在对敏捷过程中的文档输出这块有一些争议,我认为无论采用瀑布或敏捷方式都应该有完备的技术文档输出但是对方说敏捷不需要太在意文档输出,针对这块您有什么想法?如果需要输出,文档本身会不会影响敏捷的效能?

    作者回复: 这一块内容我们在02有讲到,继续往后看哈:-)

    2020-01-15
收起评论
39
返回
顶部