首页 > 代码库 > Chapter 6 敏捷流程

Chapter 6 敏捷流程

Chapter 6 敏捷流程

1.敏捷的定义:

   敏捷是一系列价值观和方法论的集合。

2.敏捷开发的原则:

   ①尽早并持续地交付有价值的软件以满足顾客的需求。

   ②敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势。

   ③经常发布可用的软件,发布间隔可用从几周到几个月,能短则短。

   ④业务人员和开发人员在项目开发过程中应该每天共同工作

   ⑤以有进取心的人为项目核心,充分支持信任他们。

   ⑥无论团队内外,面对面的交流始终是最有效的沟通方式。

   ⑦可用的软件是衡量项目进展的主要指标。

   ⑧敏捷流程应能保持可持续的发展。领导、团队和用户应该能按照目前的步调持续下去。

   ⑨只有不断关注技术和设计,才能越来越敏捷。

   ⑩保持简明——尽可能简化工作量的技艺——极为重要。

   ?只有能自我管理的团队才能创造优秀的架构、需求和设计。

   ?时时总结如何提高团队效率,并付诸行动。

3.敏捷的步骤:

  ①找出完成产品需要做的事情——Product Backlog。

     Backlog:“积压的工作”、“待解决的问题”、“产品订单”等。

     产品负责人领导大家对于这个Backlog中的条目进行分析、细化、理清相互关系、估计工作量等工作,单位为“天”。

  ②决定当前的冲刺(Sprint)需要解决的事情——Sprint Backlog。

     产品的任务呗进一步细化了,且单位为“小时”。

     订单上的任务是团队成员根据自己的情况来认领

     团队成员能主导任务的估计和分配,他们的能动性得到较大的发挥。

  ③冲刺(Spring)。

     外部人士不能直接打扰团队成员。

     较好的平衡了“交流”和“集中注意力”的矛盾。

     冲刺期间,团队通过每日例会来进行面对面的交流,大多都是站着开的因此又称为“每日立会”,强迫每个人向同伴报告进度,迫使大家把问题摆在明面上。

        我昨天做了啥?

        我今天要做啥?

        我碰到了哪些问题?

     用简明的图表展现整个项目的进度。

      eg1.燃尽图(想象我们把一堆Backlog的木头给烧光)。

          2.看板图(把一堆任务从最初的“待定”推动到“工作中”等各个状态,直至“完成”)。

      冲刺阶段是时间驱使的,时间一到就结束,有效的切断了各种延期想法的后路,很高明。

  ④得到软件增量版本,发布给用户。在此基础上进一步计划增量的新功能和改进。

4.敏捷流程的问题和解法:

   ①怎样在计划(Backlog)中体现依赖关系?

   ②把一个任务从产品层级的描述逐步细化到技术实现层面,是很需要技术能力和交流能力的。

   ③每日立会不能流于形式,应该定义好任务究竟是什么。并在每个任务中记录我们完成这个任务还需要多少时间。

   ④程序员在写完功能后,还有的一些比较艰难和底层的长期任务。

   ⑤测试人员在一个冲刺中怎么工作呢?

   ⑥在得到一个增量的软件发布,但是谁来验证这个增量是否满足了事先的计划?如果程序猿们在冲刺的过程中发现了新问题,要改进原来的计划,是好事还是坏事?

5.敏捷的团队:

   敏捷对团队的要求:

   ①自主管理:

      自己挑选任务,完成后还要总结不足,提出改进,并且自己要实施这些改进。

   ②自我组织:

      每个人要联合起来对项目负责,有人工作落后了还要帮助他改进,项目缺少某类资源还要自己顶上去。

   ③多功能型:

      每个人都要全面的负责就是啥都会一点。

6.敏捷总结:

   敏捷是一股思潮,或者说是一种价值观,它涵盖了好几种软件开发的方法论;这些方法论又是建立在许多行之有效的作家实践方法之上的。

   敏捷不是万能的,敏捷的方法能帮助你更早的谁知道你是否能如期完成任务。

   敏捷的方法(迭代的方式)能帮你尽快让用户看到项目的部分价值。

 

 

 

 

 

 

Chapter 6 敏捷流程