技术领导力实战笔记
TGO鲲鹏会
100 位 CTO 的真知灼见
82996 人已学习
新⼈⾸单¥98
登录后,你可以任选6讲全文学习
课程目录
已完结/共 266 讲
技术领导力实战笔记
15
15
1.0x
00:00/00:00
登录|注册

第57讲 | 敏捷中的期限之殇,软件业该怎么做?

最好的按期交付激励应该落到平时
过度强调如期交付的奖励会忽略质量
及时的会商解决技术实现问题
持续对里程碑计划进行维护
根据前端开发、后端开发和测试的主要专业分部建立细化的专业里程碑
制造业的规律提供线索
从建筑工程行业寻找灵感
需要建立另外一套计划和跟踪系统
进度要素重新纳入敏捷开发的管理范畴
按期交付的激励
跟踪、响应和及时沟通
软件研发的关键里程碑
将进度要素纳入敏捷开发
80%以上的APP更新频度在两个月以上
预测完成特性开发量相对容易
迭代更新周期相对稳定(2-4周)
软件业如何更好地控制项目进度和周期
敏捷开发中的项目期限控制问题
任向晖:敏捷中的期限之殇,软件业该怎么做?

该思维导图由 AI 生成,仅供参考

你好,我是明道创始人任向晖,上期内容跟大家分享了敏捷开发中项目期限控制的问题,以及其他行业带来的启发。今天,想跟大家聊聊想要更好地控制项目进度和周期,软件业该怎么做?

1. 将进度要素纳入敏捷开发

其实敏捷开发宣言中也并没有完全抛弃进度,它只是说响应变化要优先于遵循计划。而因为迭代更新的周期相对稳定(2-4 周),所以看起来敏捷开发模式没有延期的问题。再不济也是割舍了一些完不成的特性,作为一个不算成功的迭代来复盘。
预测在 2-4 周内能够完成的特性开发量相对容易,稍有经验的 ScrumMaster 都能够基本估准确。但并非所有的软件开发迭代都是这么短的周期。在新版本开发、复杂的企业 SaaS 特性开发中,一个迭代经常需要超过一个月,再加上必要的测试和灰度发布,可能轻易超过两个月。我统计了一些常用 APP 的版本更新历史,发现 80% 以上的 APP 更新频度在两个月以上。
所以,我们必须要把进度要素重新纳入敏捷开发的管理范畴内。
这意味着,看似简洁的 SCRUM 开发看板,在 In Process(开发中)这一栏中的任务内容,需要建立另外一套计划和跟踪系统才能实现更可靠的进度控制。
而在敏捷开发之外,传统的软件开发计划和建筑工程项目管理相比,大多也欠缺详尽的进度计划,而只是笼统的定义了几个粗放节点。如果是业务部门人员和外包客户达成协议,软件工程人员往往在交付时间要求上缺少发言权。很多软件外包项目的所谓开发交付计划都是根据客户要求的时点往前倒推而已。很多时候,别说客户了,就连自己人也很容易拿交付的时点来倒逼开发团队。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

敏捷开发中的项目期限控制是软件业中的重要问题。任向晖在文章中分享了他的观点,指出敏捷开发并没有完全抛弃进度控制,而是强调响应变化优先于遵循计划。他提出了软件研发的关键里程碑应该如何定义,并介绍了根据迭代总期限进行倒推的方法,以实现敏捷开发中的响应变化原则。此外,他强调了在新产品和项目研发过程中,除了具体的模块定义和页面组件定义带来的开发工作时间计划外,还需要留下足够的项目整体架构时间。文章深入浅出地为软件研发团队提供了实用的管理方法和思路。此外,任向晖还强调了在研发过程中,跟踪进度、响应问题和及时主动沟通是保证进度的基本手段。最后,他提出了对按期交付的激励问题的看法,认为过度强调如期交付的奖励会忽略质量,而最好的按期交付激励应该落到平时,给团队成员庆祝small win的机会。文章内容丰富,为软件研发团队提供了有益的管理经验和思路。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《技术领导力实战笔记》
新⼈⾸单¥98
立即购买
登录 后留言

全部留言(1)

  • 最新
  • 精选
  • 易林林
    敏捷的期限之殇,很考验一个管理者对于敏捷开发的理解深度和实施能力。 在敏捷开发过程中,要考虑敏捷开发产生的背景,为什么而生?它是为了更高效的综合利用各方面的项目资源(主要是人力和财力),基于传统软件设计模型(例如瀑布模型)的缺陷而生的。 那么,实际上要想能在敏捷开发领域有更强力的扎根,必须得了解传统软件设计模型的弊端,也得充分了解其优势,使优势得到更大更多的发挥,通过敏捷开发的几个重要的点来弥补其中的弊端。 最近经常和朋友、同事聊天,好多人都说传统设计模型没什么用,敏捷开发才是王道,我根据他们的描述来看,对于敏捷开发大多是东鳞西爪的片面应用,很难形成自有的思维和体系。 在我看来,敏捷开发只是一种思维和概念,没有特定约定俗成的东西,遵循了就一定能用好,而是要综合以前项目管理经验的积累和当前公司的开发环境进行动态的调整。就拿开发环境来说,领导的远见,管理层的执行力,员工的意识和工作能力等等各方面进行评估,拿出切实有效的敏捷开发模式。 谈到站立会议,个人觉得不一定是每天都要完成这样的规则,如果流于形式,大可不必。管理者只要在进行敏捷开发管理的过程中,能够进行高效而有效的沟通,也可以通过软件根据、通信工具进行管理,敏捷开发方面有大成的管理者,会去发现规则,利用规则,而不是原原本本的利用规则。
    2019-03-29
    1
    15
收起评论
显示
设置
留言
1
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部