sprint_sprintf - CSDN
精华内容
参与话题
  • 什么是Sprint?

    万次阅读 2020-02-21 11:47:28
    Sprint指Scrum团队完成一定数量工作所需的短暂、固定的周期。Sprint是Scrum和敏捷的核心,找到正确的Sprint周期将帮助您的敏捷团队交付更高质量的产品。 “在Scrum框架中,庞大且复杂的产品将被拆分成一个个小的片段...

    未命名_自定义px_2019.06.21.png

    Sprint指Scrum团队完成一定数量工作所需的短暂、固定的周期。Sprint是Scrum和敏捷的核心,找到正确的Sprint周期将帮助您的敏捷团队交付更高质量的产品。

    “在Scrum框架中,庞大且复杂的产品将被拆分成一个个小的片段,通过一系列被称为“Sprint”的迭代来完成。”

    Sprint使项目更易于管理,让团队更快、更频繁地交付高质量的工作,并使团队能够更灵活地适应变化。

    许多人将Scrum的Sprint与敏捷软件开发联系起来,以至于不明就里的人将Scrum和敏捷当成是同一件事。但实际上,两者根本不是一回事儿。敏捷是一套开发的原则,而Scrum则是一个能够帮助你把活儿搞定的框架。

    如何规划和执行Scrum Sprints?

    Scrum践行者们考虑十分周到。通过召开Sprint planning会议,用于规划即将开始的Sprint。Sprint Planning是一个团队协作活动,这个过程中,团队需要回答两个基本问题:本次Sprint要完成哪些工作?如何完成?

    Product Owner,Scrum Master和开发团队需要协作选定每个Sprint中要做的工作项。Product Owner则需要商讨Sprint要达成的目标,以及在Sprint结束时可以确保目标实现的PBI。

    然后团队需要在此基础上制定一个计划,说明他们将如何构建Backlog列表并在Sprint结束之前将其“完成”。选择工作事项以及如何完成这些工作事项的计划被称为Sprint Backlog。Sprint Planning结束时,团队已经准备好开始Sprint Backlog的工作,将Backlog列表中的工作推进到“进行中”和“已完成”。

    image.png

    Sprint期间,团队通过每日站会汇报工作进展。站会的目标是展示可能影响到团队顺利交付Sprint目标的阻碍或挑战。

    Sprint完成之后,团队将在Sprint Review上展示他们在Sprint期间完成的工作。这也是在产品正式上线前,团队向利益相关者和团队其他成员展示工作成果的机会。

    最后,以Sprint Retrospective来为整个周期画上一个圆满的句号。这也是确定团队在下一个Sprint中需要在哪些地方做出改进的机会。在此基础上,就可以着手开始下一个Sprint周期了。

    要和不要

    即便在掌握了前述基本准则的情况下,大多数团队在刚刚开始尝试sprint实践时也会遭遇诸多困难。以下是一些建议的做法和注意事项。

    推荐要做的事项:

    • 一定要确保团队设定并真正理解了Sprint目标以及Sprint成功与否的标准。这是确保每个成员协同一致并朝着共同目标前进的关键。
    • 确保Backlog中所有的工作项按照优先级和关联关系顺序进行排列。如果管理不当,这可能会是一个极大的挑战,并且还会破坏整个过程。
    • 确保团队对速度有很好的理解,并且要体现休假和团队会议等事项。
    • 用Sprint Planning会议来充实需要完成工作的具体细节。鼓励团队成员为Sprint中的所有需求、bug和任务草拟工作任务。
    • 如团队无法判断相关性,例如来自另一个团队、设计和法律签署的工作则应该暂时搁置。
      *最后,一旦做出决策或计划,请确保有人在项目管理或协作工具中能获取该信息。这能够确保每个人都可以轻松地查阅相关决定及其理由。

    当我们致力于成为完成前述所有“推荐要做的事项”的Scrum团队时,也要避免下面这些危险事项:

    需要避免的事项:

    • 不要一次性设计太多用户故事、高估团队速度,或在Sprint中加入无法完成的任务。尽量避免设定那些注定会导致团队失败的目标。
    • 不要忘记质量或技术债。要为像bug和工程师健康等这样的QA和非功能性工作预留缓冲时间。
    • 不要让团队对sprint中工作内容存在不清楚的地方。确保每个人都清楚地了解,不要太专注于快速推进而忘记确保每个人都朝着同一个方向前进。
    • 此外,不要承担大量未知或高风险的工作。将庞大或具有高度不确定性的用户故事进行拆解。可以大胆地将部分工作留到下一个Sprint去完成。
    • 如果听到团队成员表达的担忧,无论是关于团队速度、低确定性工作,还是他们认为超出预估的工作量,都不要忽视这些声音。解决他们提出的问题,并在必要时重新校准。

    Worktile官网: https://worktile.com/

    内容整理:Worktile
    文章首发于「Worktile官方博客」,转载请注明来源。

    展开全文
  • c语言中sprint的用法

    千次阅读 2017-01-23 15:12:43
    sprintf()最常见的应用之一莫过于把整数打印到字符串中,如:  sprintf(s, "%d", 123); //把整数123打印成一个字符串保存在s中  sprintf(s, "%8x", 4567); //小写16进制,宽度占8个位置,右对齐 ...
    sprintf()最常见的应用之一莫过于把整数打印到字符串中,如:
        sprintf(s, "%d", 123);  //把整数123打印成一个字符串保存在s中
        sprintf(s, "%8x", 4567);  //小写16进制,宽度占8个位置,右对齐

    sprintf的作用是将一个格式化的字符串输出到一个目的字符串中,而printf是将一个格式化的字符串输出到屏幕。sprintf的第一个参数应该是目的字符串,如果不指定这个参数,执行过程中出现 "该程序产生非法操作,即将被关闭...."的提示。

    #include <stdio.h>
    main()
    {
        char a = 'a';
        char buf[80];
        sprintf(buf, "The ASCII code of a is %d.", a);
        printf("%s", buf);
    }


    展开全文
  • 我始终记得当年我作为敏捷教练所做的第一次Sprint回顾,这一切都仿佛就发生在昨天。这家公司实行Scrum有好几年了,我自然而然地认为他们这群人是纪律严明并且成熟稳重的敏捷专家。 因此,当他们计划了一系列Sprint...

    我始终记得当年我作为敏捷教练所做的第一次Sprint回顾,这一切都仿佛就发生在昨天。这家公司实行Scrum有好几年了,我自然而然地认为他们这群人是纪律严明并且成熟稳重的敏捷专家。

    因此,当他们计划了一系列Sprint回顾会议,用来展示X团队最新Sprint成果时,我感到异常兴奋。我早早地溜进了会议室,并为自己找了个绝佳的位子坐下,翘首以盼。

    渐渐地会议室里的人越来越多,并变得嘈杂起来,这反而使我的期望到达顶点,我知道好戏就要开演了。这时,第一个团队登上了“舞台”,准备他们的回顾,他们打开PowerPoint做的幻灯片,“演出”终于开始了!

     

    第一个团队准备的材料实在是精挑细选,他们准备了在这个Sprint中他们所完成的事情的列表,还配了插图,甚至还准备了些在适当时刻调节气氛的小笑话。他们一一讲述团队所做的工作,一页接一页地翻动着幻灯片,在恰当的时机,听众也不失时宜地礼貌地鼓掌以表示对他们的赞许。

    然而,当第一场回顾进行到一半的时候,我意识到似乎有非常、非常重要的东西被遗漏掉了,怎么没有代码演示呢?我心中感慨,这样的错误怎么会发生在这样一群成熟且经验丰富的敏捷专家身上呢?整个Sprint回顾的最终目的就在于向各位利益相关者展示这个Sprint所完成的代码,并得到大家的反馈。当时我想,也许这只是一个特例,只是被这个团队疏忽了,接下去肯定会有代码演示。

    然而,我期待的事情并没有发生,之后的每一个团队使用着跟第一个团队相同的模式——风趣幽默的幻灯片和文字,对他们的工作量进行说明,并没有代码演示,这让我的热情迅速耗尽, 也让我彻底失望。

    对于整个团队而言,还有那些诠释过Sprint回顾意义的人而言,显而易见地是,他们并没有真正理解Sprint回顾的意义。当然,利益相关者也没能理解这么做的目的,他们仍然对那些设计好的笑点礼貌地回应,并鼓掌肯定团队的工作,似乎这个仪式仅仅是为了给Scrum流程列表上的这一项打上个勾而已。

    千万杜绝!

    在此后的Sprint回顾中,毋庸置疑的是,我再也不会让这类事情发生了。我很敬佩这些团队的自主精神,但我仍然立即列出了今后Sprint回顾应该完成的目标以及如何实现这些目标的纲领。

    纲领中的某些项目跟敏捷宣言(Agile Manifesto)非常合拍,例如在每个迭代或Sprint结束时进行代码演示的理念,但有些项目却是我们的组织以及企业文化中特有的。

    这才是文章的重点。我打算与大家分享,我们当时是如何转变Sprint回顾的主要纲领、战略以及心态的,正如:

    • 从礼节性地鼓掌转变到热烈地欢呼
    • 从礼节性地鼓掌转变到获得有建设性的反馈
    • 从兜售我们的成果转变到让成果变成真实透明
    • 从小众群体参与转变到大众站立方式并运用录影
    • 从幻灯片转变到代码演示
    • 从娱乐大众的心态转变到展示团队能力及产品价值
    • 从“授课”形式的演示转变到有交流、有互动的形式
    • 从刻意兜售我们的成果转变到“姜太公钓鱼,愿者上钩”、让事实说话的形式

    当然,冰冻三尺非一日之寒,这些不会马上发生,我们仍然在日复一日持续对我们的Sprint回顾进行着调整和优化。幸运的是,我们当真找到了一些门路,使之成为贯穿组织架构中实施敏捷流程的基础。 让我来分享几件我们用心做的事情吧。

    “出色”的Sprint回顾

    总体来说,我认为Sprint回顾非常重要,之所以这么说是因为:

    1. 一个敏捷团队为世界上最重要的故事(story)专心工作了一段时间,并准备交付与之相关的功能或故事。单从这点上看,回顾就足够重要,人们的目光都聚集在这里,大家渴望见到成果,所以你必须满足你的“观众”。
    2. 团队有义务展示他们的工作成果,但这不单单停留在代码演示,团队应该站出来讲述围绕他们的工作所发生的故事。这可以是图文并茂的,伴有情节的,而且这必须与上一次的Sprint回顾有联系,并对下一次的Sprint回顾做出铺垫。

    接下去我将为大家分享Sprint回顾的7个最重要的方面以及一个简单的回顾会议日程。我希望这些建议能帮助大家改进你的Sprint回顾,能更有效地拉拢你的利益相关者,并更全面、更充满激情地展示你的团队。

    Sprint回顾的7招绝杀

    1. 职责
      在每次Sprint回顾中,我们都会建立起一种产品负责人对此全权负责的理念。诚然,这是每个团队成员的事情,但在每天工作结束时,产品负责人会负责进行外部沟通、展示计划中所交付的代码,以及对收集到的反馈意见进行相应地调整。他们还负责把大家找来做回顾——如果与会者参差不齐,人数稀少(小众参与),他们就必须找到问题所在并做出相应改变,让“合适的”人聚到会议室里进行Sprint回顾(大众站立式)。 我时常把产品负责人比作典礼的主持人——他们负责引导Sprint回顾的各个方面。当然他们不需要事事亲历亲为,但他们需要把握总体的回顾质量,考虑回顾的重点以及对回顾的成果负责。

    2. 形式
      我们对回顾的日程安排以及时间控制出了很多主意(如果你置身于多个Sprint团队,那么也可以是多个Sprint的回顾)。你肯定希望你的回顾具有固定的节奏(时间与间隔),在进行Spring内容回顾时,你也肯定希望每个团队都遵从统一的流程(之后的章节将给出回顾会议日程安排的例子)。 在我们的案例中,由于我们有多个Sprint,并且是同步的,我们在同一天演示多支团队的成果,因此我们的回顾形式有一种跨团队的日常安排,将3个小时的回顾会议合理地分配给每个团队。我们不仅对每个团队的回顾做出安排,更重要的是,我们的首席产品负责人对每个团队的回顾流程进行统一的节奏掌控。

    3. Sprint目标
      就个人而言,我更倾向于Sprint回顾主动地去契合团队成员都认同的Sprint目标。我经常嘱咐我的团队,当他们在制定Sprint目标的时候,多想一想如何撰写他们需要发送的回顾邀请邮件。这个Sprint的故事就会契合Sprint目标,团队成员也将采取相应的行动来达到Sprint目标。

      另外,你必须对团队所要承诺的Sprint交付物100%的诚实,你必须告诉大家成功了或是失败了。但千万不要让“失败”这个词把大家都吓坏了,失败乃成功之母,它是团队自我学习的一部分,也是整个组织保持一种“向失败学习,不被其打败”的积极态度的重要组成部分。

    4. 人人参与
      正如我所说,我崇尚把产品负责人当作整个典礼的主持人,那么Scrum Master则是协调者(如果需要的话),而整个团队才是真正的大明星。给予你的团队成员一个表现自己的机会,让他们站出来展示他们的成果。人人参与的方式,将给予你的团队足够的表现空间——让团队成员轮流地去做代码演示,这样一来,每个人都有机会为大家演示自己的劳动成果。

      但必须记住,不要强迫性格内向的成员去做大范围的演讲,你可以鼓励每个团队成员去表现,但这必须不是强制性的。通常,性格内向的成员可以成为演示的参与者,他们是很好的聆听者,安静地参与回顾。但是,你必须要鼓励团队的每个成员积极参与回顾。

    5. 准备 如果说什么是成功的Sprint回顾秘诀,那就是之前的准备工作了——别放太多的内容,也别过于简单了,把握好这个度。你必须去思考,什么内容是和这次Sprint回顾相关的;回顾应该以怎样的流程进行下去;你还要去想,这次回顾如何与前一次,后一次的回顾相互呼应。

      通常,有着质量保障(Quality Assurance)背景的人会提前写一个回顾的“脚本”,帮助自己更紧凑地揭示工作成果。但最终,产品负责人才是决定回顾哪些内容,以及为什么做这些回顾一锤定音的人,他为利益相关者搭建好回顾的“舞台”。

      如果有疑问,在Sprint计划阶段就给回顾的准备留出足够的时间,并认真地去做准备。

    6. 执行与演示 你需要保证整个回顾演示必须是顺畅的、有思想的、精心商榷的,并且最终的软件是可以无差错地工作。你需要执行试运行(Dry-running)演示,并确保所有代码环境都事先调试通过。你还必须计算好演示的时间,保证不会超过预留给你的时间,同时也不要忘记提问部分。

      除了演示,你最好能描述一下你所开发的功能特性或工作流。我曾见过一些团队在他们的第一次Sprint回顾中就给出了他们在未来6次Sprint所规划的工作的架构图。在此后的每一次Sprint回顾,他们只需做做简单的“填空游戏”就能把他们的应用程序架构附上“皮肉”(意指代码实现)。我觉得这是一种非常好的方法,能够帮助回顾会议的听众涉点及面。

      在我看来,团队在一个Sprint中涉及的所有工作都可以在Sprint回顾中被展示,这包括:功能特性、功能改进、Bug修复、重构、文档、测试架构等等,任何工作都可以放进来。当然有些东西可能要等到一定的程度才能拿得出,但只要是团队做的,都可以成为回顾的内容之一。

      最后,考虑好如何描述清楚你的演示,让你的听众能够理解你所演示的内容,内容的关键部分,以及团队在这些内容背后的辛苦付出。

    7. 总结 最后,我们总是对两个方面进行回顾总结——软件本身的反馈意见以及回顾会议的反馈意见。例如:这个过度是否平稳?所有人都明白我们做的东西了吗?你清楚如何向我们提供反馈意见了吗?下一次回顾有什么地方需要改进吗?我们通常都会在这个阶段花上几分钟,但这几分钟绝对超值!如果你对举手表决(Fist-of-Five)的理念比较熟悉的话,我们通常使用这个方法来结束反馈过程。

    回顾会议日程安排举例

    你可以考虑将以下作为你的团队Sprint回顾会议日程安排的模板:

    1. 介绍

    2. 组织架构

      • 团队成员角色:名字、角色、工作地点等
      • 对Sprint提供帮助的外部成员
    3. 工作认可——感谢

      • 这个绝对是团队成员的出彩时间
      • 这也是对Sprint提供帮助的外部成员的工作进行认可的好时机
    4. Sprint目标

      • 阐明Sprint目标,以及有何调整
      • 宣布Sprint是否成功,团队成员是否兑现承诺
    5. 战略目标、成功定义、工作量、新发现、成果

      • 分享团队交付的代码所考虑到的整体战略目标
      • 围绕Sprint幕后的工作量
      • 是否有考虑不周全的地方;关键的成果
      • 所有这些都为回顾会议的听众提供了一个了解团队Sprint幕后故事的机会
    6. 演示、提问时间

      • 演示所选择的用户故事集以及功能特征——接受提问
    7. 未来议项

      • 宣布现行目标的进程以及未来Sprint所涉及的工作
    8. 回顾改进意见的举手表决(Fist-of-Five)

      • 鼓励回顾会议的听众对团队的表现进行反馈
    9. 结束

    总结

    我无法用语言表达一次高质量的Sprint回顾将带给你何种感受,这需要你亲身去感受。尽管产品负责人及团队很大程度地左右着回顾成果,但作为敏捷项目的项目经理,你同样扮演着至关重要的角色。 通常,团队成员在努力工作时被抓出来,仓促地准备Sprint回顾。事实上,这么做是典型的反例。你必须在Sprint计划时就嘱咐团队留出相应的时间给Sprint回顾,并且在Sprint即将完成的时候,善意地提醒他们,做好Sprint回顾的准备工作。

    请记住,这个回顾会议也是团队能力的一个“质量检查点(QA Checkpoint)”。将各项工作放在一起并演示出来,无疑是提高团队Sprint能力的最佳途径了。你往往会发现——环境没有准备好、整合没有做好或者交互没有实现等等诸如此类的麻烦事。

    因此,各位敏捷项目的项目经理们,我希望这篇文章能够影响你们,使你们发生转变,把Sprint回顾做成敏捷实现中最有利的一种手段,真正担当起Sprint回顾的重任。虽然团队才是做准备及完成交付的人,但你的任务是去影响他们进行回顾的态度与方式。随着项目的进行而不断的进步,你可以将你能获得的正向反馈无限放大,帮助你的团队更好地完成敏捷项目。

    展开全文
  • Sprint回顾会议的一种简单玩法

    千次阅读 2016-03-03 09:28:52
    sprint回顾会议的一种简单开法——只须问团队成员3个问题:他们想开始做什么?他们想停止做什么?他们想继续做什么?

    原文作者:Mike Cohn


    回顾会议该怎么开?团队不同,大家的做法或许各有不同。我想介绍一种我最喜欢的方式,特别是因为这种方法经受住了时间的考验,很多年以来,我已经把它运用在了很多很多的团队里。

    开始/停止/继续

    我喜欢在sprint回顾会议上问团队成员3个问题:他们想开始做什么?他们想停止做什么?他们想继续做什么?这种类型的会议因此有了一个别名,叫“开始/停止/继续”会议。

    开始事项是指某个团队成员想要团队把它们加入流程的那些事。一些例子如下:

    • 把软件早一点展示给客户
    • 早一点与客户确定验收测试
    • 做代码审查
    • 准时参加每日站会
    • 在当前需求没有完成之前不要开始做新需求

    停止清单上的事项是指团队里的人认为效率低下或者浪费时间的那些事。团队应该停止做这些事。一些例子如下:

    • 在还没有跑通过所有测试之前就提交代码
    • 每日站会的时间超过15分钟
    • 在我们觉得当前sprint进度落后的时候跳过product backlog refinement会议

    继续清单上的事项是指团队想要继续重视但还没有养成习惯的那些事。也就是说,上述开始或停止清单上的任何事项都可能进入继续清单,并且在这个清单上呆上几个sprint。

    做一件事一旦变成了习惯,它便将最终从继续清单上删除。要不然,继续清单会变成超级冗长!

    以不同的方式询问

    Scrum Master可以用不同的方式去询问团队成员。最简单的就是,直接让他们大声说出来。团队成员可以自由地说出他们想要开始/停止/继续的事项。这是我的默认模式。

    但是,如果总是这样子,一个sprint接着另一个sprint,难免会让人觉得乏味。因此,我会搞些花样,有时候我会在房间里四处走动,挨个儿叫他们给我一个事项,也许在房间里走上两遍之后才会进入下一个议程。

    其他时候,我会关注在一种特定类型的事项上——常常是停止事项。我会让所有团队成员直接说出他们想要停止做的事情,除此之外什么也别说。我可能会混用两种方法。我会走到每个人的身边,挨个儿让他们指出在当前流程里他们想要停止做的一件事。

    在“开始/停止/继续”回顾会议上,为了收集大家的想法,有大量方法可以混合起来使用。这些方法足够用一阵子的,不至于让大家觉得无聊或重复。

    投票

    在收集了足够多的想法之后,就要请团队成员投票选出最重要的一项或几项。什么时候该开始投票呢?这常常是显而易见的,也就是在创造性逐渐消失、新的想法不再那么快速冒出来的时候。

    Scrum Master可以让每一个团队成员给最重要的一项投票,或者也可以使用任何典型的多投方法。举例来说,给每个团队成员3张选票,他们可以根据自己的意愿把票投出去(包括把所有3张票都投给同一项)。

    我喜欢在回顾会议上采用多投这种方法。回顾会议列出来的大部分事项,实际上很多都不需要花时间去做。很多都是行为上的。考虑一下上面给出的一个例子:要准时参加每日站会。那不用花时间。实际上,也许还是省时间的。

    通过多选,团队可以选择改变行为,以及做一些其他事。通常来说,我的选择不会超过3项。即使它们不费时间(或者说不费很多时间),选择太多事项也会降低那些所选择之事的重要性。

    除了投票选出新增事项之外,也需要讨论一下继续清单上的那些事项,是否已经达到预期了,于是不再重要或者因为其他什么原因应该从清单上删除了。

    下一次回顾

    在下一次回顾会议上,我建议Scrum Master把前一次会议上收集来的想法都过一遍,包括那些被选择执行的和没有被选择的。这些可以作为下一次回顾会议的开场讨论。

    我喜欢在一张大纸上把它们都写下来,然后静静地把它贴在墙上。如果团队需要,或者想要参考一下,这些事项总是静静地呆在那里。然后,我会组织新一轮的“开始/停止/继续”讨论。

    有哪些好处?

    我发现,这样组织回顾会议的好处是:快、容易做、没压力、有效!“开始/停止/继续”会议是非常行动导向的。我们没有花时间在员工感受上。我们没有问团队成员他们在sprint里的感受怎么样,是开心还是不快,感受到了温馨还是矛盾……

    每个事项都会直接引起行为上的改变。团队将开始做一些事,或者他们将停止做一些事,或者他们将继续做一些事,直到养成一种习惯。

    我可以预见,很多人会说,员工的感受才是重中之重。我们只有首先处理好人们的感受问题,我们才不知道应该怎样去采取行动。没错!有一些情况确实是这样。但是,在其他大量的情况下,我们可以直接分辨出该做的事情(比如“我们需要开始早点做测试”)。

    这就是在sprint回顾会议上引入“开始/停止/继续”方法的优势所在!

    展开全文
  • <!-- table.MsoNormalTable {line-height:115%; font-size:11.0pt; font-family:"Calibri","sans-serif"} p.MsoNormal {margin-top:0in; margin-right:0in; margin-bottom:10.0pt;...
  • 白话SCRUM 之三:sprint backlog

    万次阅读 2013-08-23 14:59:47
    Sprint Backlog就是任务列表,如果映射到传统的项目管理理论中就是WBS(work breakdown structure),而且是典型的采用面向交付物的任务分解方法得到的WBS。比如有一个Product backlog 条目为: 作为系统的合法用户...
  • Release,Sprint,Story和Version的关系

    千次阅读 2013-08-10 16:33:17
    scrume的version管理
  • 敏捷开发Scrum——Sprint Retrospective

    千次阅读 2010-02-26 10:24:00
    敏捷开发Scrum——Sprint RetrospectiveMoakap总结在Scrum中,每个Sprint结束的时候会有两个会议(Sprint Review/Demo和Sprint Retrospective回顾)。这两个会议是对过去的一个Sprint的一个总结,其中Review/Demo是...
  • 一、jira中sprint面板的创建这个很简单,键入jira后,顶栏处找“面板”→“查看全部面板”,此时页面右上侧有“创建面板”的按钮,点击,选择“创建一个Scrum面板”,根据提示填信息到完成即可。二、jira中sprint...
  • Agile基础:Scrum的5个会议

    万次阅读 2016-09-08 21:19:14
    在本文中我们会整理一下Scrum的五个Event也是五个会议的相关信息。
  • SCRUM是一种敏捷开发模式,源于橄榄球术语,有一些...Sprint计划会议确定本次冲刺任务列表(Sprint backlog),原则上一次冲刺内,拒绝需求变动,scrum master有责任保护team不受需求变更的影响。关于Sprint执行期间
  • Scrum 学习笔记

    万次阅读 2011-12-09 09:49:00
    Scrum 学习笔记 敏捷火了很长一段时间了...在这个框架中,整个开发周期包括若干个小的跌代周期,每个小的的跌代周期称为一个 Sprint,每个 Sprint 的建议长度2到4周。在 Scrum 中,使用产品 Backlog 来管理产品或项目
  • 2011年4月14-15日,有幸参加全球敏捷联盟的CSM(Certified Scrum Master)培训,虽然我们在平时工作中一直使用Scrum开发模式,但是对Scrum的理论我还不是十分的清楚,两天全英文的培训使我全面了解了Scrum的基本流程,...
  • 敏捷开发之Scrum框架入门

    千次阅读 2014-04-02 15:25:33
    在这个框架中,整个开发周期包括若干个小的跌代周期,每个小的的跌代周期称为一个Sprint,每个Sprint的建议长度2到4周。 在Scrum中,使用Product Backlog来管理产品或项目的需求,product backlog是一个按照商业价值...
  • Scrum sprint plan中规模估算的常见方式

    千次阅读 2011-11-17 09:21:23
    首先,把根据sprint历史数据得到的估算,称为 历史数据估算,把commitment之后的估算 称为 承诺估算。 历史数据是以前的定量情况,包括但不限于资源利用率、sprint可以完成的story point数量、每个story point平均...
  • Scrum敏捷开发流程主要包扩三个角色、四个会议和个三物件。 三个角色 Scrum团队中包括三个角色,他们分别是产品负责人、开发团队和 项目的直接管理者(Scrum Master)。...Scrum 团队是自组织、跨职能的完整团队...
  • 在Redmine backlogs中规划项目方法

    千次阅读 2014-01-12 18:28:46
    前文Release,Sprint,Story和Version的关系讨论了一些基本概念。而且提到简单来说就是一个Release可以包括几个Sprint,一个Sprint包含几个Story. 当然一个Story可以跨越多个Sprint或者Release。这句话看上去容易理解...
  • 在jira里更换工作流后,敏捷看板中的活动sprint下无法看到原来的bug list 了,通过修改敏捷看板配置中的bug状态对应后,解决问题
  • 敏捷:Scrum的5个会议

    千次阅读 2017-09-04 22:59:51
    在本文中我们会整理一下Scrum的五个Event也是五个会议的相关信息。 ...sprint plan meeting sprint规划会议的主要信息如下 项番 ITEM 详细说明 No.1 WHY
  • 在这个框架中,整个开发周期包括若干个小的跌代周期,每个小的的跌代周期称为一个Sprint,每个Sprint的建议长度2到4周。1 Scrum框架的概念Scrum是一个敏捷开发框架,是一个增量的、迭代的开发过程.。在这个框架中,...
1 2 3 4 5 ... 20
收藏数 27,777
精华内容 11,110
关键字:

sprint