定制你自己的敏捷:良好的预估如何练成?

2017 年 12 月 28 日

本文要点

  • 速度(velocity)不是加速度,它是对能力的度量
  • 避免基于任务的预估
  • 通过探针(spike)的方式明确工作量
  • 计算故事(story)的数量代替预估的方式
  • 采用周期时间来优化你的预估

很多敏捷理论都假设团队会通过故事点(story point)来预估时间,这也是一种主流的预估方式。但我们通常所说的距离,是一个标准的、不会变化的单位。在项目开发中,与距离对应的概念是故事点,但是大部分团队内部中都没有自己的标准化的故事点,不同团队之间更是如此。其实可以换一种思路,考虑通过对故事进行统计的方式,或者使用周期时间(cycle time)来进行预估。这种情况下你甚至可能完全不需要估算开发速度。

这是教你如何定制你自己的敏捷系列教程的第 3 篇文章。这篇文章中主要介绍了如何预估以及何时进行预估。

在我参加过的每个项目当中,无论是我自己的项目还是其他组织的项目,总有人想知道项目的持续时间是多久。在你进行数量级预估的时候,这是个有价值的问题。你的团队可能这样答复你:“ 我们做过很多类似的项目。有一个花费了 3 个月,有一个花费了 13 个月。我们认为我们的需求跟之前花费了 3 个月的那个项目更加类似。但是,代码基础发生了变化,所以我们有个大致的猜想:‘ 大概需要 6 个月的时间,并且随着项目开始 1 到 2 周之后,我们对代码有更深入的理解,从而能进一步优化这个预估时间 ’”。

这是预估的第一步。但是据我所知,很多团队都采用故事点的方式来进行预估。这种方式可能会带来问题,最常见的就是因为人们对开发速度的错误预判。

速度是一种时间点能力的预估

速度与方向是紧密关联的。但很多情况下,人们会混淆速度和加速度之间的概念,加速度关注的是速度变化的快慢而不是速度本身。速度并不是加速度。

假设你在家周边通过走路或者跑步的方式来进行锻炼。你的锻炼目标是每天通过走或者慢跑完成 2 英里的距离。

通常春天、夏天或者秋天,天气比较好的情况下,你可以采用四英里每小时的速度跑完全程。你的慢跑会耗时 30 分钟左右。

但是,你准备每天都走或者慢跑,不管天气如何。当下雨的时候,你不进行慢跑,而采用走的方式。并且,你因为没有穿合适的跑鞋而走的更慢了。取而代之的是,你穿了橡胶鞋来保证你的脚不会被雨淋湿。你采用了不同的速度来行走:3 英里每小时。你花了 45 分钟来完成全程。

此外,如果下雪了,你甚至连 3 英里每小时的速度都达不到。你穿了胶鞋的同时,还因为怕被雪或者看不见的冰滑到而更加小心翼翼地走。你的速度降到了 2 英里每小时。走完全程花费了你整整 1 小时的时间。

你仍然坚持每次都走一样的距离。但是,接下来有段很长的路要走:你走路的速度也不尽相同。你没有按照你的期望,在相同时间内走完相同的距离。干扰的因素有很多,包括天气、你的胶鞋,以及路况。

而软件研发团队会碰到相同的问题。团队的速度通常取决于完成的质量。下面列举了一些会影响到团队完成质量的因素:

  1. 故事大小。故事越大,那么团队在完成这个故事时面临的超出他们预期情况的风险就越大。就算你的团队对大的故事定义非常准确,还要记得是你的客户购买的是故事而不是故事点这个问题。参考 Customize Your Agile Approach: Start with Results ,看看其中是如何通过燃尽图(burnup chart)来反映故事的完成情况,而不是故事点。
  2. 代码现在的状态和相应的测试。自动化单元测试以及系统测试越多,那么团队在修改某个模块功能的时候所面临的风险就越小。
  3. 团队的稳定性。当你的团队是稳定的,那么团队就能通过参考历史情况来假设后面的速度。但是,当你的团队关系出现变化,有时候甚至只有一个人的变动,那么团队就无法维持与之前相同的速度前进。新人是需要花费时间来熟悉代码,以及团队的工作方式的。

此时,你可能会认为如果一个稳定的团队始终采用故事点方式来预估进度的话,那么这个团队应当能比较准确的做出预估。通过我的实践发现,一般 1 - 2 天左右的故事采用故事点的方式进行预估是比较准确的,最多情况下可以用于 3 天规模的故事。

但是,当故事变的更大,或者故事的类型增加的时候,团队通常很难通过故事点的方式来进行预估。通常情况下是故事点越多,相应的风险也就越高。

有个团队的历史数据显示,他们团队能在每次迭代中完成 42 个故事点。他们只有包含 1、2 或者 3 个故事点的故事。这些故事通常会花费大概 0.5 天、 1 天,或者 1.5 天的时间。这意味着他们可以相对独立的完成工作。

但是,在下个迭代期间,他们选择了 3 个有 13 个故事点的 故事(共计 39 故事点)以及一个包含 3 个故事点的故事。这些加起来也是 42 个故事,花费他们完整的 8 天。

团队并不是因为愚笨或者懒惰。他们低估了故事的复杂度,以及故事所涉及的代码量。这是因为当你需要预估的单位,其规模越来越大的时候,你预估的误差可能就越来越大(参考 Predicting the Unpredictable ,其中有对这个现象更深入的解释。)

故事点可以用来比较你们的故事的规模大小是否相同。但是,只有一个或两个故事点的故事与那些有 5 个或者 8 个故事点的故事是截然不同的。

反而,你可以通过你的团队平均能多久交付指定数量的故事作为衡量的速度,或者修复问题的速度,或者你们团队可以用于衡量交付物的任意一种形式。这也是预估的一种方法。

可能这种方式对你来说不太适用。很多的敏捷团队使用关联预估的方式。

团队使用关联预估

如果你们团队已经采用敏捷开发有一段时间了,我确定你已经听说过使用计划扑克(Planning Poker) 来进行关联预估的方式。团队成员在一起讨论下个迭代中要完成的工作。每个团队成员都有标有数字的卡片,数字可以是斐波那契中的数字或者 T 恤的规格型号(从小到大,译者注)。PO(Project Owner,项目所有者)开始解释故事的具体内容,然后团队成员举起相应的卡片,并解释为什么觉得这个故事有这么大。

每个团队成员不需要在相对的大小上达成一致,讨论的过程才是最具有价值的。团队成员讨论代码、设计、测试,以及他们能看到的任何风险。

这个讨论的过程,其实是团队对这个故事的不同理解进行讨论和统一的过程。并且,当团队最终决定故事的大小大于 “ 1 ” 的时候,这时候团队就知道这个预估中存在一个不确定因素(可以参考 Pawel Brodzinski 的 Story Points and Velocity: The Good Bits ,来了解更多关于评估的细节内容。)

避免基于任务的预估

有些团队会尝试将工作分解为任务。对这种基于任务预估的方式有个问题。我见过很多次团队都尝试采用基于人力资源优先的方式,而不是基于团队工作流优先的方式去分配任务。当一件工作被修改为已完成状态时,这件工作通常就淡出了团队的视野,因为还有很多正在进行的工作要做。很多情况下,团队每次的发布都不是按照特性来进行,反而团队会发布一部分尚未完成的新特性。这些新特性并不会帮助到客户。团队开始通过统计故事点的方式来完成统计,而不是统计已经完成的特性的数量。

换一种说法,思考一下对于那些大于 1 天的故事,你如何能做到更好的理解不确定因素呢?如果你想通过关联预估的方式理解你工作中的不确定因素,下面有一些指导建议:

  • 要记住你的预估可能会出现偏差。比如,你有一个包含 3 个故事点的故事,你的预估可能会比这多 3 个故事点,或者少 3 个故事点。如果你的故事包含 8 个或者 13 个,甚至更多的故事点呢?在极端情况下,你那包含 8 个故事点的故事最终可能需要 16 个故事点的工作量。
  • 问问你自己为什么会觉得这个工作花费很久。一些可能的原因是:代码很乱;单元测试或者自动化系统测试不够,无法覆盖每一个变更;工作的内容很复杂,比如是一个完整的特性需求而非一个故事。

当你在讨论一个故事的时候,可能发现采用任务这种方式进行分解是有效的。但是不要忘记你任务的最终产物,并不能直接被客户使用。客户需要的是一个或多个完整的特性。

特别是对于那些规模很大,耗时很久的故事,划分任务的方式可能能帮你发现你工作上哪里有遗漏。我不推荐通过任务的方式来划分工作。但是当你采用了这种方式,你可能发现你能更好的评估故事中的风险和不确定的部分。甚至对于小一些的故事,你还会发现你的评估更精确了,交付速度也更快了。

利用探针使工作更清晰

我开始喜欢那种一天就能完成的故事了,当然通常是指一个团队一天能完成的。你可能会想,一个团队一天怎么能完成一个故事呢?当你采取多人一组(swarming)或者人海战术(mobbing)的方式,你就会发现相比单打独斗,故事完成的效率要高了很多。(更多内容可以参考: Pairing, Swarming, and Mobbing 。)要谨记,在敏捷实践的过程当中,一个人能做什么并不重要;重要的是一个团队能做的事情。

你可能对我的观点 “ 结对、多人一组、人海战术等方式要优于个人的单打独斗 ” 持怀疑态度。不管你的看板上有几个阶段,敏捷实践证明当团队齐心协力一起的时候,将一个故事从开始移动到完成状态的效率更高。很少有团队能很好的利用好团队内部的合作。大部分团队通常都是与客户或者用户合作,但很少关注团队内部。结对、多人一组、以及人海战术的方式都能够帮助团队成员更深入的了解产品细节,从而交付更高质量、更有价值的产品。(更详细的信息可以参考: How Pairing & Swarming Work & Why They Will Improve Your Products 。)

很少有 PO 或者团队能将故事的迭代周期控制在一天之内,他们没有掌握化整为零的艺术。当团队面对比较大的故事的时候,通常会讨论故事的不确定性。例如,如果一个团队认为当一个故事包含八个或者更多的故事点 是一个比较危险的情况,会存在很多不确定的因素,通常的做法可能是下面几种之一:花更多的时间讨论这个故事相关的内容,然后通过使用探针的方式拆分这个故事,亦或者采用人海战术,投入更多的人力去解决。还有一种情况是,PO 和团队一起分析这个故事,看看他是不是一整个需求合集或者一个复合型的故事。亦或者团队使用一天的讨论来对这个故事做更深入的理解。

下面描述了一个团队是如何通过一天的讨论来探索、交付,最终更加充分理解整个故事的过程。Jim 是一个六人团队的 PO,团队中包括 4 个研发人员以及 2 个测试人员。Jim 之前跟客户见面讨论过,知道客户所想所需究竟是什么。但是 Jim 看到的是整个功能集合,对于如何将其拆分为具体的故事,Jim 遇到了一些困难。他想让团队通过多人组队的方式来帮助他更好的分析其中的风险。

  1. 团队的会议在下午 1:30 开始,正好是午休之后。(因为团队之间是在一起工作的,所以他们不需要在每天早上通过通讯工具来互相沟通进度情况;每个人每天就绪后就能开始工作了。)

  2. 团队在交付方面,关于如下点是达成一致的:每次交付一个小特性之后,会尝试回答如下问题:这个特性包含了哪些故事?其中的风险是什么?我们交付的产品中的最重要的点是什么?

  3. 团队成员决定工作时间是早上十点到下午五点,之后可以选择检查邮件或者回家。中午的时候他们会工作到十二点半左右,然后去吃午饭,回来之后参加 Jim 主持的下午 1:30 左右的会议。这就是他们一天的安排。

  4. 团队开始决定采用开发者和测试者结对的方式来理解一个完整的特性是如何工作的,然后再决定接下来的工作。一开始的时候他们采用多人一组或者人海战术的方式。但是不确定的因素太多了,他们决定更换为结对的方式,然后每小时碰头沟通一次。下面是他们这一天工作的细节:

  5. 下午 1:30 的时候,Jim 向大家解释工作目标,以及客户的需求是什么。Jim 对接下来的工作有一个模糊的想法,但是他不能够完全确定。

  6. Jim 想跟团队在下午 2 点的时候进行一次迭代。团队分成了三组,两组是由开发人员互相结对,剩下的一组由两名测试人员组成。他们互相约定,在下午 3 点的时候会重新碰头开一次会。

  7. 下午三点的时候他们回到了会议室,会上他们互相阐述了刚刚过去的一小时内都得到了什么结果,并且会后他们决定不更换互相的结对组合。

  8. 在下午 4 点的时候,团队成员又碰了一次头,互相了解了一下进度。其中一个开发人员组成的小组给出了一个原型设计,并且希望团队以及 Jim 能够给出一些建议。测试人员那一组给出了一些自动化测试用例,并且得到了 Jim 的一些建议和反馈。Jim 根据大家的结果,重新调整了一下他所需要的内容,然后每个小组仍然保持之前的结对,继续工作。

  9. 到了下午 5 点之后,团队成员再一次碰头。现在他们的方向终于正确了。有些人在下午 5:15 离开了,像往常一样结束了他们一天的工作。剩下的人继续处理他们的邮件,总结未完成的工作,准备明天继续。

  10. 第二天的早上 9:30,每个人都回到各自工作岗位然后处理他们收到的邮件。团队开了一个简单的会议,进行了重新结对然后继续工作。

  11. 在上午 10:30 的时候团队再一次碰头,跟 Jim 沟通从而获得更多的反馈意见。到目前为止,两组开发人员都完成了各自的原型设计,并且向 Jim 和团队中其他成员就他们的原型设计进行阐述。测试人员给出了他们新设计的自动化测试用例,这也帮助开发人鱼更加理解最终的所得所需。Jim 针对大家的工作成果给出了更多的反馈和建议。接下来分组调整为三个一组:两个开发人员和一个测试人员。

  12. 在上午 11:30 的时候,团队成员再次与 Jim 碰头,每组都完成了一个小的故事,并且还有相应的单元测试和自动化系统测试。团队成员互相了解了目前的故事进展。接下来的 30 分钟内他们与 Jim 一起就剩余的故事进行研讨分析。团队成员回答了相应的问题,并且解释了为什么性能问题是这一特性集中的较大风险。

这个团队采用了两两结对和三个一组的方式完成了这个过程。其他组选择了每人自成一组的形式来完成,每个人会工作规定的时间,然后一起碰头互相沟通一下彼此的进度。

但是,他们也可能选择了多人一起工作的方式。如果他们采用了,他们可能不需要每小时一次的检查点了,尤其当 Jim 也跟他们在一间屋的时候。

当团队使用探针的时候,他们可以互相了解大家每天都做了什么。他们也会了解剩余的工作量以及可能在什么时间会出现风险。

如果团队成员发现工作太复杂,他们会有如下选择:约定接下来的某一天举行探针,与团队成员和 PO 一起研讨分析目前的工作,或者重新对当下工作进行评估。

尝试着不根据大小来进行评估,采用更进一步的、更准确的方式,比如考虑通过统计故事的数量。

统计故事数量取代预估

采用故事数量进行统计的方式有一个优点,就是团队会尝试将每个故事调整到一个适合他们团队的大小。有的团队可能喜欢 1 天左右的故事,但是有的团队可能喜欢 3 天左右的故事。不管怎么说,一个团队如果采用统计故事数量的方式,那么他们会尝试让寻找一个适合自己的故事大小。

当一个团队真的采用上述方式的时候,你可能对这个团队是否有能力找到合适的故事大小而存疑。先标准化故事或者先开始采用故事计数这种统计的方式并不重要。关键点是团队需要聚焦于他们的最终目的:完成故事。当他们开始统计故事而不是故事点的时候,他们的行为会发生变化。(具体如何做可以参考: Customize Your Agile Approach: Start with Results You Want

有个团队刚使用故事计数法的时候,曾经认为他们不需要关注故事的大小。但是经过一次迭代的证明,他们要么需要重新审视故事的规模,要么需要测量他们的迭代时间。

故事计数法允许团队能更清楚的了解到他们的产出。并且因为故事计数法会帮助他们标准化他们的故事规模,所以团队不需要花费太多的时间在预估上。

取而代之的是,PO 和他的团队需要花费更多的时间在划分故事上,因为故事需要被划分为近似的大小。每个故事花费的时间总有差异,一个可能多一些,另外一个可能少一些。一段时间之后,每个故事的大小就基本相同了。

另外一个好处是,团队不会被基于任务的预估所阻碍。

时间周期是一个很好的方式帮助你统计自己的故事。时间周期记录了每个故事在每个阶段所使用的时间。下面的表格式,可能就是你在实际中所需要的:

故事 故事开始日期 故事结束日期 故事持续天数 1 第 1 天 第 2 天 (全天) 共 2 天 2 第 3 天 第 6 天 共 4 天 3 第 6 天 第 8 天 共 2 天 4 第 8 天 第 10 天 共 2 天 合计: 4 个故事 共花费 10 天 时间周期 = 平均每个故事 10/4=2.5 天现在你可以知道每个 story 平均花费 2.5 天的时间,那么团队就可以说:“ 我们每个迭代周期可以完成四个故事 ”。这是一个有效的统计。

假设下没有预估会怎么样

你可能听说了无预估的方式。核心的观点就是你的团队工作流程已经标准化,所以你不需要预估任何东西。如果采用这种方式,你的故事必须保持很小的规模,这样标准工作流中才能持续输出来看到相应的成果。

有时候团队预估可能也没什么用。你可能有过如下经历:

  • 在你完成并提交故事之后,PO 想修改故事
  • 团队发现之前认为很小的故事实际并不小的时候
  • 团队发现自己的代码或者测试用例搞错了方向的时候

团队这时会发现预估失效了。这种情况下,故事计数法可能更有帮助。

要记住的是,如果你的团队每周或每两周需要交付一个可以运行的产品给你的经理或者客户的时候,你可能就不需要预估了。

总结

关于预估,不同的团队可以选择不同的方案。我还没有发现根据故事点速度来实现一个很好预测的案例,除非这个团队能做到每个故事都能在 1 天或者 2 天内完成。我还发现,时间周期是一个在整个迭代周期中都好用的方式。这是因为时间周期利用了你的团队的历史数据。

如果你需要预估你们团队的工作量,尝试下能否将工作目标拆分为 1 天左右的故事,然后进行统计。如果不能的话,可以尝试在某天采用探针的方式暂停当前的工作,将已经完成的特性进行发布,并统计下剩余的故事。

如果可以的话,尝试让你的团队采用工作流的方式进行工作,每天都完成 1 个故事。这样可能会帮你节省预估的工作。

关于作者

Johanna Rothman, 以 “ 实用主义管理者 ” 的称号为人所熟知。她能为困难问题提供最直接的建议。她擅长帮助团队发现自己的问题,协助领导和成员解决问题和风险,以及更好的管理项目开发的进度。Rothman 著有 10 余本著作,包括:Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver, Agile and Lean Program Management: Scaling Collaboration Across the Organization, Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, 2nd ed. 你可以从网站 jrothman.com 上找到更多关于 Rothman 著作的介绍。

查看英文原文: Customize Your Agile Approach: What Do You Need for Estimation?

感谢冬雨对本文的审校。

2017 年 12 月 28 日 16:361150

评论

发布
暂无评论
  • 出色的速度

    Buddha Buck最近向Extreme Programming讨论组提出这样一个问题:对于由7个人构成、迭代持续两周的团队,速度处于什么范围才算是“出色”呢?在他看来,少于或等于8点的速度就表示团队的故事可能太大了。由此引发的讨论提供了一些答案,还揭示出问题背后的问题。

  • 跟踪速度,而不是任务完成时间

    一个全新敏捷团队的成员在Scrum Development邮件列表中提出这样的问题:如何跟踪工程师在每个任务上耗费的时间,以及这与敏捷中速度概念的关系。速度是敏捷的度量方式,用来跟踪团队要用多久才能完成功能开发,以此了解完成一个项目要用多长时间。讨论组的意见是:跟踪任务完成时间毫无必要,没有用处。

  • 开发中的问题一再出现,应该怎么办?

    在软件研发中,许多问题是反复出现的,很多开发团队会因此陷入无限“救火”中,解决这种问题一个好的办法就是复盘。

    2019 年 3 月 1 日

  • 精益看板(上):精益驱动的敏捷开发方法

    企业的敏捷转型并没有一条通用的路径,所用的方法也没有一定之规。今天,我就跟你分享一种主流的敏捷开发方法:精益看板。

    2019 年 10 月 29 日

  • 敏捷的发展方向

    本文关注敏捷社区内的最新趋势,简要介绍了时下一些众所周知敏捷过程的替换方案。特别关注了估计,预测成果和影响的话题,还有精益生产对敏捷社区的影响。

  • Sprint 规划:故事点数 vs. 小时数

    长久以来,对于sprint规划中应该使用故事点数还是小时数,一直有着不分胜负的争论。Mike Cohn坚决支持将用户故事拆散成任务,然后再用小时数估算。而Jeff Sutherland提出:有些跟他一起工作过的、非常出色的团队一直在使用故事点数,并用其绘制燃尽图。

  • 这是一篇敏捷实践者对 Scrum 的吐槽

    众所周知,Scrum 是一种敏捷实践,很多团队在敏捷转型时都采用了它,但是在我看来,Scrum 并不那么敏捷,甚至它提倡的有些价值观和做法是有悖于敏捷原则的,所以本文我会讲讲 Scrum 到底存在哪些问题?

  • 使用就绪定义

    许多团队都使用完工定义来检查用户故事是否完成以及产品是否做好了交付准备。但团队从他们的产品经理那里获得的用户故事怎么样呢?团队可以使用“就绪定义(Definition of Ready)”检查用户故事的质量。

  • 关于“敏捷计划与估计的方法”的讨论

    在做Scrum的迭代计划时,不同的团队有很多不同的做法。在敏捷中国讨论组中,对敏捷计划与估计的方法进行了激烈的讨论(Scrum sprint plan中规模估算的做法调查,关于story point的单位)。

  • 定制你的敏捷方法:以结果为导向

    这是系列文章中的第二篇,该系列主题为帮助你思考如何针对你的环境定制敏捷方法。本文围绕的是团队可能收集和使用的数据(比如正在做的产品和其他度量),即那些你想要分享给管理者和利益干系人的信息。

  • 敏捷度量的 Why、What、Who、When

    敏捷不仅有度量,度量还是敏捷项目非常重要的一部分,但敏捷度量和传统的度量存在很大的区别。敏捷度量不是以评估和考核为目的的,它是为了帮助团队拉通目标和行动、指导指定工作计划和任务、协助团队持续改进而发生的。

  • 当敏捷团队遇上固定价格合同

    固定价格合同很有害,这是敏捷实践者经常说的。从另一个角度来说,这些合同是很多敏捷团队必须面对的现实。但是,如果我们试着去驯服它而不是去反对它,那结果又会如何?一个公司如何用敏捷实践执行这种合同来达到更佳效果和更低风险?这篇文章试图回答这些问题。

  • 最佳实践:小团队如何应用软件工程?

    小团队在软件项目开发上的主要问题是:对成本敏感、人少活多和缺少流程规范。可以从团队建设和流程建设入手,去解决这些问题。

    2019 年 6 月 4 日

  • 分支策略:让研发高效协作的关键要素

    分支策略就是研发协作和发布模式的风向标,找到适合当前团队的分支策略,是非常重要的事情。

    2019 年 11 月 5 日

  • 敏捷开发流程之 Scrum:3 个角色、5 个会议、12 原则

    通过团队间的有效交互,为企业创造价值。

  • 如何用敏捷消除项目风险?

    需求定义不规范是开发中最大的浪费之一。本文描述了一种非常简单的技术,可以用于所有的用户故事,以便提高质量减少浪费。本文还探讨了如何通过未充分利用的“就绪定义”将它匹配到现有的计划和工作流评估中。那是一个你可以马上应用的、可操作性很强的概念。

  • 怎样平衡软件质量与时间成本范围的关系?

    根据“金三角”的三条边,找出来固定的一条或两条边,然后去调整剩下的边,达到平衡。

    2019 年 3 月 12 日

  • 项目管理工具:一切管理问题,都应思考能否通过工具解决

    每一次工具的升级,都是对项目管理工作的一次简化。合理的使用项目管理工具,可以帮你极大提高管理效率,起到事半功倍的效果。

    2019 年 3 月 28 日

  • 拿看板拯救你——我的“红”项目

    这篇案例讲述了如何运用看板以及精益开发技术,拯救一个“红”项目。从预算、进度以及质量各个方面把这个项目“拯救”回来。关于如何在中型项目中引入这些技术,使其从混乱环境中重新建立控制,这篇文章是一个活生生的案例;同时还提供了团队进度的若干图表以作参考。[译注:有这样一部电视剧——“拿什么拯救你,我的爱人”,对于我们又憎又爱的“红”项目,看板,将是最佳的拯救利器。]

  • 提高敏捷回顾效果的小贴士

    怎样更好地提高敏捷回顾的效果呢?Esther Derby、George Dinwiddie、Jo Geske、Mike Sutton和Ilja Preuss给了一些建议。这些建议包括给facilitator/Scrum Master的小贴士,以及使用燃尽图的新方式。

发现更多内容

设计模式-第三周

X﹏X

【第三周】命题作业——单例及组合模式

三尾鱼

极客大学架构师训练营

极客大学架构师训练营 框架开发 上课总结 第五课

John(易筋)

极客时间 设计模式 极客大学 极客大学架构师训练营 框架开发

架构师训练营第三周课后作业

赵凯

设计模式

【架构师训练营 - week3 -2】总结

早睡早起

架构师训练营-作业3

进击的炮灰

面向对象的设计模式

WW

windows使用docker运行mysql等工具(二)安装运行mysql

Java旅途

MySQL Docker

让你眼前一亮的 10 大 TS 项目

阿宝哥

Java typescript Web 前端开发 开源项目

【架构师训练营 - week3 -1】作业

早睡早起

架构师训练营第三周-学习总结

架构师训练营-总结3

进击的炮灰

组合模式应用

yupi

可读代码编写炸鸡二(下篇) - 命名的歧义

多选参数

代码 代码优化 代码组织 代码规范

手写单例模式

yupi

架构师训练营第三周作业

极客大学架构师训练营

蟒周刊/426: DjangoCon US 2020 取消了

ZoomQuiet大妈

Python 大妈 蟒营® Weekly 蟒周刊

2020互联网公司端午节礼盒合集!你最中意哪一款?

Java小咖秀

互联网人 端午节

可读代码编写炸鸡二(上篇) - 命名的长度

多选参数

代码 代码组织 代码规范

windows使用docker运行mysql等工具(一)windows安装docker

Java旅途

MySQL Docker

架构师训练营 - Lesson Week 3

brave heart

极客大学架构师训练营

【架构思维学习】 week03

chun1123

小师妹学JVM之:java的字节码byte code简介

程序那些事

Java JVM Java 25 周年 bytecode 字节码

产品失败了,产品经理要不要承担责任?

涛哥

产品经理

架构师训练营 0 期第三周

Blink

新手村:最适合新手的 Redis 基础

多选参数

数据库 redis redis6.0.0

数字货币监管当体现“中国之治”

CECBC区块链专委会

数字货币 CECBC 区块链技术 技术标准 准入和监管

【架构思维 - 学习总结】week03

chun1123

学习 设计模式

Breaking through Three Common Engineering Myths·英语阅读笔记

3.141516

架构师训练营 - Task Week 3

brave heart

极客大学架构师训练营

区块链改变数字营销与广告市场

CECBC区块链专委会

区块链技术 广告业 精准投放 去中介 公开透明

定制你自己的敏捷:良好的预估如何练成?-InfoQ