2017-04-07 09:06:17 huver2007 阅读数 3071
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

猪和鸡的故事

关于鸡与猪的故事有很多种版本,被用在各种不同的场合,管理的、营销的、敏捷开发的,大体相同,但稍有差异。

故事一:有一只鸡和一头猪合伙开饭店,双方各占50%股份。鸡对猪说:“我每天下一个蛋用来炒菜,你每天割一块肉下来炒菜”,猪认为合理:“同意”。饭店后来开大了,这个饭店的股权最后会归谁所有呢?毫无疑问会归鸡,因为猪最后一定会被割死!

故事二:一天,一头猪和一只鸡在路上散步。鸡对猪说:“嗨,我们合伙开一家餐馆怎么样?”猪回头看了一下鸡说:“好主意,那你准备给餐馆起什么名字呢?”鸡想了想说:“叫‘火腿和鸡蛋’怎么样?”“那可不行”,猪说:“我把自己全搭进去了,而你只是参与而已。”

前面一个故事往往被用作在管理和营销上来说明一些道理,而后面这则故事应用在敏捷开发,用来说明不同角色的职责。在Scrum过程中,“猪”是在Scrum过程中全身投入项目的各种角色,他们在项目中承担实际工作。他们有些像上边那个笑话里的猪,要把自己身上的肉贡献出来。“鸡”并不是实际Scrum过程的一部分,但是必须考虑他们。

采取Scrum模式最大的优势在于以口头的面对面沟通取代文档沟通,来保持沟通的高效与快捷,但如果参加迭代会议的人员过多时,会使沟通效率打折扣,这个时候就要求参与Scrum会议的人员明白各自的职责,关注各自的焦点,以避免限于冗长的会议泥潭中。Scrum本身非常关注这点,也就有了上面的鸡与猪的故事。从这个故事引申出来这样的结论:猪类才是团队的核心,拥有较大的话语权;而鸡类仅仅为部分参与者或者关联者,拥有较少的话语权,并明确规定在类似于站立会议中鸡类人员不得讲话、评论等。

在Scrum团队中,一般ScrumOwner(产品经理)、ScrumMaster(项目经理)、Developer、需求分析师为猪类角色,而测试工程师、UI工程师、QA、客户等为鸡类角色。Scrum教练参与会议以控制迭代及其过程。但实际项目中往往是猪类角色没有发言,鸡类角色喋喋不休。

2018-12-17 14:08:02 Choerodon 阅读数 70
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

本文是 Choerodon 猪齿鱼敏捷管理系列文章的第三篇。在上一篇文章《Choerodon猪齿鱼敏捷管理实践(二)——冲刺管理》中介绍了在敏捷开发中如何使用Choerodon猪齿鱼来管理需求和冲刺。当进行敏捷开发时,与之相关的Scrum会议穿插在整个迭代开发中,本篇将重点介绍Choerodon猪齿鱼敏捷管理对各种会议是如何进行管理支持的。

文章主要内容:

  • Choerodon的需求和冲刺管理回顾
  • Choerodon对敏捷各类会议的管理支持
    • 计划会
    • 每日站会
    • 评审会
    • 回顾会
  • 总结

Choerodon的需求和冲刺管理回顾

Choerodon敏捷管理中,我们使用用户故事地图和待办事项进行需求和冲刺管理。在敏捷开发实践中,整理需求和规划冲刺是开发中的重要阶段,通过规划管理可以使开发达到以下目标:

  1. 可视化管理团队
  2. 明确开发需求优先级
  3. 明确各个任务项
  4. 可视化任务进展情况

明确需求和冲刺管理的目标后,我们会有四个敏捷会议贯穿整个开发过程,需要开发团队的每个成员参与其中,此时也可以使用Choerodon敏捷管理进行会议的管理支持来达到团队的开发目标。

Choerodon对敏捷各类会议的管理支持

标准的敏捷流程包含了四个会议,即计划会、每日站会、评审会和回顾会。我们在实际开发中会结合Choerodon猪齿鱼平台来管理支持团队中的敏捷会议。

计划会

在每个Sprint进入开发之前,团队将会召开Sprint计划会议。

在会议之前,产品负责人会在Choerodon敏捷管理中使进行需求和冲刺的规划,并且排列好Backlog的优先级,为计划会议做准备。

在Sprint计划会议的前半段,根据Choerodon敏捷管理计划冲刺中的Backlog,产品负责人会从优先级最高的功能依次为开发团队进行讲解。然后,团队成员针对Backlog中的待开发功能提出问题,团队就该问题进行展开讨论,直到这个功能相关的问题全部解决,再进入下一个功能的讨论。

如果Backlog中的待开发功能在此迭代中已经饱和,或者有阻碍需要在进行重新计划的,产品负责人会把它从迭代计划拖动至待办事项列表进行重新规划。

在Sprint计划会议的下半段,开发团队会讨论这些确定开发的功能问题,这时可以使用Choerodon敏捷管理的报表:迭代速度图。

迭代速度图可以看出每个开发团队在每个迭代中完成任务的情况,大致可以得到一个团队迭代中任务的饱和点,然后开发团队根据这个数据决定下一轮迭代能够完成的工作量。

之后,团队成员对计划中的Sprint列表中的故事进行拆分,将每个故事拆分成一个一个的任务,并估算每个故事的故事点。一旦迭代开始,这些迭代任务将不会发生大的变化。

通过敏捷的计划会议,开发团队和产品负责人可以确认共同的迭代目标和价值。

每日站会

Choerodon敏捷管理中的活跃冲刺看板可以用来进行开发迭代任务可视化管理,每个任务下的子任务、经办人、任务状态、任务类型都在看板中显示,每一个开发人员都可以看到团队开发的流程进度。

每日站会是敏捷开发中用于开发团队沟通了解进度的会议,可以把看板泳道切换为经办人泳道,这样可以清楚每个人身上的任务进度。

每日站会中,开发团队成员根据看板中自己的任务进度和大家进行交流:我昨天做了什么,今天要做什么,我有遇到什么困难。可以一边交流一边拖动看板上的卡片(或者在站会开始前就已经根据自己情况进行卡片拖动完成),团队成员可以对大家的各种任务状态和受阻问题进行了解。

在每日站会拖动完团队成员的卡片后,会切换到Choerodon猪齿鱼敏捷管理看板中的工作台页面,团队会共同维护一张“燃尽图”(Burn Down Chart),即所有任务的累积剩余时间随开发进程与日递减的图形,用以观察和预测所有任务是否会按期完成。

每日站会中展示燃尽图,也是向团队成员展示一个迭代开发的任务或者时间的总体完成情况,可以指导团队随时调整迭代计划与速度。

评审会

每个Sprint结束时,都会有一个Sprint评审会议。评审会议最重要的工作是演示功能和成果,验证用户故事的实现场景,并接受评价。

所以在评审会开始之前,开发团队会检查Choerodon敏捷管理活跃冲刺看板中的故事完成情况,根据完成任务后的测试情况拖动卡片到看板已完成的列,把未完成的任务进行整理。

团队成员整理好看板中的已完成和未完成的任务时,我们就可以完成Sprint。这个迭代中未完成的遗留问题我们可以移动到待办事项中进行重新计划,对于已完成的任务,则会在评审会中进行演示验收。

评审会中,团队成员会对本次迭代中已完成的功能进行演示,产品负责人进行验收。团队成员需要接受产品负责人的评价,再针对已有的功能进行优化或者直接验收成功。

评审会后产品负责人会根据验收成果在Choerodon敏捷管理的待办事项中进行下个Spring的优先级调整,重新规划将要进行的新的Sprint。

回顾会

在评审会之后,开发团队会进行回顾会。回顾会的重点是团队检视与调整,进行工作问题和改进点的反馈。回顾会可以提供一个很好的机会给开发团队,来讨论什么方法能起作用而什么不起作用,并一致通过改进的方法。

在进行敏捷回顾会议时,开发团队会使用Choerodon猪齿鱼Wiki管理中进行会议记录,创建时使用“敏捷回顾会议记录”的文档模板,可进入已经设置好的回顾会议文档编辑页面。

回顾会议中,开发团队会提前根据本迭代的达成目标、产品功能、敏捷流程、需求管理等方面进行准备,针对开发团队在实施敏捷开发中的各种进步和问题进行讨论。可以指派一位团队成员进行会议记录,在已有的Wiki文档模板中记录大家提出的各种问题。

然后,团队成员会共同讨论找寻这些问题出现的根本原因,提出大家认同的解决方案,统一在下一个Sprint中改进,并在下一个回顾会议上评审改进问题的结果。

在Choerodon猪齿鱼知识管理中的回顾会文档,可以记录开发团队关于每个迭代的各种问题的思考,帮助团队不断调整敏捷实施方案,突出敏捷开发的效果。

总 结

回顾整篇文章,我们继上篇进行了简单的敏捷主要规则介绍,同时详细描述了Choerodon猪齿鱼是怎样管理支持敏捷的各个会议,通过使用Choerodon猪齿鱼不断规范、记录开发过程,实现敏捷的开发,希望可以对大家有所帮助。

参考资料:

更多关于敏捷管理的文章,点击可阅读 ▼

关于Choerodon猪齿鱼

Choerodon猪齿鱼是一个开源企业服务平台,基于Kubernetes的容器编排和管理能力,整合DevOps工具链、微服务和移动应用框架,来帮助企业实现敏捷化的应用交付和自动化的运营管理的开源平台,同时提供IoT、支付、数据、智能洞察、企业应用市场等业务组件,致力帮助企业聚焦于业务,加速数字化转型。

大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:

2010-03-14 22:11:00 superch0054 阅读数 1088
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。Scrum在英语的意思是橄榄球里的争球
虽然Scrum是为管理软件开发项目而开发的,它同样可以用于运行软件维护团队,或者作为计划管理方法

Scrum定义了许多角色,根据猪和鸡的笑话分为两组,猪和鸡
  一天,一头猪和一只鸡在路上散步,鸡看了一下猪说,“嗨,我们合伙开一家餐馆怎么样?”,猪回头看了一下鸡说,“好主意

,那你准备给餐馆起什么名字呢?”,鸡想了想说“餐馆名字叫火腿和鸡蛋怎么样?”,“我不这么认为”,猪说,“我全身投入,

而你只是参与而已”


冲刺订单(sprint backlog)

燃尽图(burn down chart)是一个公开展示的图表,显示当前冲刺中未完成的任务数目,或在冲刺订单上未完成的订单项的数目。

不要把燃尽图与挣值图相混淆。


以下是一些Scrum的通用实践:
  客户成为开发团队中的一部分。(例如客户肯定对开发的结果真正感兴趣。)和所有其他形式的敏捷软件过程一样,Scrum有频

繁的包含可以工作的功能的中间可交付成果。这使得客户可以更早的得到可以工作的软件,同时使得项目可以变更项目需求以适应不

断变化的需求。频繁的风险和缓解计划是由开发团队自己制定。
– 在每一个阶段根据承诺进行风险缓解,监测和管理(风险分析)。  计划和模块开发的透明
– 让每一个人知道谁负责什么,以及什么时候完成。频繁的利益所有人会议,以跟踪项目进展
– 平衡的(发布,客户,员工,过程)仪表板更新
– 利益所有者更新
– 你必须拥有预警机制,例如提前了解可能的延迟或偏差。没有问题会被藏在地毯下。认识到或说出任何没有预见到的问题并不会

受到惩罚。在工作场所和工作时间内必须全身心投入。
– 完成更多的工作并不意味着需要工作更长时间。

2012-02-08 00:01:21 jingwenjingwen 阅读数 9
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师
这是敏捷开发一千零一问系列的第五篇。(之一,之二,之三,问题总目录)

本问题被评为某次课程最佳问题之一(每场2~4个)。

问题
怎样让团队成员完成从派活到主动要活?

方案
步骤0:

在一个传统团队中,多半是由一个人(一般是项目经理)估算、分配、监督任务完成。由于这个人处于鸡的角色(请参考百度“猪与鸡”),所以真正承担任务的人要冒任务被错误估算和分配导致绩效低下的风险,引起大家的不满。

按时完成了经理领导有方,延期了则总能找到一个临时工来顶缸,事情永远做不好。

步骤1:

“领导”和“管理”的区别在于后者利用权力行事,而前者亲自带领队员。

比如如果项目经理仍然估算和分配任务,但是会主动帮助认为估算不对、任务过难的人。传统上让项目经理估算和分配起于其能力超过一般人,而他只有帮助别人完成任务,才能让他的能力发挥出来,也能让别人有所收益。

完成步骤1后,人们就不会过于担心任务的难度。

步骤2:

把团队分解为1-3-9团队(参考松结对编程系列),安排师傅和徒弟,让师傅做第二级别的分配。

在1-3-9团队中,师傅对整个团队的成败负责,因此最难最重的活,一般他都会主动承担。从长远看,为了防止自己总是累得半死,他又会把自己的一部分技能教给徒弟们,让徒弟也能为自己分担一些工作。

此外由于末级团队规模较小(只有2~5人),人们极少冷漠地对待对方,相反地以兄弟相称,主动帮助乃至要活的概率更大。在心理学上,从众心理在人数众多的时候更容易发生,多数社会上“冷漠”事件的发生,不是路过的人太少,而是太多。

步骤3:

这个算是师傅的回报期了:师傅可以因为小组工作量变大而要求加人,所招聘的新人,其招聘、试用、培养环节,均由师傅负责。他会在这个过程中将文化根植于自己看中的弟子心中,而不是被迫接受领导送来的菜鸟或刺头。这样建立起来的团队更加稳固,人们更加乐于互相帮助。

如果团队早就存在了,可以从步骤1开始,逐渐过渡到步骤3。

很多人会说:“如果是新建的团队,一切都还好说,我直接用步骤3,但现在我们已经太晚了,已经有20个人了……”如果这样想,会在团队有200人的时候后悔:“倒霉,早知道20人的时候就动手了”。

所以,没有太晚,只有更晚。

案例
暂无

分析
1. 个体分离(有我)是人们不愿意主动要活的原因,因为人们觉得一旦自己要了活,付出的是自己,而受益的是别人(包括自己在内的团队有时候也被认为是“别人”)。应该首先破除这一点,形成团队工作的概念。

2. 责与权的分离是一个障碍,因为谁先破除“有我”的障碍,谁先需要付出。因此团队应该有一个机制保证多劳者多得。

所谓的“得”,未必是钱,因为很难计算;但可以是任何其他东西。比如经常帮助新人的,我们可以将其提拔为师傅,进而成为未来项目经理的候选人;经常帮助别人的,还可以给他几个下属,让他帮助一下(而这些下属自然也可以帮助他做更多事情)……等等,都可以称之为“多得”。

3. 有时候会感觉自己企业的老板或直属领导很失察,自己做了帮助别人的事情,未必会有回报。

其实不然,首先在没有帮助别人前,怎么知道领导是这样的想法呢?或许领导正愁没人愿意带个头呢,以至于他想提拔个副组长,都没有个合适的人选。

其次,不要总想着在这里就得到回报,因为没有回报,所以我也就不帮助别人了。或许在这里,或许在下一家公司,或许被你帮助过的新手在下家公司推荐了你,或许……俄狄浦斯命中注定会杀死父亲,因此父亲把他扔到野外,没想到被人所救,长大后参加一个运动会,不小心把自己的父亲一标枪(或者铁饼?忘了)给杀了……世界运行的规律,不要用小学数学分析。因做到了,自然会结果。

4. 不要想有一家企业,大家互相帮助,在那里自己也会主动要活,但这里吗……算了。

这样的企业是找不到的,因为即使有,他也不让我们这些从来不自己要活的人去。怎么办?从头就做一个主动的人,作为强者,帮助别人作为弱者,寻求帮助(至少不拒绝帮助),最后会证明自己的企业就可以被改造成哪家人人互相帮助的企业。

这就叫共振。
2010-09-24 16:12:00 bihailan123 阅读数 486
  • SCRUM敏捷开发视频教程

    SCRUM敏捷开发视频教程,该课程为你分享SCRUM敏捷开发,理解敏捷的本质,认识中国IT行业对敏捷的挑战,学会让敏捷落地的实用招数。 嘉宾介绍:张传波 1. 创新工场创业课程(敏捷课程)讲师 2.软件研发管理佳实践顾问(曾任华为某团队研发顾问) 3. 中国敏捷联盟《ADBOK》(敏捷开发知识体系)项目组成员 二十年软件开发、软件设计、需求分析、项目管理、部门管理、公司管理及过程改进等经验,亲历“无数”项目,涉猎建筑、通讯、互联网、电力、金融、制造业、政府等领域,熟悉软件生命周期的全部过程

    10423 人正在学习 去看看 CSDN讲师

任何人力流程都离不开人来执行,所以在讲解Scrum流程之前,有必要先把Scrum中的角色讲一下。

    一天,一头猪和一只鸡在路上散步,鸡看了一下猪说,“嗨,我们合伙开一家餐馆怎么样?”,猪回头看了一下鸡说,“好主意,那你准备给餐馆起什么名字呢?”,鸡想了想说“餐馆名字叫火腿和鸡蛋怎么样?”,“我不这么认为”,猪说, “我全身投入,而你只是参与而已”

    猪是全身投入项目和Scrum过程的人,有三种角色:产品负责人(Product Owner)、ScrumMaster、团队(Team)。


    鸡角色并不是实际Scrum流程的一部分,但是必须考虑他们。 敏捷方法的一个重要方面是使用户和利益相关者参与到过程中的实践。参与每一个评审和计划,并提供反馈对于这些人来说是非常重要的,管理者就属于鸡

在知道Scrum的主要角色后,我们看看下图中的过程图:它由Product backlog开始,经过sprint会议从Prdouct backlog挑选出一些优先级最高的故事(story)形成迭代的sprint backlog(一个sprint一般为1个月)。在sprint中会进行每日站会,迭代结束时会进行演示和回顾会议。


    第一次听到以上术语的可能不能很好的理解backlog和spring之类的东西,大家不用着急,以后会慢慢对每一个过程进行仔细讲解。

    以下将对一些术语进行简单介绍,以便大家现在开始逐步了解Scrum。

    【Backlog】

    Product Backlog

    在项目开始的时候,Product Owner要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog,一个最终会交付给客户的产品特性列表,它们根据商业价值来排列优先级。Scrum team会根据这个来做工作量的估计。Product backlog应该涵盖所有用来构建满足客户需要的产品特性,包括技术上的需求。高优先级的一些产品特性需要足够的细化以便于我们做工作量估计和做测试。对于那些以后将要实现的特性可以不够详细。

    Sprint Backlog

    Sprint Backlog 是Sprint规划会上产出的一个工作成果. 当Scrum team选择并承诺了Product backlog中要递交的一些高优先级的产品功能点后,这些功能点就会被细化成为Sprint Backlog:一个完成Product Backlog功能点的必需的任务列表.这些点会被细化为更小的任务,工作量小于2天。Sprint backlog完成后,Scrum team会根据它重新估计工作量,如果这些工作量和原始估计的工作量有较大差异,Scrum team和Product Owner 协商,调整合理得工作量到Sprint中,以确保Sprint的成功实施。

    【会议】

    Sprint Planning Meeting(Sprint规划会)

    根据Product Owner制定的产品或项目计划在Sprint的开始时做准备工作。Product Owner可以是客户或者客户代表或代理。对于产品型的公司,客户就是市场,Product Owner扮演市场代理的角色。一个Product Owner需要一个确定产品最终目标的远景,规划出今后一段时间产品发展的路线图,以及根据对投资回报的贡献确定的产品特性。他要准备一个根据商业价值排好序的客户需求列表。这个列表就是Prodct Backlog,一个最终会交付给客户的产品特性列表,它们根据商业价值来排列优先级。

    当为一个Sprint定义好足够多的Product Backlog,并且排列好优先级后Scrum就可以开始了,Sprint规划会是用来细化当前迭代的开发计划的。规划会开始的时候,Product Owner会和Scrum team一起评审版本,路线图,发布计划,及Product Backlog。Scrum Team会评审Product Backlog中功能点的时间估计并确认这些估计尽可能的准确。Scrum Team会根据资源情况看有多少feature可以放在当前的Sprint中。Scrum Team按照优先级的高低来确定开发的先后是很重要的。

    当Sprint backlog确定后,ScrumMaster带领Scrum Team去分解这些功能点,细化成Sprint的一个个任务. 这些任务就是细化的来实施这些功能点的活动. Sprint Planning的这个阶段需要控制在4个小时。

    Daily Scrum Meeting(每日站会)

    一旦计划阶段结束,30天周期的Sprint就开始了。ScrumMaster需要组织团队成员每天开站会. 这个会议是用15分钟的时间来让大家过一下scrum的状态。在会上,每个团队成员需要问3个问题:我昨天做了什么,今天做什么,遇到哪些障碍。谁都可以参加这个会议,但只有Scrum团队成员有发言权。这个会议的目标是得到一个项目的全局观,用于发现任何新的依赖,定位项目成员的要求,实时的调整当天开发计划.

    Sprint Review Meeting(Sprint评审会)

    在Sprint结束的时候召开Sprint评审会. 这个会议最多不超过4个小时.会议的前一半时间用来演示在这个Sprint中开发的产品功能给 Product Owner. Produc Owner会组织这阶段的会议并且邀请相关的利益相关者参加。 业务,市场,技术都要做相关的评审。由Product Owner来决定Product Backlog中的哪些功能已经开发完成 。会议的下半部分,是由Scrum Master和Scrum Team一起回顾当前的Sprint。团队评估大家在一起的工作方式,找出好的方式以后继续发扬,找出需要做的更好的地方,想办法提升。Sprint评审会结束后,新一轮的迭代又继续开始(中间最好修整半天或者隔个周末),迭代会一直继续,直到开发了足够多的功能去交付一个产品。

没有更多推荐了,返回首页