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);
    }


    展开全文
  • 很多聊技术的人会聊敏捷,聊敏捷似乎避免不了scrum,而scrum中经常出现的sprint这个东西,那么sprint在scrum中到底是什么呢? 有人也许会说sprint就是是一个迭代(iteration),一个开发周期嘛,那么问题来了:...
        

    很多聊技术的人会聊敏捷,聊敏捷似乎避免不了scrum,而scrum中经常出现的sprint这个东西,那么sprint在scrum中到底是什么呢?

    有人也许会说sprint就是是一个迭代(iteration),一个开发周期嘛,那么问题来了:
    sprint和我们之前认知的开发周期有什么区别?
    任何一个迭代都可以称为一个sprint吗?
    sprint背后到底代表的是什么?

    从sprint和scrum的关系开始聊起

    那么我们先从sprint和scrum的关系开始聊起吧,下面这张图是scrum的开发模型
    图片描述
    我们关注图中的蓝色部分,就是代表的sprint,可以很明显的发现,sprint是scrum的一部分,并且貌似还是很重要的一部分,它会有一个时间限制可能是4 weeks,在每个sprint过程中,我们会经历daily meetings以及并且会密切关注sprint burn down(燃尽图),我们会以sprint backlog作为开始工作的基础或者叫做输入,然后发布一定的product。

    这样简单介绍后,我们对sprint有了一个简单的认识。但是我们的问题并没有得到解答。

    接下来,我们就进入到sprint的里面,进行一番窥探,更多的去获取一些细节,希望从这些细节中发现sprint和一般的迭代以及开发周期有什么区别,希望我们会有收获,good luck。

    一个sprint会是怎么样的?

    • sprint有固定模式吗?

    在上一篇文章中,我提到过敏捷实践并没有固定的模式,那么sprint作为scrum这种敏捷实践的重要部分,是否会有固定的模式呢?从我的角度,我是觉得有的。

    比如在每一个sprint之初,都会制定sprint goal,都会基于sprintbacklog进行开发,并且估算每个故事进行时间估算,在过程中,都会经历每日会议并且关注燃尽图来保证sprint按照估算顺利进行。

    • sprint和开发周期的区别?

    展开全文
  • 我始终记得当年我作为敏捷教练所做的第一次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个问题:他们想开始做什么?他们想停止做什么?他们想继续做什么?
  • Sprint

    2019-06-21 14:15:15
    Scrum是一种迭代和增量式的产品开发方法,Scrum通过Sprint来实现迭代。一个Sprint是指一个1周-4周的迭代,它是一个时间盒。Sprint的长度一旦确定,保持不变。Sprint的产出是“完成”的、可用 的、潜在可发布的产品...
  • Python Sprint 报告

    万次阅读 2006-12-07 16:23:00
    为了便于参考,这里是关于本次 sprint[1] 的 wiki 页面和 py3k 的wiki页面。Python 3000 Sprint 的成果我将从本次 sprint 的 Py3k 部分的成果开始,因为我是最直接地参与了。热身在本次 sprint 的前几周,我已经对...
  • Sprint生命周期

    2020-07-29 14:20:36
    Sprint生命周期
  • 创建jira sprint SCRUM is a great way to manage all sorts of tasks including sprints, but you don’t have to purchase expensive software packages to burn one. Excel is a great tool for rolling your ...
  • 我们的Sprint未被取消(但是我对Scrum的信任是) (Our Sprint wasn’t cancelled (but my trust in Scrum was)) 为什么要取消Sprint以及不这样做会发生什么 (Why you should cancel a Sprint and what happens when ...
  • 什么是SCRUM首先要知道SCRUM是敏捷开发的方法论之一。 在学习SCRUM之前我们需要简单储备一下基本的知识。 什么是敏捷开发? 敏捷开发(Agile Development)是一种以人为核心、迭代、循序渐进的开发方法。...
  • sprint计划

    2020-06-23 14:07:22
    怎样制定sprint计划 sprint目标 团队成员名单(如果不是100%需要列出投入度:具体指出例如还要参加什么会议之类) sprint backlog(就是上一章提及的的backlog) 确定好sprint演示日期 确定好时间地点每天举行scrum...
  • 软件开发流程之Scrum/Sprint开发方法

    千次阅读 2015-06-10 17:12:36
    软件开发流程之Scrum/Sprint开发方法,从理论上看, 这个方法真是妙得很!
  • 如何决定Sprint长度?

    千次阅读 2013-10-21 14:03:44
    使用Scrum的组织通常会使用30天作为Sprint的长度,但是Scrum同样允许周期更短的Sprint。周期较长的Sprint通常用于变化较少的环境,而周期较短的Sprint则通常用于机会较多或者更具有挑战的多变环境。
  • Sprint计划

    2020-07-24 16:00:42
    对于敏捷中的活动有很多,本文先从Sprint计划开始,分享一些方法、建议和注意事项,这些对理解和实践Scrum都很有帮助。 Who? Sprint计划的参与者:整个Scrum团队。 请注意, Sprint计划是 一个积极的、合作的活动。...
  • 概述: 对于功能性的产品增量进行审视并调整。 参与者: 团队、产品负责人、ScrumMaster。...在Sprint结束后,就到了Sprint评审会议 (Sprint Review Meeting),人们会评审这个Sprint。出席会议的人有...
  • 白话SCRUM 之三:sprint backlog

    万次阅读 2013-08-23 14:59:47
    Sprint Backlog就是任务列表,如果映射到传统的项目管理理论中就是WBS(work breakdown structure),而且是典型的采用面向交付物的任务分解方法得到的WBS。比如有一个Product backlog 条目为: 作为系统的合法用户...
  • <p>I really don't understand the benefit of using <code>fmt.Sprint</code> compared to add strings together with <code>+</code>. Here is an example of both in use: <pre><code>func main() { myString :...
  • 接着上面说下决策树的另外
  • Sprint评审及回顾

    千次阅读 2013-05-23 08:03:36
    Sprint评审 在Sprint结束后,将进行Sprint评审,团队在此期间展示他们所构造的产品。出席此会议的有产品所有者,开发团队成员,ScrumMaster,加上客户,项目管理者,专家,高层人士和任何对此感兴趣的人。会议时间...
1 2 3 4 5 ... 20
收藏数 28,298
精华内容 11,319
关键字:

sprint