何为敏捷开发？

zexho994
719 阅读9分钟

思考

  • 怎么用敏捷模式学习敏捷开发模式

科普：何为敏捷

记住最重要的一句话： 敏捷 = 价值观 + 原则 + 符合原则和价值观的方法

敏捷5个价值观

  1. 个体和交互 胜过 过程和工具
  1. 可以工作的软件 胜过 面面具到的文档
  • 不必要的文档,例如:
    • 交接类文档:
    • 提测单: 因为开发测试工作在一起
  • 必要的文档,例如:
    • 重要的方案设计和文件

  1. 客户合作 胜过 合作谈判

  2. 响应变化 胜过 遵循计划

  3. 虽然右项有价值,但是我们更加看重左边

敏捷12原则

  • 第一条: 我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意

早不等于快.快是不顾质量而追求速度,早是指版本迭代的内容更细化,提早交付的时间.

  • 第二条: 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势

灵活应对，对应价值第4点

  • 第三条: 经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好

对应原则第一条

  • 第四条: 在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。

对应价值第一点

  • 第五点: 围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作

保持团队时刻处于敏捷的状态，个人认为这是最难的一点

  • 第六条: 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。

对应原则第四条

  • 第七条: 工作的软件是首要的进度度量标准
  • 第八条: 敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度

所以加班是不可以取的，恒定的开发速度开发人员好的状态

  • 第九条: 不断地关注优秀的技能和好的设计会增强敏捷能力

不断提高团队的硬实力。例如目前采用的午间分享，大分享。

  • 第十条: 简单——使未完成的工作最大化的艺术——是根本的
  • 第十一条: 最好的构架、需求和设计出自于自组织的团队
  • 第十二条: 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整

基于敏捷的方法

  • 极限编程
  • Scurm
  • 特征驱动开发
  • 动态系统开发
  • 自适应软件开发
  • 水晶方法

规模化敏捷方法: SaFe,Less,

技术实践 :测试驱动开发

==具体的方法的说明,阅读敏捷的方法==

==具体的每个点的优缺以及使用场景后续补充==

知识储备：敏捷方法

在采用方法前,需要提前了解这3个点:

  1. 这个方法可以解决什么样的问题 （为什么要用敏捷？）
  2. 有没有使用前提 （用敏捷需要先做哪写准备？）
  3. 有没有什么相应的使用规则

方法也不是随意可以使用的,方法有方法的约束,如果不遵守这些约束,可能只会适得其反.

Scurm为例

约束条件

  • 迭代计划会议开始前,产品负责人需要准备好需求条目,是需求达到准入标准
  • Scrum 讲究实践盒,包括迭代的周期,各个会议,这些都要遵守时间盒的约定

不遵守第一条,避免不了节奏被打乱

不遵守第二条:团队被耗在各个会议上,会议效率又很低,容易厌烦

正式工作：开始推进敏捷

如何在团队中启用敏捷，需分步骤，且环环相扣。

大致划分为： 评估 -> 试点 ->推广

1. 评估诊断

对当前企业进行一次清晰地整理,很多企业采用敏捷后效果不佳,或者起了副作用,很大的原因是缺少了评估诊断这一步.评估诊断可以采用四步法

第一步: 挑选代表性项目

  • 小项目

  • 中项目

  • 大项目

==之所以需要多种类型的项目,是为了清楚各个团队或不同类型的项目存在哪些不同或相同的问题吗?==

第二步: 访谈评估

对各个项目的成员进行访谈,访谈的内容包括但是不限于:

  • 项目流程
  • 组织
  • 人员技能
  • 度量
  • 技术

目的是为了有目的性的探查项目的痛点

这一步需要大量的个体交互过程,对应了敏捷的价值的第一条;个体交互胜过过程和工具.

第三步: 制作转型的计划

根据访谈的结果,确定团队的痛点,

比如团队存在跨部门,跨团队沟通不畅上,要考虑团队组织的问题.考虑组织变革.

如果是问题集中在开发完成到上线这段时间,计划考虑建设 DevOps 流水线.

第四步: 沟通

与团队负责人,成员以及负责敏捷推进的人员沟通.就指定的计划达成一致.

一定要达成一致才进行后续的动作,因为敏捷最难的一点就是成员接受敏捷

如果想要已团队为单位,而不是企业.可以省略第一步

2. 团队敏捷试点

为什么要进行试点,而不是整个企业都推行敏捷,因为敏捷是有特异性的,不同企业的敏捷方案可能都不同,因从小团队进行试验,根据推行后的效果来进行经验积累,找到合适该企业的方案.

试点分为两步,试点前准备和试点推进过程.

2.1 试点前准备

  1. 找到符合特征的团队
  2. 业务价值高或者短期内会给团队带来很大收益的

针对第二点,更好的效果可以起到更大的正面影响,侧面提高其他团队的兴趣.

这是更加详细的方法:

1.选择独立的项目，规模在5~9人，尽量避免选择团队之间交叉依赖的项目，避开不必要的复杂性，增加试点成功率；可以选择大项目中的一个小团队做试点
2.团队尽量在一起
3.选择在业务主航道上的项目做试点，不要选择那些最关键的项目，选择主航道上重要程度为中等的项目
4.项目周期不能太短，也不要太长
5.最好选择新产品开发项目，而不是维护类项目
6.选择纯软件项目做试点，试点见效后再考虑硬件项目

团队尽量两个以上,孤品风险大,且团队数量多有对照作用.

前期工作:

  • 组织和人员 : 最重要,关键点,'高内聚,低耦合'.
  • 管控治理规则: 制定一些关于配合敏捷的规则
  • 需求范围
  • 架构
  • 敏捷方法和工具: jira,Trello,禅道等
  • 办公环境设施

2.2 试点推进过程

  • 制定"社会契约" --形成约束和激励机制

所谓社会契约,就是大家一起约定好的一些规章制度.这样可以后续发现问题做到"对事不对人"

  • 开展回顾会议 --引导团队的自主性(会议的时间盒不能超过1.5小时)

    会议内容可以围绕三个点:

    • 团队工作中做得好的地方是什么?
    • 做的不好的地方是什么?
    • 除此之外,还有什么疑问?

    比如每个人用白纸写下每个答案,最后统一,做得好的继续保持,做的不好的点大家头脑风暴去想怎么改善.然后解决大家提出的疑问.

  • 成绩墙和错题集

    记录推行敏捷时，记录自己的心情曲线，记录取得的成绩和错误。侧面也是代表了团队的成长。

当然，可用的方案远不止这些，可以从这些上借助起理念，活用在自己的团队里。

3. 大规模推广

目前方向主要在团队内敏捷,所以不过多涉及这方面理论.

==待补充： 主要关于如何在一个试点取得成功后，其他团队是直接复制过去？ 还是怎么借鉴试点团队的成功呢？==

  • 规模化推广 不等于 直接复制试点经验

试点的目的不是为了找到一个绝对方法,而是为了指明一条相对的道路,保证不会走歪.

  • 重要一点,试点是团队内部的敏捷,规模化还需要注重团队之间的敏捷

团队就的敏捷涉及到的点更多更复杂,协同管理,多个迭代,多个产品下的计划和安排等.

零散知识点（待归纳）

  • 在敏捷中，计划的制定是渐进明细的，即近期的计划可以具体到可实施的细节，而远期的计划则是粗略的

  • 在敏捷中，不是不接受新的需求插入，当时要去除掉同等量的需求

疑问点

  • 为什么敏捷开发相对瀑布,人员水平要求更高?

    团队成员需要快速响应,灵活应对需求

  • ==什么是DevOps==

  • ==什么什么是特色团队?人员怎么分配==

  • 什么是时间盒

    时间盒就是将各个任务的时间规定好

  • 业务是指什么,是指产品经理,需求分析这些吗?

    业务可以抽象的理解开发的上游，例如产品，交互等

  • 开发前期的接口文档流程要不要省略?

    根据实际场景来,评估文档为产品带来的价值.最好不要省略,可以做适当的裁剪.

参考资料

wiki - Agile software development

极客时间-说透敏捷

推荐阅读

《Scrum敏捷项目管理》

《硝烟中的Scrum与XP》

《敏捷回顾:团队从优秀到卓越之道》

《敏捷教练：如何打造优秀的敏捷团队》

avatar
文章
阅读
粉丝