美文网首页
构建之法-6-敏捷流程

构建之法-6-敏捷流程

作者: BigLong | 来源:发表于2019-05-11 11:27 被阅读0次
目录

好像现在开发软件都流行敏捷模式,项目经理要是不懂得敏捷开发流程感觉就像是过时了一样。但是敏捷优劣并存,用不好的话就会适得其反。其实,我认为敏捷流程更有点极限压榨程序员的意味。


6.1 敏捷的流程简介

敏捷的流程简介.png
  • 现有做法vs敏捷的做法
    敏捷的做法更像是随意一点,开心就好。

    现有做法vs敏捷的做法
  • 敏捷的开发原则

  1. 尽早并持续地交付有价值的软件以满足顾客需求
  2. 敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势
  3. 经常发布可用的软件,发布间隔可以从几周到几个月,能短则短
  4. 业务人员和开发人员在项目开发过程中应该每天共同工作
  5. 以有进取心的人为项目核心,充分支持信任他们
  6. 无论团队内外,面对面的交流始终是最有效的沟通方式
  7. 可用的软件是衡量项目进展的主要指标
  8. 敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续合作下去
  9. 只有不断关注技术和设计,才能越来越敏捷
  10. 保持简明—尽可能简化工作量的技艺—极为重要
  11. 只有能自我管理的团队才能创造优秀的架构、需求和设计
  12. 时时总结如何提高团队效率,并付诸行动
  • 敏捷的步骤
    敏捷的步骤

第一步:找出完成产品需要做的事情—Product Backlog。
第二步:决定当前的冲刺(Sprint)需要解决的事情—Sprint Backlog
第三步:冲刺(Sprint)
第四步:得到软件的一个增量版本,发布给用户


6.2 敏捷流程的问题和解法

敏捷流程的问题和解法

说一下第三点:每日例会。基本上敏捷开发需要经常开例会讨论进度,汇总信息,例如:

我昨天做了啥
我今天要做啥
我碰到了哪些问题

但是每日例会经常会出现一些效率不高的发言。例如:

我昨天掰棒子
我今天继续掰棒子
我没碰到困难

这样的发言毫无疑问是没有意义的。所以就需要定义任务究竟是什么?

每个人的任务必须是明确定义的,狗熊们不能笼统地说“我在掰棒子”,而是要说明标号为123的棒子现在是什么状态,你做好之后交给谁了。

同时,在每一个任务上记录完成这个任务还需要多长时间?

已经花了多少时间虽然重要,但那不是关键(那是沉没成本),关键是要看我们离最后目标有多远。就像某部门展览“反腐成果”给群众看—“已经抓出来N个腐败分子”固然解恨,但关键是“还剩多少在台上”,这个问题不说明,再抓多少个都不解决问题。

最后说一下燃尽图,下面是一个实际项目的燃尽图,有三个每天跟踪的时间值:

实际剩余时间(Remaining Hour):每个团队成员所有任务的剩余时间的总和。
预估剩余时间(Projected Remaining Hour):根据每个人每天的理论进度推算的剩余时间。
实际花费时间(Completed Hour):实际花费的时间。

实际项目燃尽图

6.3 敏捷的团队

敏捷的团队

敏捷看起来很舒服,管理也方便,但是一个强势的Scrum Master是敏捷能否实施成功的关键。这个角色绝不是招呼大家开开会,记录每个人的进度而已。


6.4 敏捷总结

敏捷总结
  • 敏捷不特别

Sprint/Scrum对项目的众多需求采取分而治之的办法,能让相关人员集中精力,在一定期限内解决部分问题。它强调短时间的迭代(Iteration、Time-box),在多次迭代中不断总结,改进团队的流程和产品功能。

  • 敏捷流程的经验教训

这里有一些实践者的经验教训:

  1. 敏捷宣言表明的是一些优先级,不必当作圣旨或者教条来争论。
  2. Scrum Master不是一个官,而是一个没有行政权力的沟通者,就像微软的PM那样。他/她同时还要在团队中做具体的工作。直接把原来的“经理”变成Scrum Master,大多行不通。
  3. 一些项目需要很多暗箱操作和政治角力才能搞定,Scrum会把这些矛盾都摆到明处。这有好处,也有风险。
  4. 在复杂的项目里,要让一线团队成员做决定。
  5. 创业公司的团队其实经常是运行在Scrum 的模式中(只不过大家太忙,没工夫论证自己到底有多么Scrum)。
  6. 在Scrum计划阶段的估计不是一个“合同”,领导们不要把它当成一个合同。估计总是不准的。坚持短期的Sprint,这样即使不准的估计也不会有大的损害。
  7. 不要和管理层谈“流程”,他们只关心“结果”。
  8. 在大型团队、跨地区的团队,或者复杂项目中,Scrum并没有非常完美的答案,Scrum的创始人也承认这一点。

6.5 敏捷的一些相关问答

敏捷不是说开发就不用搞计划、搞文档、上来就写代码等等
——鲁迅没说过

  • 敏捷的适用范围

    适用范围
  • 什么时候适合选择敏捷

    什么时候适合选择敏捷

相关文章

  • 构建之法-6-敏捷流程

    好像现在开发软件都流行敏捷模式,项目经理要是不懂得敏捷开发流程感觉就像是过时了一样。但是敏捷优劣并存,用不好的话就...

  • 构建之法

    个人能力的衡量(开发的工作量和质量的衡量):通过代码行数或功能点来衡量;花费的时间;交付的代码有多少bug来衡量;...

  • 构建之法-5-团队和流程

    只有一个好的团队,才能做成大事。——鲁迅没说过 5.1 非团队和团队 提出了一个问题:什么是一个团队?随便凑一伙人...

  • 敏捷开发不是万能的(Mar.30 2015)

    @(Diary) 谈谈今天读《构建之法》关于敏捷开发一部分时候的一些想法,因为还没做总结笔记,所以原文怎么说的也不...

  • ACP考试中的关键知识点

    一、敏捷原则和理念 1、敏捷的4条宣言就是敏捷之道,12条原则可以被视为敏捷之法。 2、常见正向的关键词:价值、消...

  • 构建之法-2-个人技术和流程

    成为一名合格的软件工程师 2.1 单元测试 2.1.1 为什么要写 团队合作里,每个工程师都有自己负责的模块,我们...

  • 《构建之法》整理

    第2章 个人技术和流程 单元测试 单元测试 回归测试 回退操作 效能分析工具 先用抽样的方法找到效能瓶颈所在,然后...

  • 【笔记】构建之法

    第二章:个人技术和流程 要点: 单元测试,回归测试,效能分析,基于个体的软件开发流程(PSP) 单元测试的构建标准...

  • 读《构建之法》

    开篇提到的现实世界中软件工程师的职业发展与教科书上经典的瀑布模型刚好相反的观点,让人眼前一亮。 学校里教的开发流程...

  • ThoughtWorks暑期特训——任务五 ·学习笔记

    一 、编程精进之法 “敏捷”之TDD TDD(全称Test Driven Development)测试驱动开发,是...

网友评论

      本文标题:构建之法-6-敏捷流程

      本文链接:https://www.haomeiwen.com/subject/bkataqtx.html