关于敏捷交付:从敏捷协作到价值交付

后面我的共事在分享的时候,指出目前软件研发的最大问题不是效率,而是研发资源的节约。可能产品经理半天写的需要,开发要埋头苦干三个月。如果谬误的抉择了一个对业务倒退有益的需要,会带着大家往谬误的方向越跑越远。 那么什么是正确的需要呢?咱们认为对于业务倒退有帮忙、贡献度高的需要视为有价值的需要即正确的需要,而基于有价值需要的一直演进,才会让咱们的业务倒退越来越好,产品越做越强。 明天我想和大家分享的就是云效我的项目合作在这个新课题上的摸索:从麻利合作到价值交付,从谋求效率到谋求价值。 首先,为新老朋友简略介绍一下云效我的项目合作这款产品。云效我的项目合作是面向企业级的研发合作平台,提供了我的项目、需要、迭代、品质等多个维度的协同治理以及相干的我的项目度量能力。过来一年,咱们落地了麻利研发以及规模化项目管理的合作场景。为了连贯各个角色,让大家围绕价值,顺畅、高效地进行合作,咱们持续在多团队分层合作场景中进行摸索,帮忙团队朝更有益于业务倒退的方向后退。 为了让分享更场景化,咱们从一个需要的交付作为切入点,看看在它的整个生命周期中,价值交付是如何影响到每个流程步骤、每个参加人员的。 一个需要从它的诞生到完结,往往会通过很长的流程步骤,经手过很多人。咱们从其中选取了三个重要的角色:业务、产品经理、开发经理,来看看他们在需要交付过程中都经验了什么艰难。 业务同学首先咱们聚焦到业务同学萧峰,看看他的工作中遇到了什么问题。 萧峰在这个月有一个重要的经营流动要上线。需要上个月曾经提给了产品,到了月中跟踪进度的时候发现产品尽管做了排期,然而开发因为种种原因没有做。经营流动是必定要如期上线的,这个时候萧峰就要紧急拉会,还要找各方协调资源。 原本需要在后期协调资源是能够很顺畅的交付,当初变得困难重重。这种状况萧峰不是第一次遇到了,很屡次的重要经营流动都演出了相似的场景。萧峰很苦恼,需要明明对业务这么重要,怎么还是总交付不及时呢? 为了解决萧峰的问题,云效我的项目合作提供了便捷、无效的交付进度追踪能力。 首先咱们去解决萧峰获取进度信息不便捷的问题。云效我的项目合作Projex能够显性化展现需要的交付进度。萧峰能够很快的看到需要曾经实现了哪些阶段、以后解决什么阶段、以及后续还要通过什么阶段才能够进行交付。 同时,他还能够同时查看需要在每个阶段的停留时长。如果需要在某个阶段停留时间过长,能够配合规定进行主动告诉。让萧峰能够很快的发现并看到交付卡点在哪里,及时辨认危险并解决,充分保证需要及时交付。 解决了进度信息获取不便捷的问题,还要解决进度同步不及时的问题。萧峰常常会遇到业务需要和交付需要之间状态不同步,带来跟进上的问题。为了解决这个问题,云效我的项目合作提供了进度自动更新的能力。 当一个研发工作进入到开发中,业务需要也会同步进入到开发中,这样萧峰再也不必费神去一个个查看撑持的事项状态,在业务需要中看到的就是实在的进度信息。 咱们来看看业务人员萧峰,他在应用云效前后工作上有什么改良: 从“原来的需要提完处于失联状态,交付到了什么阶段全靠问人”到”需要页面显性化展现进度,无需到处求人”从“危险信息总是滞后,最初影响交付。”到“需要阶段停留主动计时,及时辨认危险。”从“进度全靠手动保护,常常更新不及时”到“零碎自动更新进度,再也不费神同步”。云效我的项目合作让业务人员萧峰跟进需要更及时。 产品经理咱们持续下一个角色:产品经理小宝,看看她在工作中遇到了什么问题。 这是某天下班前,小宝收到的工作音讯。业务人员萧峰提了个经营流动需要,要下个月交付。接着她对接的开发经理,要下个月进行性能革新,因为不少用户反馈页面响应慢。再接着她的老板提了个指标布局需要,要尽快交付。这个时候的小宝,一个头两个大。谁都认为本人的需要很重要,然而肯定要有个先后顺序。毕竟开发人力只有这么多。 这种状况也不是小宝第一次遇到了,她始终都在苦恼,需求方这么多,谁提需要都是重要且紧急,那怎么排才对业务倒退更好并可能达成团队共识呢? 为了解决小宝的问题,云效我的项目合作提供了有根据的需要排序能力,让需要能够依据价值进行交付排序。 云效引入了主题的概念,散点的需要能够聚合到独特的主题内,主题有明确的业务指标和里程碑节点,并可进行价值评估。 小宝只须要让需求方确定业务指标影响,让开发评估老本。大家能够基于指标影响和老本进行探讨,达成共识后落入零碎,主题的价值分数就会主动出现。 哪些事件重要须要先做能够很快达成共识,小宝只须要依照主题进行需要优先级排序就能够。 咱们来看看产品经理小宝,她在应用云效前后工作上有什么改良: 从原来的“会开了一轮又一轮,还是说不清楚谁重要”到“说分明价值,谁先做自然而然出现进去”。从“原来的单个需要单个排,排完一轮又一轮”到“基于主题进行需要优先级排序。会开少了,交付布局却更加清晰明了。”云效我的项目合作让产品经理小宝更好地排需要。 开发经理咱们接下来看最初一个角色:开发经理虚竹,看看在他的工作中遇到了什么艰难。 某天和虚竹始终单干的业务同学,在群里忽然反馈,开发团队的反对度不够,客户投诉了。老板为了可能让团队之间顺畅的单干,让他和业务对齐,看看问题出在哪里。 这是虚竹在他的工作中时不时呈现的场景。虚竹很纳闷,明明团队里的小伙伴每天都加班加点,怎么会说反对度不够呢? 为了解决虚竹的问题,云效我的项目合作提供了主题角度的投入统计,开发投入在哪里高深莫测。 首先对于虚竹团队里的开发小伙伴,云效我的项目合作提供了单个需要溯源能力,可溯源至主题看交付的价值。让开发同学不再只抬头做事,也能够低头看业务。 同时对于虚竹的整个团队,云效我的项目合作提供了基于产品主题的统计能力。通过统计能够看出虚竹团队投入在什么主题上、每个主题的交付效率和趋势都高深莫测。让开发团队和业务、产品团队在同一个维度对话。 咱们来看看开发经理虚竹,他在应用云效前后工作上有什么改良: 从“接了一个又一个散点需要,团队的开发忙个不停。到年初谁也说不清本人做了什么业务奉献”到“单点的需要可溯源,团队的投入可被度量”。云效我的项目合作让虚竹团队的投入看得见。 总结至此,咱们别离聊了三个重要角色在工作中遇到的艰难和云效我的项目合作在产品能力上的反对。其实每个角色在合作过程中,都有角色特有的愿景: 萧峰心愿“如果需要曾经承诺了交付工夫,就请如期交付”;小宝心愿“我抉择的需要就是对业务有价值的”虚竹心愿“我的团队投入对业务无益,且能够被大家看见”云效我的项目合作帮忙他们实现了愿景。总结下来,云效我的项目合作的价值交付,其实就是在做三件事: 第一件事——让需要选得对:反对产品主题价值评估,让价值不再停留在每个人的脑海中,落在零碎中造成共识;围绕价值进行需要排序,永远先做重要的事。 第二件事——让进度追失去:反对显性化展现进度,不再须要到处问人;反对事项进度的自动更新,不再须要手动保护。 最初一件事——让投入看得见:通过业务视角进行交付统计,撑持多少业务价值的落地高深莫测。 云效的价值交付心愿帮忙千千万万个企业中的业务同学、产品同学、开发同学做有价值的事儿。 云效在合作畛域的摸索从未止步:从谋求效率到谋求效力,从面向流程到面向价值,突破职能边界,联通所有角色,让所有人都围绕价值合作。 云效我的项目合作,期待与你的相遇。 作者:径遥,阿里云云效 我的项目合作产品负责人 原文链接 本文为阿里云原创内容,未经容许不得转载。

December 29, 2022 · 1 min · jiezi

大多数Scrum团队遇到的挫败感是什么?

7月7日,Scrum社区聚集在阿姆斯特丹(荷兰)参加第5届Scrum Day Europe。目标是从Scrum社区生成见解并定义Scrum框架的改进。白天我们要求大家回答5个问题:在过去的20年里,Scrum的实力已被证明是什么?未来20年Scrum应该关注什么?到目前为止,Scrum最让你感到沮丧的是什么?什么连接你到Scrum?什么是可以添加到Scrum的小改进?每位参与者都贡献并提供了意见 因此它被证明是一个真正的社区活动!今年的主题是“下一次迭代”。因此我们回顾了Scrum在过去20年中给我们带来了什么,同时也期待着Scrum的未来。当然,评估是通过回顾展进行的。根据参与者,Scrum的优势是什么?这是一个简单轻巧的框架(6x)这是一个透明度促成因素(5倍)它提供了一个可持续和持续改进的框架(4x)它吸引了普遍基本的人类需求和价值观(3x)它提供短反馈循环,连续计划(3x)它消除了客户 - 供应商的界限(2x)这很有趣也很成功(2x)它是个人成长的推动者的使用时间盒它改善 了所有层的通信这不是一颗银弹 (尤指人们寄予厚望的某种新科技)它强调多学科团队合作根据参与者的说法,Scrum在未来几年应该关注什么?支持创造价值驱动型组织,关注客户满意度(9)加强整个组织的框架(9)保持简洁(3)在下一个sprint开始之前设置进程/网关(2)提供更多支持扩展Scrum的实践(2)证明Scrum工作的指标!(2)不断创新和适应提供工作 增量解决与非Scrum组织的接口问题建立实践以发展文化拥抱精益 思想整合DevOps 原则专注于Sprint 目标提供工具来检查产品的神智逐渐与多个独立组织合作为企业高管提供Scrum将Scrum应用于其他“慢速发展”行业,例如制药行业与评论家进行更多讨论,以了解他们在Scrum中缺少的感受研究敏捷是多么“敏捷”。因为有些组织滥用敏捷。根据参与者的说法,Scrum最让你感到沮丧的是什么?Scrum看起来很简单,但实在太难了(6)Scrum 僵尸 变体(5)对Scrum Master角色的误解(4)没有 授权的产品所有者(4)管理层不愿意改变(2)角色需要高于普通人Scrum和当前组织的值不匹配纯粹专注于软件开发不知道如何处理投资组合/产品管理缺乏做到这一点工作水 - 摔倒团队沟通根据参与者,您将什么与Scrum联系起来?Scrum工作,开始整理!(5)合作成瘾(5)令人敬畏的工作氛围(3)邀请人们不断改进,一次一小步(3)我个人得到了乐趣回到我的工作生活!(2)权力下放的决策(2)我在瀑布工作了21年Scrum的常识活下去!在工作和个人使用它活下去!处理unknows使用自动化软件帮助掌握Scrum流程Scrum Process Canvas是一个用于帮助您管理Scrum项目的Scrum工具 - 从识别项目愿景到最终产品交付,使敏捷项目更加简单有效。Scrum Process canvas可帮助您:在一个设计精美的Scrum流程画布中无缝导航整个Scrum流程。快速,轻松,无缝地执行Scrum活动。让整个团队充分参与。(开放Scrum Process Canvas快速导览 - 视觉范例)为每个Scrum团队打造。借助scrum流程画布,scrum工作项,敏捷管理工具和直观界面,Scrum Process Canvas可帮助您的Scrum团队在每个Scrum项目中取得最大成功。优先产品积压。通过识别业务目标(作为用例),Epics和用户故事,逐步构建产品backlog。整个项目中的新郎产品积压很容易。用例用户故事地图积压优先排序在用户故事地图中整理用户故事将用户活动,史诗和用户故事保存在结构良好的用户故事地图中。通过拖放轻松重新排列用户故事。点击编辑用户故事。通过Web访问故事地图,随时随地工作,节省时间并完成更多工作。通过更好的计划开始冲刺。sprint backlog管理器为敏捷团队提供了一个直观的界面,用于讨论和选择要包含在sprint中的故事,创建和估计任务。更快地创建Sprint Backlog借助表格界面和选择工具,快速将用户故事包含在sprint积压中。结果是一个明确的积压故事列表,整个团队可以在整个sprint中关注这些故事。努力估计任务列表从包含的故事中轻松维护开发任务列表。通过列表视图,准确地估算比较任务所涉及的工作量。让你的团队回到整个冲刺阶段。所有scrum工具都支持您的团队在整个sprint中将承诺的用户故事转化为功能性可交付成果。每日ScrumBurndown图表障碍日志Scrumboard进度跟踪回顾与回顾记录每日Scrum会议保留每个团队成员在每日Scrum会议中报告的工作,计划工作和遇到的障碍的记录。创建任务以管理每日Scrum会议中标识的操作项。轻松检索早期日常Scrum会议的内容。无缝迭代。一次执行一个sprint的sprint活动。轻松切换到任何早期的冲刺,随时查看其历史记录。敏捷发布管理。通过用户故事地图,您可以随时轻松地将故事添加和排列到发布分区中。项目可交付成果的状态也可以以临时方式更新。发布交付项目回顾轻松发布管理用户故事地图提供了一种可视化的发布管理方法。作为发布计划的一部分,您可以通过拖放将用户故事添加到发行版中。将每个人都放在同一页面上。有效管理团队成员的角色和职责。从一开始就将scrum master,产品所有者,业务分析师,UXers和开发人员放在同一页面上。即时文档,自动存档。生成产品待办事项,sprint积压,任务列表,各种会议等的报告。从可视化的Scrum cabinet中检索文档。内置任务管理平台。一站式敏捷解决方案提供了积压和任务管理之间的无缝集成。您可以在一个地方创建任务,报告和监控进度。单一软件,多种用途。使用UML,BPMN,ERD,DFD,UX(线框,原型设计),代码工程,ORM,思维导图等来加强您的Scrum项目。敏捷敏捷方法论敏捷开发ScrumScrum敏捷

March 5, 2019 · 1 min · jiezi

Scrum - 指导原则

雖然這篇文章討論了Scrum中的一些常見指导原则,但重要的是要記住這些指南是靈活的,應根據您團隊的需求進行塑造。當我提到規則時,我指的是那些無法修補以適應特定背景的方面。例如,沒有產品負責人,開發團隊和Scrum Master,您就無法做Scrum。當我提到指南時,我指的是那些可能被改變以適應特定背景的方面; 但是,影響只能在實施後進行驗證。然後我們相應地檢查和調整。例如,Product Backlog細化消耗不超過團隊容量的10%。容量是小時數,故事點數還是天數?嗯,沒有規則。Scrum團隊自我組織並選擇最適合他們背景的東西; 遵循我們消耗的指導方針,不超過團隊容量的10%。在這篇文章中,我將探討一些將11個要素綁定在一起的指南,並讓Scrum團隊靈活地將這些方面融入其背景中。#1。開發團隊規模建議開發團隊的規模為3-9名成員。根據具體情況,可能會有更多人或更少。它的影響因團隊環境而異。不到三個開發團隊成員減少了交互,導致生產率降低。較小的開發團隊可能會在Sprint期間遇到技能限制,導致開發團隊無法提供可能可釋放的增量。擁有超過九名成員需要太多的協調。大型開發團隊為實證過程提供了太多的複雜性。#2。開發團隊的標題/角色Scrum無法識別開發團隊中的任何標題/角色。在開發團隊中,每個人都是開發團隊成員。雖然在組織內,團隊成員可能擁有頭銜/角色。根據我的經驗,我沒有遇到任何只有一個頭銜/角色的團隊。#3。每日Scrum的三種問題格式我使用過的大多數團隊都使用了每日Scrum的三個問題的格式:昨天我做了什麼幫助開發團隊實現Sprint目標?今天我將做些什麼來幫助開發團隊實現Sprint目標?我是否看到任何妨礙我或開發團隊滿足Sprint目標的障礙?這三個問題只是以Scrum開頭的團隊的模板。只要他們專注於Sprint目標的進展,開發團隊就可以按照他們認為合適的方式構建他們的Daily Scrum。#4。活動時間表事件的時間框表示一個月Sprint事件允許的最長時間。指南是:對於較短的Sprint,時間限制通常較短。這是否意味著,對於為期兩週的Sprint,Sprint Planning的時間限制為四小時,Sprint Review為兩小時,Sprint回顧為一個半小時?沒有。只要滿足其目的,事件可以根據需要调整短/長,但它們不能超過最大分配時間。例如,Sprint計劃為期兩週的Sprint計劃活動如果達到目的可能會在兩小時內結束,如果不滿足,則可能會持續八個小時。#5。進展趨勢Scrum指南建議使用燒毀圖表和累積流量等實踐來監控進度。但是,團隊可以完全自由選擇他們認為合適的任何練習。根據我的經驗,我見過團隊創建視覺路線圖,基於里程碑的進度,旅程線,釋放燃燒圖表等。我們還需要記住,在復雜的環境中,只有經驗數據才能幫助我們做出正確的決策。#6。估計在 Scrum的指南介紹了需要積壓的產品項目來進行估計。如何估算它們完全取決於Scrum團隊。故事點,理想日,T卹尺碼,狗尺碼是一些方法。Scrum團隊可以做“沒有估計”嗎?當然,只要Scrum團隊能夠起草支持經驗主義的計劃,創建透明度,並幫助團隊在Sprint結束時創建可能可釋放的“完成”增量。Scrum團隊自行組織選擇適合其背景的內容。#7。工作分解在“選擇的工作將如何完成?”部分下。對於Sprint計劃,Scrum指南提到:開發團隊在Sprint的頭幾天計劃的工作在本次會議結束時進行分解,通常分為一天或更短時間。然而,這通常有助於發展團隊這樣做。根據我的經驗,我看到幾個團隊沒有將他們的工作項目細分到如此細緻的水平。他們了解如何將功能轉換為“完成”增量。#8。Sprint評論這是一項重要的檢查和調整活動,Scrum團隊與主要利益相關方就Sprint期間取得的成果進行合作,以及在下一個Sprint中可以做些什麼來優化產品的價值。Scrum指南還描述了Sprint Review中的元素:與會者包括Scrum團隊和產品負責人邀請的主要利益相關者。產品負責人解釋了產品待辦事項項目已“完成”且未完成的內容。開發團隊討論Sprint期間的情況,遇到的問題以及這些問題是如何解決的。開發團隊演示了它“完成”的工作,並回答了有關增量的問題。產品負責人會討論產品Backlog。他或她根據迄今為止的進展(如果需要)預測可能的目標和交付日期。整個小組就下一步做什麼進行合作,以便Sprint Review為後續的Sprint Planning提供有價值的信息。回顧市場或產品的潛在用途如何改變下一步最有價值的事情。審查下一個預期的產品功能或功能發布的時間表,預算,潛在功能和市場。對於已經獲得資助一年的Scrum團隊來說,在每兩週一次的Sprint評審中審查其預算是否有意義?也許不吧。並非所有上面提到的元素都適用於所有Scrum團隊。它們作為指導提供,以便Scrum團隊可以選擇在Sprint審核期間討論和触及產品交付的各個方面,因為他們認為適合他們的上下文。#9。發佈到生產每個Sprint的目的是創建一個可能可釋放的“完成”增量。這意味著增量需要處於可用狀態並滿足Scrum團隊的完成定義(DoD)。然而,將增量釋放到生產中的選擇由產品負責人決定。根據團隊的上下文及其創建的增量,Scrum團隊可能決定每個Sprint執行多個版本,每個Sprint發布一個版本,或者累積發布多個Sprint; 無論如何優化產品的價值。#10。完成的定義“完成”的定義有助於提高透明度,並對完成工作的含義達成共識。根據Scrum指南,Scrum團隊有望擴大他們的國防部並使其更高質量的更嚴格。同樣,這不是一個規則。取決於團隊的背景; Scrum團隊可能會在每次回顧中重新審視它的國防部,或者可能繼續使用相同的國防部,除非它學會了新的東西以提高產品的質量。結論這些只是Scrum指南中的一些指導原則。我想提出這種區別,因為我經常發現Scrum團隊與Scrum規則和指南混淆。幾乎沒有什麼是常見的 - 將Sprint計劃的時間安排為兩個星期的Sprint或開發團隊花費太多時間和精力將PBI分解為“任務” - 其他人並不常見。我相信這篇文章將幫助團隊確定Scrum的一些方面,他們可以修改這些方面以適應他們的背景。Scrum参考What are the Scrum Events?What are Scrum Ceremonies?What is Product Backlog Grooming?What are the 3 Important Questions in Daily Scrum?Scrum Sprint Cycle in 8 StepsWhat is a Sprint in Scrum?Heartbeat of Scrum - The Daily StandupDaily Scrum Meeting - A Quick GuideWhy Fixed Length Sprints in Scrum?What is Scrum Release Planning?What is Sprint Planning?What is Sprint Review? ...

February 22, 2019 · 1 min · jiezi

Scrum Master 如何做一个仆人领袖?

什麼是僕人式領導?雖然僕人式領導的觀念是一個至少可以追溯到兩千年的永恆概念,但現代僕人式領導運動是由Robert K. Greenleaf於1970年發表的,當時他發表了他的權威文章“僕人作為領袖 ”,他創造了這些文字。 “僕人式領袖”和“僕人式領導”。僕人式領導是一種非常社會化的領導風格。雖然傳統的領導力是關於“金字塔頂端”的人積累,囤積和鍛煉(通常會墮落為濫用)權力,但僕人式領導是與團隊分享權力,識別,優先考慮和滿足他人和幫助人們盡可能地發展和表現。必須強調的是,在說“仆人领导 - 是仆人第一”時,Greenleaf並不意味著僕人領袖應該順從,而是要真正想要服務,幫助他人。Greenleaf在AT&T擔任管理髮展總監近四十年,當他於1964年退休時,他被認為是世界領先的企業領導專家之一。傳統領導與僕人式領導為什麼僕人式領導是一種強大的管理風格僕人式領導是一個在過去十年中吸引了一些研究人員注意力的概念,他們的研究結果一致表明了這種領導風格的力量。綠葉的“僕人式領導的最佳測試”:多層次分析是2011年的研究由內布拉斯加-林肯大學的羅伯特·W·海登,美國即說:“這項研究實證檢驗羅伯特·格林里夫(1970)的僕人領導的開創性的銜接。他理論化的四個個人成果(健康,智慧,自由自主和服務導向)都是根據僕人式領導的既定維度進行測試的。所有相關性都是顯著且積極的。“領導者對領導者的信任和對組織的承諾的影響2013年由地中海社會科學期刊發表的南非瓦爾理工大學的理查德·奇諾莫納的研究得出結論:“結果表明,僕人領導積極地影響員工對領導者的信任以及員工對組織的重大承諾。“僕人領導和員工對主管的承諾,由美國德克薩斯州康考迪亞大學的Shane Sokoll於2014年在國際領導力研究期刊上發表的一項研究表明,“發現僕人領導對員工對主管的承諾產生了重大影響。" 以下是簡單的指導方針。它能幫助你作為Scrum Master成為一名僕人領袖。1.承諾將自己放在最後僕人式領導者和其他類型的領導者之間的區別,僕人式領導者首先是僕人而不是領導者。成為僕人領袖意味著您致力於將您的個人利益放在最後。換句話說,僕人式領導是對謙卑的承諾。成為僕人領袖不是關於你的成功,而是關於你所服務的人的成功。你不是關注的中心,你所服務的人應該成為關注的焦點。我們目前生活在一個人們喜歡吹噓他們在社交媒體上取得成功的世界,僕人式領導不是吹噓你的個人成功。如果您吹噓自己的成功或作為Scrum Master的能力,或者您使用Scrum成功交付的項目,我很遺憾地說這不是僕人式領導。這些成功都不屬於你,它屬於你所服務的那些人,你沒有權利宣稱它是你的並吹噓它。我經常對其他人的公司Scrum Master的職業道路有疑問,看來他們擔心Scrum Master會在他們的餘生中保持同樣的位置。Scrum Master的成長不應該通過她在組織結構圖中的排名來看待,而應該通過她的服務的影響來看待。雖然公司中有許多領導者在組織階梯上奮戰,但我很遺憾地說,但僕人式領導並不是要在組織結構圖中奮鬥。記住這一點,你將以激光為重點服務他人,遠離公司政治,保持中立和不偏不倚。把自己放在最後,讓別人成功的方式需要很大的謙虛。2.關注他人的偉大我見過很多人問過我,“ 如果我的團隊沒有按預期交付我不應該懲罰他們嗎?“很多人還問我,” 如果有一個團隊成員沒有像其他團隊成員一樣快或多快地交付,我不應該懲罰那個人嗎?“許多公司和領導人多年來一直堅持”獎懲“模式。這種領導風格不再適用於21世紀,因為它不具有人性化。用棍棒和胡蘿蔔來懲罰表現不佳的工人的時代已經結束。我們已經通過它,我們應該在上個世紀留下它。懲罰表現不佳的傳統模式對我個人來說從未有任何意義。這只是感覺不對。僕人領袖應該幫助一個表現不佳的人,並將他們提升到更大的水平。僕人領袖總是在服務於讓別人變得偉大,而不是懲罰,指責或判斷他們。一個Scrum Master會問一個表現不佳的團隊成員,“ 我能為你做些什麼,這樣你才能成為偉大的並讓你擺脫這種局面?“你作為僕人領袖的目標不是你的偉大,而是其他人的偉大。您可能需要加倍努力或犧牲您的個人資源才能使它們變得更好。“ 但是,但是,如果我們試圖指導那個人並且他仍然沒有改變怎麼辦?“我個人認為人類是成長的動力。沒有人在早上醒來只是為了最壞。我們應該通過他們的鏡頭而不是我們的鏡頭來看待故事,而不是根據我們所看到的結論得出結論。我們應該先看看自己。僕人式領導者是一種領導者,他積極主動地解決問題的核心,這樣她就可以讓其他人變得很棒,而不是根據她所看到的結果做出結論。通過關注他人的偉大,我們對別人的評價就會減少,我們會讓別人感到安全。僕人式領導者專注於創造一個人們可以茁壯成長並成為自身最佳版本的環境,而不是人們變得具有防禦性和自尊心低的環境。3.尊重他人需要完全人性化我們一直生活在工作場所只是工作場所的信念之下,在那個系統之外我們可以完全是人。許多公司都提倡工作與生活平衡的概念,因為他們認為工作場所是關於工作的,而在該系統之外的是生活。你沒有在工作場所生活。在這種信念中,人們需要關閉他們的人性,並在每次進入工作場所時將其留在家中。我個人認為,完全是人類是一項基本需求,不應該被關閉。無論是在工作場所還是在工作場所之外,人們都需要成為人。僕人領導者不區分工作場所內外的人。僕人領導關心員工在工作場所的福祉。僕人領袖個人對她的人民作為人類感興趣。她是一個人。憐憫可能不是我們在公司環境中聽到的常見詞彙,但作為僕人式領導者,我們需要富有同情心和好奇才能對我們所服務的人產生個人興趣。要有同情心和好奇,你需要是真誠的,你不能偽造它。我還記得我的老闆告訴我的一句話,“ 不要帶著問題來找我,帶著解決方案來找我。“每當我聽到有人這麼說時,我總覺得不舒服。這聽起來不對,儘管我認識的很多人都認為這是管理層的標准信念。這種信念讓我感到氣餒,因為我覺得我需要獲得老闆的批准。如果我不能帶著問題來找我的老闆,我還能信任誰來幫助解決我的問題?在這種信念中,似乎我需要完美,我不能錯,我不能犯錯誤。僕人式領導者創造了一個環境,人們可以在工作中感到安全,完全是人,就像人們在他們的朋友和家人中感到安全,完全是人。她的人民應該說“ 我不知道 ”或“ 我失敗了,我需要幫助 ”,而不必擔心工作中的判斷或懲罰。當一個僕人領導有問題而不是告訴他們稍後帶著解決方案回來時,會邀請他們。我們隨時為他們服務。她的人民可以創造空間和時間來反思他們的錯誤。人們可以做一個能為公司帶來價值的實驗,而不必擔心失敗。勇敢說出真相僕人領袖有勇氣說實話,即使這會讓別人感到不舒服甚至抵抗。她沒有給她發送的任何信息加糖,因為她希望她的員工能夠改進並獲得新的體驗。她走的是講話,她的每一條信息都有完整性。真相可能不是過去人們習慣聽到的,因為真理沒有為政治創造空間。僕人領袖不是安全的,也不擔心說實話,因為她知道她的目標是他人的偉大。無論她做這件事有多困難,僕人領袖都會說實話。僕人式領導者不偏不倚,沒有任何收藏,否則會降低她為整個組織帶來的服務質量。告訴真相對於許多人來說永遠不會感到舒服,因為我們擔心真相會傷害他人,否則會使我們在工作場所的未來付出代價。有時候我們只告訴老闆他想听到什麼,因為我們害怕受到懲罰,或者我們不會得到他的認可。僕人領袖是不同的。僕人領袖是真誠的,她沒有隱藏的動機,也沒有個人對她的信息感興趣。說出的真相將把她所服務的人民和組織帶到一個新的高度,而不是傷害他們。事實將促使人們以不同的方式思考而不是保持現狀或住在舒適區。僕人領袖創造了一個人們可以安全地說出真相並說出真相的環境。5.開放性關於你自己的漏洞我們從上面的觀點中看到,僕人式領導者如何專注於為更大的利益服務他人。僕人式領導者也是一位對自己的弱點持開放態度的領導者。一個僕人領袖謙虛地說她沒有所有問題的所有答案,她給出的任何建議都不能作為絕對真理。僕人式領導者謙虛地不吹噓她自己,同時對她的不完美持開放態度。許多人認為,當領導者對她的脆弱性持開放態度時,這表明她很脆弱。有些人甚至可能會說她沒用。畢竟,在企業環境中,我們以我們的能力來衡量,因此在公開場合公開我們自己的漏洞會被其他人視為我們作為領導者的無能力。對我們自己的漏洞保持開放是對他人的一種服務形式,以便其他人也可以安全地對他們開放。這是我們從服務對像那裡獲得信任的唯一途徑。當我們獲得他們的信任並且他們對自己的脆弱性持開放態度時,我們可以為他人服務。當領導者有勇氣對自己的脆弱性持開放態度時,人們會感到舒適並且不會害怕判斷。人們會信任領導者,並且當領導者首先對她的人民表現出對她的脆弱性的開放態度時,他們會對自己的漏洞保持開放態度。成為僕人領袖需要謙虛。當僕人式領導不是我們社會中許多公司或領導者所採用的標準時,成為僕人領袖並不容易。對我個人而言,這對我個人來說從未如此簡 我個人仍然在努力成為一名僕人領袖。作為僕人領袖並不容易。但我相信,作為一名僕人領導者,與其他領導者相比,使我們與眾不同,是什麼能夠為這個世界帶來變化。我使用上面的指導作為我自己的動力,繼續提高我的僕人領導能力。期待在未來多年看到你作為僕人領袖的美麗工作的結果。綜上所述Scrum Master 采用僕人式領導需要將团队的需求放在首位。僕人式領導者主要關注团队的成長和福祉:首先為他人服務,對於希望在團隊成員中發揮最大作用的現代管理者來說,僕人式領導是一個強大的工具。

February 22, 2019 · 1 min · jiezi

User Stories - 最佳实践 (Best Practices)

在转向敏捷之后,很多团队开始使用“用户故事”一词。用户故事是一种简单而优雅的技术,可以收集客户需求。然而,它需要一定的理解和实践才能用User Stories构建出色的软件。让我们仔细看看用户故事是什么以及如何使用这种技术取得成功。什么是用户故事?用户素材是对功能的简短描述,它为用户或客户带来价值,团队可以在迭代中提供这些功能。用户故事应该回答3个问题:我们为谁建造它? - 作为<用户类型>我们在建什么? - 我想<feature>我们为什么要建造它? - 这样<值或利益>在此之后,用户故事的典型格式是:作为<用户类型>,我想要<feature>,以便<value或benefit>。用户故事示例:作为注册用户,我希望能够将我的图片下载到我的个人资料中,以便其他用户可以看到我的样子。有没有创建用户故事的程序?没有正式的过程来创建用户素材。尽管如此,还是应该遵循一条准则来创建一个好的用户故事。它被称为3 C,由极限编程的创始人之一Ron Jeffries提出。该卡是用户故事的书面说明。它没有捕获有关应该构建的内容的所有详细信息。相反,它是一个提醒,是对必须进行的后续通信的承诺。对话用于讨论用户故事的细节。它可能会被一些文档补充。确认由用户验收测试表示,确保用户故事满足用户/客户的验收标准。如何撰写高质量的用户故事确保用户故事具有适当质量的良好做法是遵守Bill Wake的INVEST首字母缩略词的标准。INVEST还有助于确定用户故事是否已被充分理解并为开发团队开始工作做好准备。独立 - 用户故事不应该依赖于另一个用户故事,因此用户故事可以按任何顺序开发。可协商 - 用户故事的详细信息通过产品负责人和开发团队之间的口头对话进行协商。有价值 - 用户故事应该为用户/客户带来所需的价值。估计 - 开发团队应该很好地理解用户故事来估计它。小 - 用户故事应足够小,以适应迭代。可测试 - 应为用户故事编写正确的验收标准,以便进行验证。什么不是用户故事?让我们对自己说实话:用户故事不能通过其定义成为“技术用户故事”,因为在这种情况下它不会给用户/客户带来直接价值。不过,许多团队喜欢在需要执行代码重构等技术任务时创建用户故事。我建议将其他工作项用于此类任务,并与您的产品负责人就此类工作达成一致,以便了解为何需要这样做。这同样涉及非功能性需求任务,界面设计任务,复杂的用户交互任务或错误。您可以自由地为这些任务创建其他工作项。例如,Constraint Story可用于表示非功能性需求。用户故事是捕获产品功能的绝佳技术,但我们没有义务将其用于所有目的。谁是用户?在编写用户故事之前,应该清楚地了解创建用户素材的用户是谁。有时它被新用户故事技术的团队所忽视,他们最终创建了具有不必要功能的软件。因此,做一个适当的用户研究,让你的所有用户类型或用户角色或角色写下来并描述。可以帮助您解决此问题的两种技术是用户角色建模和角色。谁负责撰写用户故事?通常,客户代表(例如产品负责人)负责用户故事。尽管如此,用户故事并不是从顶级到团队的规范,而是产品负责人和团队之间的协作技术。这就是为什么如果用户故事是协作编写的话会更好。一个很好的方法是做一个故事写作研讨会。细节在哪里?由于用户故事不是规范,因此详细信息以不同方式传达:3 C指南中的第二个“C”是Conversation。对话是敏捷最重要的方面之一。因此,大多数细节都是通过客户代表和开发团队之间的口头沟通来传达的。第三个“C”是确认。用户验收测试确认用户故事满足用户/客户的验收标准,并且它们用作正式的文档详细信息。BDD(行为驱动开发)是一种编写验收测试的好方法。如果需要,某些用户故事可能包含其他书面详细信息。你怎么知道用户故事何时完成?使用“完成定义”技术。简而言之,Done的定义是团队成员之间对工作完成意义的共同理解。完成的定义通常以活动清单的形式创建,其表明商定的价值(用户验收测试以满足用户验收标准)和质量(以满足质量标准)。团队有时会忽略最后一个,在迭代结束时,什么可以使用户故事不可能发送给客户。完成技术的定义有助于避免这种情况。完成定义的示例:完成时间:单元测试通过代码经过同行评审用户验收测试通过集成测试通过回归测试通过用户指南已更新如何开始定义产品范围?在项目开始时,我们需要定义产品的粗略范围,以便对其有全局视野。这可以通过Epics完成。史诗是一大块工作,有一个共同的目标。Epic可以被视为占位符,用于稍后创建的更详细的用户故事。Epic通常需要多次迭代才能完成。什么是组织用户故事的最佳方式?使用由Jeff Patton发明的故事映射技术 (User story Mapping)。故事映射代表了一种自上而下的需求组织方法,也是确定优先级和规划的好方法。对BABOK®Guidev2的敏捷扩展指出:“故事映射提供了解决方案支持的活动序列的视觉和物理视图。它使用二维网格结构来显示产品在水平维度上的关键方面的顺序和分组,详细信息和优先级关于垂直维度的故事。故事映射是一种分解技术,它允许从端到端视图开始逐步理解解决方案,并深入到详细的用户故事。故事映射示例 (Visual Paradigm User Story Mapping):https://www.youtube.com/watch…

February 18, 2019 · 1 min · jiezi

用户案例 - 3Cs

3C’s = 卡 (Card),会话 Conversation),确认 (Confirmation)”;这个模板(来自Ron Jeffries)捕获了用户故事的组成部分:第一个C (Card) 是原始形式的用户故事,即卡片。用户故事手动写在索引“卡”上,以保持简洁。标准格式有3个基本组件:作为[用户类型],我想/需要[目标],以便我可以完成[理由/商业价值]。该卡只是一个占位符。第二个C (Conversion) 是对话。对话有必要获得有关卡的更多详细信息。该对话促进了敏捷团队之间的增量和持续协作,以便围绕问题和潜在解决方案建立共同理解。第三个C (Confirmation) 是确认。确认是接受标准,它捕获基本要求并将其转换为测试标准,以便我们知道何时成功交付了用户故事。1.卡 (Card)用户故事应该能够放在3“x5”便条卡上,有效地捕获最重要的信息。虽然这个“C”有时指的是实际的记录卡,但我们的意思是它指的是用户故事的最佳尺寸。正如杰弗里斯所写,卡片不应包含有关要求的所有信息,而是足以用于规划识别要求并提醒项目团队的故事。每个用户故事都应遵循以下标准化格式:“作为[特定用户],我想[执行此操作],以便[我可以实现此目标。]” 专注于收集每种用户类型的用户故事,以创建一组最具代表性的用户故事。用户故事应尽可能直接由用户编写。但是,根据项目类型和组织细节,用户故事也可以由项目团队成员和/或产品所有者编写。可以使用常见的启发技术(如访谈,问卷调查,观察和用户故事撰写研讨会)收集完整的用户故事集,以确保用户故事准确反映用户需求。2.对话 (Conversation)在用户故事即将被放入sprint之前,产品所有者应该与客户讨论他们的用户故事(或与其业务领域相关的用户故事)以进行详细说明和验证。与用户的协商对话是必要的,因为用户故事可能难以解释,可能需要一些背景知识来实现,或者自编写故事以来需求可能已经改变。对话代表项目团队与产品所有者或其他利益相关者和商业中小企业之间的讨论。在这些对话中,产品所有者告知利益相关者正在发生的事情,利益相关者或团队成员交换想法,意见和感受。对话应在整个项目生命周期中进行。虽然我们主要讨论口头讨论,但对话还可以包括通过电子邮件,内部聊天程序或通过需求管理和业务分析工具(如Enfocus Requirements Suite™)进行的电子通信。3.确认 (Confirmation)用户故事的最后一个组成部分是用于确认用户故事是否已正确实施并成功交付的验收标准。必须在开发开始之前定义验收标准,以确定每个用户故事何时完成并按用户的意图工作。验收标准可用于演示用户故事的界限,并且通常在产品所有者,项目团队和用户之间进行对话时进行考虑。建议用户是编写验收标准的用户,因为每个用户故事都是从用户的角度编写的 - 因此确保用户故事完成和满意的测试也应由用户编写。最好是这样定义验收标准的细节正是时候用户故事被放置在一个冲刺前。提供太多细节是浪费和耗时的,因为如果用户故事发生变化,则还需要更改细节。但是,提供太少的细节通常会导致重大的返工,并迫使开发人员做出错误的假设。它们应该被写成勉强够用; 也就是说,用户故事应该只包含启用开发所需的绝对最小信息量,并允许测试以合理的效率进行。这样做的理由是最大限度地减少在不增加最终产品价值的任何事情上花费的时间。敏捷软件开发文章什么是敏捷软件开发?什么是用户故事?什么是用户故事映射?用户故事与敏捷软件开发的使用案例

February 18, 2019 · 1 min · jiezi

Scrum:为什么Sprint长度应该短?

短跑运行在短在一段有限的时间距离。它被用于许多包含跑步的运动中,通常用作快速到达目标或目标的方式,或避免或抓住对手。为什么短冲刺?你应该有一个足够短的迭代,以保持团队的注意力,但足够长,以提供有意义的工作增量。在Scrum的指南限制了冲刺长度为一个月。失败快 - 太小导致不会失败短Sprint的优势来自于尝试某些事情(快速失败),获得快速反馈,然后快速检查和调整的策略。在存在高度不确定性的情况下,开始研究产品通常会更便宜,了解我们是否做出了一个好的决定,如果没有,在花更多的钱之前快速杀死它。快速失败:为什么短跑长度必须短?类似于Kaizen(改善)的想法,它是日语中的“改进”。在商业领域,改善是指不断改进所有职能并让所有员工从首席执行官到装配线工人的活动。分析这些变化的结果并重新开始微调。以这种方式,可以提高正在执行的任务的生产率或质量。一点一点地做出微小改变远比一次性解决所有问题更有效。我们的想法是让变更变得如此简单,以至于在实施过程中很难失败。首先,我们养成了改变的习惯。然后我们添加新的更改或稍微改变更改的里程碑,以便我们可以逐步改进。一个接一个地应用调整很重要。这个想法是为了避免选择应用和何时应用的复杂性。这样我们就能够分析每个小改进的结果。如果我们同时申请几个,我们将不知道哪个有效,哪个没有。或者一个人的效果是否已经抵消了另一个人。Scrum - 持续改进Scrum框架基于经验主义,它依赖于透明度,检查和适应性。在Scrum事件和工件协助定期检查和调整,导致持续改进。在sprint计划期间,scrum团队会检查产品积压并调整sprint目标,预测和sprint积压。在每日Scrum期间,开发团队会检查sprint目标的进度并调整sprint backlog。在冲刺审查期间,Scrum团队和利益相关者检查增量,冲刺和产品积压并调整产品积压。Scrum - 持续改进最后,sprint回顾展是scrum团队改进的正式活动,scrum团队通过实施可行的,可持续的改进来检查围绕人员,关系,流程和工具的冲刺。

February 15, 2019 · 1 min · jiezi

为什么 scrum 开发人员是一个 t 形的人 ?

(Source: Scrum.org)Scrum Developer是一个T形人一个T-型的人有两种特性的,因此使用字母“T”来形容他们。字母“T”的垂直笔划描述了他们所具有的特定领域的深层技能,而水平笔划描述了跨多个学科的协作处置。它由两件事组成,即对其他人的学科的同理心和热情,以至于他们可能真正开始练习它们。只熟悉某个特定领域的人称为I形人。下图解释了I形人和T形人之间的差异。T-形Scrum开发人员从上图中可以看出,Scrum开发团队的测试工程师需要具备的技能不仅仅是“点击测试”,他们应该有_一些_编程,分析,设计,开发,技能等。分析师应该有技能超越“分析”,他们有望进行_一些_编程,测试工程,设计,营销,技能等。设计师有望拥有“设计”技能,预计会有一些编程,测试和分析技能。嗯,你明白了。因此,我们认为分析师不会比程序员和程序员更高的位置,而不是测试工程师。在像软件开发这样的创意产业中,在开发团队中拥有T形人员非常重要。James Shanteau做了一项研究,发现专家(I-Shaped people)的判断既不符合该领域专家的判断,也不符合内部一致性。在开发团队中拥有许多T形人员可提供创意行业急需的广泛见解。IDEO - 着名设计公司的首席执行官蒂姆·布朗表示,拥有一个T形人很重要,因为他们能够建立在其他人的想法基础之上,并不会立即抛弃你自己的竞争理念。T形人从另一个角度想象这个问题 - 站在别人的鞋子里。T-形人也非常热衷于其他人的学科,以至于他们可能真正开始练习它们。T-形人不是一个真正的新概念,在文艺复兴时代,有很多T形人,仅举几例着名人物:莱昂纳多达芬奇 - 画家,雕塑家,建筑师,音乐家,数学家,工程师,发明家,解剖学家,地质学家,制图师,植物学家和作家。Galileo Galilei - 物理学家,数学家,工程师,天文学家和哲学家。Nicolaus Copernicus - 数学家,天文学家,医师,经典学者,翻译,州长,外交官和经济学家。T-形人不是通才,他们在一个领域拥有深厚的技能,但也有其他技能可以帮助他们与其他开发团队成员合作。例如,伽利略和哥白尼是众所周知的天文学家。哇,你可能认为开发人员拥有的技能太多,这些开发人员是否存在?是的,他们存在,但不幸的是,他们中的大多数人已经很高兴与一家好公司合作。而且由于软件正在吞噬世界,软件的作用越来越重要,我们需要提高游戏的门槛。

February 15, 2019 · 1 min · jiezi

极限编程 (Extreme Programming) - 迭代计划 (Iterative Planning)

(Source: XP - Iteration Planning)在每次迭代开始时调用迭代计划会议,以生成该迭代的编程任务计划。每次迭代为1到3周。 客户从发布计划中按照对客户最有价值的顺序选择用户故事进行此次迭代。还选择了要修复的失败验收测试。客户选择的用户故事的估计总计达到上次迭代的项目速度。用户故事和失败的测试被分解为支持它们的编程任务。任务记录在索引卡上,如用户故事。虽然用户故事是客户的语言,但任务是使用开发人员的语言。可以删除重复的任务。这些任务卡将是迭代的详细计划。开发人员注册执行任务,然后估计他们自己的任务需要多长时间才能完成。对于接受任务的开发人员而言,重要的是估计完成任务所需的时间。人们不可互换,而且要完成任务的人必须估计需要多长时间。每项任务应估计为1,2或3(如果需要,添加1/2)持续时间的理想编程天数。如果没有干扰,理想的编程日期是完成任务需要多长时间。短于1天的任务可以组合在一起。超过3天的任务应该进一步细分。现在再次使用项目速度来确定迭代是否超过预定。在任务的理想编程天中总计时间估计值,这不得超过上一次迭代的项目速度。如果迭代次数太多,那么客户必须选择要推迟的用户故事,直到稍后的迭代(也叫雪耕 - Snow Plowing)。如果迭代太少,则可以接受另一个故事。任务天的速度(迭代计划)会覆盖故事周的速度(发布计划)因为它更准确。看到用户故事被雪覆盖通常令人震惊。不要惊慌。记住单元测试和重构的重要性。任何一个领域的债务都会让你失望。在安排之前避免添加任何功能。只需添加您今天所需的内容。添加额外的东西会减慢你的速度。不要试图改变你的任务和故事估计。规划过程依赖于一致估计的冷现实,将它们勉强降低会产生更多问题。密切关注您的项目速度和积雪。您可能需要重新估算所有故事并每三到五次迭代重新协商发布计划,这是正常的。只要您始终首先实施最有价值的故事,您将始终尽可能为您的客户和管理层做好准备。迭代开发风格可以为您的开发过程增加灵活性。通过不比当前迭代更远地规划特定的编程任务来尝试及时规划。

February 13, 2019 · 1 min · jiezi

极限编程 (Extreme Programming) - 发布计划 (Release Planning)

编写用户故事后,您可以使用发布计划会议来创建发布计划。发布计划指定 将为每个系统版本实现哪些用户故事以及这些版本的日期。这给出了一组用户故事供客户在迭代计划会议期间进行选择,以便在下一次迭代期间实施。然后将这些选定的故事翻译成单独的编程任务,以在迭代期间实现以完成故事。在迭代期间故事也被转化为验收测试。这些验收测试在此迭代期间运行,并且随后的迭代将验证故事何时正确完成并继续正常工作。当项目速度 在几次迭代中发生显着变化时,或者在任何情况下,在几次迭代之后继续进行,并安排与客户的发布计划会议并创建新的发布计划。发布计划以前称为承诺计划。更改名称以更准确地描述其目的,并与迭代计划更加一致。

February 13, 2019 · 1 min · jiezi

极限编程 (Extreme Programming) 和用户故事 (User Stories) 的关系

(Source: User Stories)用户故事与用例具有相同的用途,但不尽相同。它们用于为发布计划会议创建时间估计。它们也用于代替大型需求文档。用户故事由客户编写,作为系统需要为他们执行的操作。它们与使用场景类似,不同之处在于它们不限于描述用户界面。它们的格式为客户在客户术语中编写的大约三个句子,没有技术语法。用户故事也推动了验收测试的创建。 必须创建一个或多个自动验收测试以验证用户故事是否已正确实施。用户故事最大的误解之一是它们与传统的需求规范有何不同。最大的区别在于细节层次。用户故事应该只提供足够的细节,以便对故事实施的时间进行合理的低风险估计。在实施故事的时候,开发人员将转到客户并获得面对面的要求的详细描述。 极限编程流程图开发人员估计故事可能需要多长时间才能实现。每个故事将在“理想的开发时间”中得到1,2或3周的估计。这个理想的开发时间是在代码中实现故事所需的时间,如果没有干扰,没有其他任务,并且您确切知道该做什么。超过3周意味着您需要进一步打破故事。不到一周的时间,你的水平太过细致,结合了一些故事。大约80个用户故事加上或减去20是在发布计划期间创建发布计划的完美数字。故事和需求文档之间的另一个区别是关注用户需求。您应该尝试避免特定技术,数据库布局和算法的详细信息。您应该尝试将故事集中在用户需求和优势上,而不是指定GUI布局。

February 13, 2019 · 1 min · jiezi

敏捷开发: 超级易用水桶估计系统

“水桶估计系统”是一种用中小型人群估计大量物品的方法,并且可以快速完成。水桶估计系统具有以下特性,使其特别适用于敏捷环境:它 很快!可以在一小时内估算几百件物品。这是 合作的。一组中的每个人大致平等地参与。它提供 相对结果而不是绝对估计(点数与小时数)。结果无法追溯到个人,因此它鼓励 小组负责。与 团队合作估算工作量或与 利益相关者合作估算价值。水桶估计系统流程水桶估计系统的估算工作如下:按照下图设置物理环境。确保所有要估算的项目都写在卡片上。从集合中随机选择一个项目。把它读给小组。将它放在“8”桶中。这个项目是我们的第一个参考项目。从集合中随机选择另一个项目。把它读给小组。该小组讨论了其在规模上的相对位置。一旦 共识已经达成,把该项目在适当的桶中。随机选择第三个项目,经过讨论并达成共识后,将其放入适当的桶中。如果随机物品已经明显地将刻度朝向一端或另一端倾斜,则重新缩放物品(例如,如果第一物品实际上非常小并且应该在“1”桶中)。分而治之。将所有剩余项目均等地分配给所有参与者。每个参与者将项目放在规模上而不与其他参与者讨论。如果一个人有一个他们真正不理解的项目,那么该项目可以提供给其他人。完整性检查!每个人都悄悄地审查规模上的项目。如果参与者发现他们认为不合适的项目,欢迎他们提请小组注意。然后该小组讨论它,直到达成共识并将其置于其中一个桶中。在卡片上写下桶号,以便记录估算值。需要考虑的一些要点:多个项目可以在同一个存储桶中。项目不能放在“桶”之间以表示更精确的估计。如果项目的分布倾斜到比例的任何一端,那么在完整性检查步骤期间,该组还应该讨论项目是否可以并且应该在比例尺上更均匀地展开。如果是这样,那么该小组就会集体进行。辅导员应注意确保在“健全检查”步骤之前没有人移动已经放置的物品。参与者之间的项目划分不需要完全相同 - 不要担心“处理”项目。相反,只是粗略地划分它们。如果“分而治之”阶段有一两个人通过他们的项目工作非常缓慢,建议他们与已经完成的人分享剩余的项目是可以接受的。个人完全弃权是不可接受的。如果有人想要投弃权票,他们应该被告知这意味着他们将不会在估计中有任何未来的发言权。在“分而治之”阶段,保持绝对沉默至关重要。特别是,不应对项目进行双边讨论。这是为了保护尽可能多地放置物品的个人的匿名性。水桶估计系统是一种很好的替代估算方法,可以尝试代替规划扑克。它比规划扑克快得多,但仍能获得合理的结果。

February 13, 2019 · 1 min · jiezi

SPIDR - 完美分割用户故事的五种简单技巧

根据INVEST原则,对用户故事的要求是它必须“足够小”或具有合适的大小。用户故事应该足够小,可以在冲刺中完成6-10个。当然这也取决于开发团队的速度。为了原则上实现这一目标,必须相应地分割大型故事。在下文中,我想向您介绍Mike Cohn的简单快速的SPIDR方法。他总结了五种技术,几乎每个大型用户故事都可以分为几种。钉鞋Spike是敏捷软件开发中使用的术语。尖峰是功能的小型原型实现,通常用于新技术的评估和可行性。该方法涉及调查和建立知识。如果其他SPIDR方法效果不佳,则应该使用它。借助这些新获得的知识,可以更好地理解一些故事,并可能更容易地分裂。然而,该方法相对抽象,因此比其余方法更难应用。路径如果用户故事中有多个可能的备用路径,则一个选项是从这些路径中的某些路径创建单独的用户故事。为每条路径写一个故事并不是绝对必要的,只要它有意义。例如,让我们看一个用户想要在线商店购买的用户故事。现在有两种可能的途径:使用信用卡付款或使用Paypal付款。理论上,信用卡付款可以进一步细分,但你需要权衡每种类型的信用卡是否有自己的故事。然而,支付购买的首要任务分为上述两种备选方案。因此,新创建的故事更小,更容易估计。接口在该上下文中的接口可以是例如不同的设备或设备类型,例如由iOS或Android供电的智能电话。用户故事也可以根据这种多样性进行划分。让我们坚持使用不同操作系统的示例:例如,在项目中,可能存在仅与Android设备的使用相关的用户故事,或者专注于Web浏览器的其他用户故事。为了避免使故事过于庞大和全面,您应该问自己要开发哪些设备或接口。也许第一个开发结果应该只引用iOS设备,因为可能更大的目标组。数据当初始故事仅涉及相关数据的子范围时,可以使用另一种用于分割用户故事的技术。以一个旨在吸引游客到特定城市的网站为例。例如,如果它是以博物馆而闻名的城市,那么第一个故事可能包括该地区不同博物馆的信息。随后的故事可能包括穿越城市的各种旅游,以及另一项户外活动。规则业务规则或技术标准可能是另一个分裂因素。以在线购买电影票为例。通常存在约束,例如基于相应电影的业务要求,例如每个电子邮件地址最多五个票的在线购买限制。有了这个故事,可以想象开发团队省略了这个限制,允许每个访客购买尽可能多的门票。然后可以在第二次迭代步骤中添加限制。像这样的增量交付意味着初始故事不会立即完全实现,而是以几个较小的步骤提供。有时忽略技术规范或业务规则是有意义的,如果通过这样做,您可以更快地实现满足用户或客户的可呈现结果。可以在以后检索省略的故事。小用户故事 - 更容易实现用户故事分裂并不总是那么容易:许多初学者倾向于将他们的故事过于全面而且过于庞大。但是,当涉及到开发团队的改进,并最终实现故事时,很快就会发现必须制作更小的故事。在我之前关于写(好)用户故事的博文中,我坚持认为故事应该是“可估计的”和“小的”。如果您知道如何分割大型故事,则更有可能发生这种情况。正如编写用户故事一样,练习也是完美的。敏捷软件开发什么是敏捷软件开发?什么是用户故事?什么是用户故事映射?用户故事与敏捷软件开发的使用案例

February 12, 2019 · 1 min · jiezi

权威指南: 如何写好用户故事?

在这篇文章中,我们将介绍如何编写好的用户故事以及应该包含哪些内容。用户故事代表一小部分功能,具有团队可以在冲刺中提供的业务价值。用户故事和传统需求文档之间的区别在于详细程度。需求文档往往包含大量文本并且非常详细,而用户故事主要基于会话。我们可以将用户故事的结构分解为:需要的简要说明在积压修饰和sprint计划期间发生的对话以巩固细节确认故事圆满完成的验收测试在编写用户故事时要记住的一个重点是,它们是从最终使用该产品的用户的角度编写的,因此在编写用户故事时我们必须清楚地识别用户是谁。如何写好用户故事根据经验,一个好的用户故事应该遵循INVEST的缩写:I ndependent - 用户故事不应该相互依赖,因此它们可以按任何顺序开发。N egotiable - 避免太多细节; 保持灵活性,以便团队可以调整实施的故事数量。V aluable - 故事应该为其用户提供一些价值。E stimable - 团队必须能够估计故事。S商城 - 用户故事应足够小,以适应冲刺; 大型故事很难估计和计划。T estable - 确保正在开发的内容可以得到充分验证和测试。用于编写用户故事的格式是什么?用户故事通常具有以下格式:作为<用户类型>,我想<feature>以便<benefit>。示例:作为 abc.com 的客户,我想要一个登录功能,以便我可以在线访问我的帐户详细信息。As a customer of abc.com, I want a login functionality so that I can access my account details online.如前所述,要特别注意产品的用户是谁,并避免“用户”的一般角色。如果你不知道谁是用户和客户,以及为什么他们会想要使用的产品,那么你应该没有写任何用户故事。叙述用户故事的第一部分是叙事。用2-3个句子来描述故事的意图。这只是意图的总结。对话用户故事最关键的方面是开发团队,客户,产品负责人和其他利益相关者之间应该不断进行的对话,以巩固用户故事的细节。验收标准验收标准代表满意的条件,这些条件被写为场景,通常采用Gherkin(Given,When,Then)格式。验收标准还提供故事的完成定义。谁应该写用户故事?在大多数情况下,用户故事由产品负责人或业务分析师编写,并在产品待办事项中进行优先级排序。但是,这并不是说只有产品负责人才能编写用户故事。实际上,任何团队成员都可以编写用户故事,但产品负责人有责任确保存在积压的用户故事并确定其优先级。重要的是,用户故事不应该被视为需求文档,在撰写时将被交给开发团队实施。用户故事应被视为鼓励产品负责人和开发团队之间进行对话的一种手段,因此应在产品待办事项修饰会话期间进行协作编写。让开发团队参与编写用户故事的一个优点是,如果存在任何技术限制,可以提前突出显示它们。测试人员可以特别增加构建有效验收标准的价值,并提前计划需要测试的内容和方法。用户故事的详细程度如何?用户故事关注客户价值。用户故事与其他形式的需求规范之间的基本区别在于详细程度。用户故事是正在进行的工作的隐喻,而不是对工作的完整描述。随着系统开发的进展,通过协作围绕用户故事进行充实的实际工作。如果描述变得过于冗长(超过索引卡上的描述),您应该重新访问用户故事。您可能想要包含太多细节。请记住,用户故事的目的是鼓励协作。它并不意味着记录工作的每个方面,因为传统的需求声明通常就是这种情况。此外,描述中的过多信息可能导致接受标准中缺少信息。在同意处理故事之前,团队必须了解验收标准。这些对于了解需要做什么以满足用户故事至关重要。接受标准应该足够详细,以定义用户故事何时满足,但不是那么详细,以至于无法进行协作。编写用户故事时常见的错误太正式或太多细节。 有良好意图的产品所有者经常尝试编写非常详细的用户故事。如果团队在迭代计划中看到一个看起来像IEEE需求文档的故事,他们通常会认为所有细节都在那里并且将跳过详细的对话。编写技术任务的用户故事。 敏捷的大部分功能来自于每次迭代结束时软件的工作增量。如果您的故事实际上只是技术任务,那么在每次迭代结束时,您通常不会使用工作软件,并且在优先级排序方面会失去灵活性。跳过对话。 在迭代计划之前,故事是故意模糊的。如果您跳过验收标准对话,则可能会向错误的方向移动,缺少边缘情况或忽略客户需求。敏捷软件开发什么是敏捷软件开发?什么是用户故事?什么是用户故事映射?用户故事与敏捷软件开发的使用案例

February 12, 2019 · 1 min · jiezi

介紹敏捷方法: Scrum, Kanban or Lean?

構建服務時可以使用許多敏捷方法,每種方法都有自己的一套工具和技術。本指南介紹了3種最流行的敏捷方法:Scrum看板Lean流行的敏捷方法解釋了ScrumScrum是最常用的敏捷方法。它允許高度結構化的模型具有明確定義的角色和職責。這對於正在轉向敏捷的傳統結構化組織尤其有用。在Scrum指南中了解有關Scrum功能的更多信息,由Scrum,Ken Schwaber和Jeff Sutherland的開發人員撰寫。看板 (Kanban)看板作為一種開發方法的靈感來自於生產系統,這些系統專注於減少浪費和提高質量,就像豐田創造的那樣。看板是一種可視化和改進當前工作實踐的方式,以便工作快速流經系統。快速,順暢的工作流程意味著您可以:快速,可預測地提供價值及早獲得反饋,了解您的產品或服務是否滿足用戶需求精益 (Lean)精益軟件開發,如看板,改編自豐田生產系統等精益生產原則。精益原則旨在幫助您的團隊專注於:減少浪費迅速交付學習和提高使用證據和數據做出決定使用多種敏捷方法您不必只使用一種方法,您可以從多種方法中選擇工具和技術來滿足您的團隊需求。每種方法都有自己的語言來描述基本的工具和技術,重要的是要理解:為什麼你選擇了一種工具或技術敏捷的目標找到您可以使用的其他敏捷方法。確定使用哪些方法Scrum如果您的團隊不熟悉敏捷工作,那麼Scrum是一個很好的起點。您的團隊通常會在以下情況下找到最有用的Scrum:建立新產品或服務增強現有功能在每個’sprint’中添加新功能(固定的時間段)當您運行實時服務並有緊急請求時,您可能會發現sprint約束並希望轉向基於流程的方法,如看板。但您仍然可以繼續使用與Scrum相關的許多活動,例如每日站立會議,回顧會議和定期審查進度。看板 (Kanban)看板幫助您的團隊:找到流程中的瓶頸控制你正在做的工作量根據實際交付預測您的輸出當您的團隊需要快速響應不斷變化的優先級時,它尤其有用。精益 (Lean)精益使您的團隊能夠盡快專注於學習。當您的團隊首次發現用戶的需求並決定如何滿足這些需求時,精益工具和技術尤其有用。更多推荐的Scrum文章如何使用Scrum Board进行敏捷开发?Scrum boards (also known as scrum task boards) are tools that help teams visualize backlogs of sprint work items. The board can use many manual (whiteboard and sticker) and virtual forms (software tools), but it can perform the same function regardless of appearance. (Scrum 板 (也称为 scrum 任务板) 是一种工具, 可帮助团队使冲刺积压工作项可见。该板可以采用许多手动 (即白板和贴纸) 和虚拟表单 (即软件工具), 但无论外观如何, 它都能执行相同的功能。)如何为Scrum项目撰写产品愿景?模板和示例The product vision is not part of the Scrum process. Why is it so important? Schwaber believes that vision is two necessary illusions, starting the Scrum project by stating: “The smallest plan starts the vision of the necessary Scrum project composition and product backlog” (产品愿景不是Scrum流程的一部分,为什么它如此重要?Schwaber的认为,愿景是两个必需的一个假象,开始Scrum项目,通过陈述道:“ 最小的计划开始了必要的Scrum项目组成的愿景和产品Backlog ”)Scrum: 什么是产品Backlog中的DEEP?Product Backlog projects have described attributes (D appropriate details), Story points (E stimated), order (P rioritized), and they are constantly added, deleted and updated (E merged) in the backlog to reflect the backlog of teams in a timely and appropriate manner. (产品Backlog项目具有描述的属性(D适当的详细说明),Story points(E stimated),order(P rioritized),并且它们在积压中不断被添加,删除和更新(E合并)以反映到对以及时和恰当的方式积压团队的积压。)如何为用户故事撰写SMART和INVEST目标?SMART is a set of standards for creating goals such as Sprint goals. While INVEST reminds you of the characteristics of high-quality product backlog (PBI) (or user stories) typically written in user story format. (SMART是一套创建目标(如Sprint目标)的标准。虽然invest会提醒您高质量产品积压工作(PBI)(或用户案例)的特征,通常以用户案例格式编写。)Sprint Increment (冲刺增量) vs Potential Shippable Product (潜在可发货产品) vs MVP vs MMPScrum requires the team to build an incremental function in each sprint, and the increment must be deliverable, because the product owner may decide to release it at the end of the sprint. This article explains and clarify the related key concepts of: sprint increment, potential shippable product MVP and MMP. (Scrum要求团队在每个sprint中构建一个增量的功能,并且增量必须是可以发送的,因为产品负责人可能决定在sprint结束时发布它。 This article explains and clarify the related key concepts of: sprint increment, potential shippable product mvp and mmp。)什么As / I want / so that 用户故事模板?The most common technology is the role-feature-reason template, which is used by teams and product owners to start writing user stories in three parts: (1) As a (role); (2) I want (feature); So that (reason). (最常见的技术是角色 - 特征 - 理由模板,用于团队和产品所有者开始编写用户故事,分为三个部分:(1)作为 As a(角色); (2)I What 我想要(特征); So that(理由)。)Scrum中的Burndown图表是什么?Burndown chart is a graphical representation of the remaining work and time. It is usually used in agile software development methods, such as Scrum. However, burning charts can be applied to any project that contains measurable progress over a period of time. (Burndown chart 是剩余工作与时间的图形表示。它通常用于敏捷软件开发方法,如Scrum。但是,刻录图表可以应用于任何包含一段时间内可衡量进展的项目。)Scrum中的Sprint目标是什么?Sprint goals show the expected results of iterations that provide shared goals for the team, which must be defined before the team starts Sprint in order to focus on achieving this goal. This ensures that everyone is on the same page. After choosing goals, the team must strive to implement them. (Sprint目标显示了为团队提供共享目标的迭代的期望结果,必须在团队启动Sprint之前定义该目标,以便专注于实现此目标。这可确保每个人都在同一页面中。选择目标后,团队必须努力实施目标。)如何使用MoSCoW方法确定产品积压的优先次序?MoSCoW (also known as MoSCoW prioritization or MoSCoW analysis) is a prioritization technology designed to reach a consensus with stakeholders on its importance for the delivery of each requirement. (MoSCoW方法(也称为MoSCoW优先级划分或MoSCoW分析)是一种优先级技术,旨在与利益相关方就其对每项要求的交付的重要性达成共识。)Sprint Backlog在Scrum中是什么意义?Sprint Backlog is a set of product backlog projects selected for the current Sprint and a plan to provide product increments for achieving Sprint goals. (Sprint Backlog是为当前Sprint选择的一组产品Backlog项目,以及为实现Sprint目标而提供产品增量的计划。) ...

February 11, 2019 · 3 min · jiezi

敏捷 - #9 原则:持续关注卓越的技术和良好的设计 ( #9 Agile - Principle)

“持续关注卓越的技术和良好的设计提高了灵活性。” “Continuous attention to technical excellence and good design enhances agility.”下一句话很有趣。许多人可能把敏捷软件项目团队想象成一群“牛仔”,他们只是聚在一起,敲出代码,而没有太多的设计计划,也没有任何编码标准。通常情况并非如此。敏捷认识到需要以正确的方式做事情,以避免以后不必要的返工。然而,敏捷的方法不应该导致产品过度设计或“镀金”。在敏捷环境中,你经常听到的一条评论是“仅仅是够好 (“just barely good enough.)”的概念。换句话说,这项工作应该在完整性和质量方面达到一个成功的水平,以充分实现它预期的目的,而不是更多。超过“勉强够好”的水平被认为是浪费。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

February 4, 2019 · 1 min · jiezi

敏捷 - #10 原则:简单是必不可少的 ( #10 Agile - Principle)

“简单——最大化未完成工作量的艺术至关重要。” “Simplicity—the art of maximizing the amountof work not done—is essential.”“简单——最大化未完成工作量的艺术至关重要。”这个原则强调简单。有多少次我们看到项目失去了控制,因为需求变得太复杂,很难实施,并且需求变得过度设计,试图满足你能想象到的每一个可能的需求?这也与“仅仅是够好 (just barely good enough)”的概念有关 —— 不要过度设计;尽可能简单。在某些情况下,从一些非常简单的东西开始,看看它是否满足需要,然后在以后仅在必要时扩展功能可能是有意义的。敏捷的另一个概念是“最小可行产品 (minimum viable product)”,它定义了产品在市场上必须可行的功能特性的最小集合。一般来说,采用增量方法从简单的东西开始,然后在必要时扩展它,而不是从可能对需求造成过度破坏的过于复杂的东西开始,会更有效。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

February 4, 2019 · 1 min · jiezi

敏捷 - #11 原则:自组织团队 ( #11 Agile - Principle)

“最佳架构、需求和设计来自自组织团队。” “The best architectures, requirements, anddesigns emerge from self-organizing teams.”敏捷很大程度上基于自组织团队的思想,但这需要一些解释。有时,开发人员使用“自组织”的概念作为无政府状态的借口,但这并不是他们想要的。其目的是,如果你在一个跨职能的团队中有合适的人,并且团队被授权以协作的方式集体使用团队中的所有技能,那么它通常会比一个单独的人能够提供更好的结果。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

February 4, 2019 · 1 min · jiezi

敏捷 - #12 原则:持续改进 ( #12 Agile - Principle)

“团队定期反思如何提高效率,然后相应地调整和调整其行为。” “At regular intervals, the team reflectson how to become more effective, then tunes and adjusts its behavior accordingly.”敏捷在两个方面具有适应性:设计适应不确定和不断变化的用户需求,它可以从需求的高级视图开始,并在项目启动后逐步细化需求。过程本身是适应性的,而不是高度规定性的。敏捷很大程度上建立在持续改进的基础上,利用短时间间隔来重新判断什么是有效的,什么是无效的,并在必要时采取快速的纠正措施。在Scrum中,这称为回顾,它发生在每个冲刺的末尾。随着项目的进展,团队将根据需要不断改进和调整敏捷过程。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

February 4, 2019 · 1 min · jiezi

敏捷 - #7 原则:工作软件是进度的主要衡量标准 ( #7 Agile - Principle)

“工作软件是进度的主要衡量标准。” “Working software is the primary measure of progress.”衡量软件开发项目的进展可能是困难和有问题的。传统的方法是将一个项目分解为任务,并跟踪这些任务的完成百分比,以此来衡量进度;但是,这可能会产生很大的误导,因为通常任务列表不完整,并且完成水平通常需要一些主观判断,这很难做出,而且往往不准确。测试是这方面的另一个因素,在过去,整个开发过程和测试过程可能是连续的。结果是,即使软件的开发看起来是完整的,但在测试和验证它是完整的之前,您不知道它到底有多完整。敏捷方法强调在开发软件时更同时地进行测试。敏捷中有一个概念叫做“完成的定义”,你会经常听到。团队应该清楚地定义“完成”的含义,这通常意味着软件已经过测试并被用户接受。在其他环境中,done的定义可能会更加模糊,并受到解释的影响。如果您没有明确定义“完成”,则任何对完成百分比的估计都可能是可疑的。更准确的进度度量方法是将一个软件项目分解为多个功能块,其中每个软件块都有一个明确的“完成”定义,并且可以向用户演示以获得反馈和接受。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

February 4, 2019 · 1 min · jiezi

敏捷 - #3 原则:经常提供工作软件 ( #3 Agile - Principle)

“经常交付工作软件,从几周到几个月,优先选择较短的时间范围。”下一个原则强调使用迭代方法将项目分解为非常小的增量,称为冲刺或迭代,通常在两到四周的范围内。这很有道理的原因有两个:所有敏捷开发过程(如scrum)都基于持续改进。我们希望团队采用一种经验的方法 (empirical approach) 来了解随着项目的进展,哪些是可行的,哪些是不可行的,并在必要时进行调整,而不是采用一个永不改变的严格定义的过程 (defined process)。如果将项目分解为很短的增量 (increments),并且在每个增量结束时进行学习,那么学习和持续改进可以更快地发生。一个流行的敏捷口头禅是:“及早失败,经常失败”。 “Fail early, fail often.”换句话说,在许多情况下,最好快速尝试一些东西,从中学习并做出调整,而不是花费所有可能需要的时间来尝试设计一种第一次毫无效果的方法。人们工作效率更高,只需在短时间内完成任务。如果做得正确,团队会发展出一种节奏和节奏,这种节奏和节奏对于快速而有效地产生确定的工作量增量非常有效,就像制造装配线一样。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

February 4, 2019 · 1 min · jiezi

敏捷 - #4 原则:業務人員和開發人員必須攜手合作 ( #4 Agile - Principle)

“在整個專案過程中, 業務人員和開發人員必須每天一起工作。” Business People and Developers MustWork Together下一個原則強調專案團隊和業務贊助者之間的夥伴關係。這與敏捷宣言中 “合作而不是合同 (collaboration over contracts)” 的價值非常一致。為了落實這一原則, 業務贊助者 (business sponsors) 和專案團隊都需要對專案的順利完成承擔共同責任。這就需要業務贊助者的參與程度遠遠高於許多傳統專案中的常見水準, 在這些專案中, 專案的實施幾乎可能完全委託給專案團隊。當然, 參與的程度應適合專案的性質, 企業主辦人的參與方式可能因情況而異。例如, scrum 有一個名為 “產品擁有者 (Product Owner)” 的角色 (Role), 它為專案提供日常業務方向, 但方向可能並不局限于此。在一個大型的企業級專案中, 可能還有其他一些利益攸關方者 (other stakeholders) 需要提供投入, 需要以某種方式參與。設計一種讓合適的人在合適的時間參與進來的方法, 對於專案的成功非常重要。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

February 4, 2019 · 1 min · jiezi

敏捷 - #5 原则:围绕积极性高的个人去构建项目 ( #5 Agile - Principle)

“围绕有动机的个人构建项目。为他们提供所需的环境和支持,并相信他们能够完成工作。” “Build projects around motivated individuals. Give them the environment and support they> need, and trust them to get the job done.”下一个原则强调了在项目中适当激励个人的重要性。在过去,有些项目经理经常使用高压、指挥和控制策略来迫使项目团队更快地交付结果。在我们的职业生涯中,很多人都参与过“死亡行军 (Deatch March)”项目,在这个项目中,人们被赋予完成某件事情的绝对期限,如果有必要的话,他们必须在晚上和周末工作。当你处在一个需要高度创造力和创新的环境中时,这种方法就不能很好地工作。敏捷的哲学是建立在项目人员的高度授权和个人主动性的基础上的。敏捷团队没有被明确地告知该做什么,也没有被强制去做以满足最后期限的要求,而是被赋予了一般的指导,并期望自己能够确定如何最有效和高效地完成它。使这种方法发挥作用需要一种以人为本的领导风格。然而,这并不意味着不需要任何领导。一个敏捷的项目经理需要调整他或她的领导风格来适应这种情况,这通常取决于几个因素,包括项目的性质、团队的成熟度和经验水平。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

February 4, 2019 · 1 min · jiezi

敏捷 - #6 原则:面对面交谈 ( #6 Agile - Principle)

“向项目团队传递信息的最有效方法是面对面交谈。” “The most efficient and effective method of conveying information to and within a project team is face-to-face conversation.”这原则强调面对面的交谈。这是另一种说法,你不能把它当作绝对的,而是把它当作相对的。分布式团队 (distributed team) 并不总是能够进行面对面的交流,但如果可能的话,这当然是可取的。这一声明也不意味着唯一的交流形式是直接的面对面的交流。它是对瀑布式项目历史的一种反应,瀑布式项目严重依赖文档化的需求作为一种沟通方式。有许多方法可以以各种形式交流信息,您需要选择最佳组合来确定给定的情况。正确的组合将取决于许多因素,包括项目的范围和复杂性以及项目团队的分布。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

February 4, 2019 · 1 min · jiezi

敏捷 - #8 原则:促进可持续发展 ( #8 Agile - Principle)

“敏捷过程促进可持续发展。赞助商、开发人员和用户应该能够独立地保持恒定的速度。” Promote Sustainable Development敏捷的许多基础来自精益制造和全面质量管理(TQM)。许多年前,在一个制造环境中,公司了解到,像血汗工厂这样的制造工厂,强迫工人在恶劣条件下加班,通常不会产生高质量的产品。在敏捷环境中,同样的事情尤其如此,因为工作的成功如此关键地依赖于团队的创造力和动力。在这种情况下,更重要的是要创造一个长期可持续工作的环境。更多推薦的scrum 文章Scrum的基本功- 集合中英文版本(Scrum事件)Scrum的基本功- 集合中英文版本(Scrum工件)Scrum的基本功- 集合中英文版本(角色和責任篇)Scrum的基本功- 集合中英文版本(基礎篇)

February 4, 2019 · 1 min · jiezi

敏捷 - #2 原则:欢迎更改要求 (Agile - #2 Principle)

“欢迎不断变化的需求,即使是在开发后期。敏捷流程利用变化来获得客户的竞争优势。” “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”下一个原则强调创造一个期望和欢迎变化的环境,而不是严格控制和限制;当然,这并不意味着项目是完全不受控制的。基于与客户的合作关系,有很多方法可以有效地和协作地管理变更。重要的是,项目团队和客户应该事先就如何管理变更达成共识。更多推荐的 scrum 文章Scrum的基本功 - 集合中英文版本 (Scrum事件)Scrum的基本功 - 集合中英文版本 (Scrum工件)Scrum的基本功 - 集合中英文版本 (角色和责任篇)Scrum的基本功 - 集合中英文版本 (基础篇)

February 1, 2019 · 1 min · jiezi

敏捷宣言和背后的原则 (Agile Manifesto and the principles behind)

这四个价值陈述构成了敏捷宣言的基础。敏捷宣言中的原则扩展了价值, 并提供了更多细节。同样, 与值语句一样, 这些语句也应被视为相对偏好, 而不是绝对偏好。这些原则概述如下, 并在以下各节中进行更详细的讨论:我们的首要任务是通过早期和持续交付有价值的软件来满足客户。欢迎不断变化的要求, 即使是在开发后期。敏捷流程利用变化来获得客户的竞争优势。经常交付工作软件, 从几周到几个月不等, 优先考虑较短的时间刻度。在整个项目过程中, 业务人员和开发人员必须每天一起工作。围绕有积极性的个人建立项目。给他们所需的环境和支持, 相信他们能完成任务。向项目小组和在项目小组内传达信息的最有效率和效力的方法是面对面的对话。工作软件是衡量进展的主要标准。敏捷进程促进可持续发展。赞助商、开发者和用户应该能够无限期地保持不变的步伐。持续关注卓越的技术和良好的设计可提高敏捷性。简单性–最大限度地增加未完成的工作量的艺术–是必不可少的。最好的架构、要求和设计来自自组织团队。团队定期反思如何变得更加有效, 然后相应地调整和调整其行为。更多推荐的 scrum 文章Scrum的基本功 - 集合中英文版本 (Scrum事件)Scrum的基本功 - 集合中英文版本 (Scrum工件)Scrum的基本功 - 集合中英文版本 (角色和责任篇)Scrum的基本功 - 集合中英文版本 (基础篇)

February 1, 2019 · 1 min · jiezi

敏捷 - #1 原则:早期和持续交付有价值的软件 (#1 Agile Principle)

早期和持续交付有价值的软件“我们的首要任务是通过及早持续交付有价值的软件来满足客户的需求。”“Our highest priority is to satisfy the customer through early and> continuous delivery of valuable software.”第一个原则强调“及早和持续地交付有价值的软件”。在敏捷之前的许多传统计划驱动的项目中,最终用户客户直到项目的最终用户验收测试阶段才看到任何东西,到那时,进行任何可能需要的更改都是非常困难和昂贵的。强调软件的早期交付可以实现两个主要目标:1。它为客户提供了一个在开发周期早期看到软件的机会,并提供反馈和输入,以便能够快速、轻松地进行更正。2。工作软件是一个很好的进度度量。从实际完成、测试和交付到用户满意程度的增量软件功能方面衡量进展要准确和有效得多,而不是试图衡量未完成的大型开发项目的完成百分比。在不将大型软件开发项目分解为多个部分的情况下,准确地测量整个软件开发项目的进度是非常困难的。这可能是一个非常主观的判断和一些猜测。将工作分解为明确定义的“完成”标准的明确定义的部分,提供了一种更真实和客观的方法来衡量进展。更多推荐的 scrum 文章Scrum的基本功 - 集合中英文版本 (Scrum事件)Scrum的基本功 - 集合中英文版本 (Scrum工件)Scrum的基本功 - 集合中英文版本 (角色和责任篇)Scrum的基本功 - 集合中英文版本 (基础篇)

February 1, 2019 · 1 min · jiezi

用户故事指南

用户故事的目标不仅是记录需求,还要提供客户在生产中使用的工作软件。用户故事提供了一种机制,用于记录客户和开发人员之间关于软件功能的讨论。定义“用户故事代表卡中的客户要求,导致对话和确认。” 〜罗恩杰弗里斯模板以下是用于定义用户故事和验收标准的众所周知的模板。价值陈述:作为(用户角色),我想(活动),以便(业务价值)接受标准:给定(上下文),何时(执行行动),然后(可观察的后果)一般准则以下是编写用户故事时要考虑的一些通用准则:用户故事有三个方面:卡片,对话和确认(Ron Jeffries 2001)用户故事应表示对用户或系统所有者有价值的功能。用户故事应描述单个功能。用户故事应该有一个注释部分,其中记录了有关用户故事详细信息的对话。用户故事应该在故事点中具有估计(成本),其表示大小和复杂性。用户故事应根据其对客户的价值进行优先排序。良好用户故事的属性(INVEST)Mike Cohn在他的“用户故事应用”一书中指出了一个好的用户故事的六个基本属性。这些是:独立的(I)用户故事应该不依赖于其他用户故事。用户故事应该是自包含的。用户故事应按任何顺序完成和发布。当发生依赖关系时,应该以不同的方式组合或拆分用户故事。可面议(N)用户故事不应该是合同义务,因为它们是可以协商的。用户故事应该是客户,开发人员和测试人员之间的协作谈判。有价值的(V)用户故事应该对软件的用户或所有者有价值。用户故事不仅仅对开发人员有价值。用户故事应明确定义客户/用户的利益,以帮助确定优先级。用户故事应由客户编写,以确保其对客户/用户有价值。可估计(E)用户故事应根据故事点进行估算。在开发团队估计用户故事之前,应该清楚地理解用户故事。在开发团队估算之前,用户故事应包含足够的详细信息。当开发团队缺乏领域知识时,用户故事可能无法估计。当开发团队缺乏技术知识时,用户故事可能无法估计。当用户故事太大时,用户故事可能无法估计。小的(S)用户故事应该尽可能小,同时仍然提供用户价值。用户故事应该能够适合一次迭代。对于大的用户故事将难以理解和估计。可测试的(T)应通过测试验证用户故事,以证明它们已正确实施。用户故事应包含指导测试的故事接受标准。用户故事应该很容易进行单元测试。(技术实施)用户故事应该很容易接受测试。(行为的)用户故事应尽可能以自动方式进行测试。故事点规划改进的Fibonacci(0,1 / 2,1,2,3,5,8,13,20,40,100)T恤(xxs,xs,s,m,l,xl,xxl,)完成(DoD)的定义团队可以使用许多标准来定义他们的“完成定义”。这可确保团队提供在功能和质量方面完成的功能。Done的定义是可审核的核对表。以下是国防部的一系列可能标准和活动:单位测试通过接受标准达成代码已审核通过功能测试非功能性要求产品负责人接受用户故事用户故事示例以下是用户故事的示例。参考科恩,迈克。用户故事应用:敏捷软件开发。第1版,Addison-Wesley Professional,2004年。Wake,William C. Extreme Programming Explored。Addison Wesley,2002。

January 29, 2019 · 1 min · jiezi

完成的定义 Definition of Done

每个Sprint的输出的正式名字为“潜在可交付产品增量”。在开始第一个Sprint之前,产品负责人、团队和Scrum Master必须审视对于把一个产品待事项列表中的事项做到潜在可交付所需要的所有事情。所有为了交付产品所需的活动都应被包含在“潜在可交付”的定义中,并且要在这个Sprint中完成。遗憾的是,当团队开始使用Scrum时他们通常做不到在每个Sprint都能交付出“潜在可交付增量”这个目标。这通常是因为团队缺少自动化或者不够跨职能(例如,技术文档撰写者还没有被包含在跨职能团队中)。随着时间的过去,团队必须要提高从而能够在每个Sprint交付“潜在可交付产品增量”。但是为了开始,他们需要建立一个他们当前能力的基线。这会被记录在“完成的定义”中。在第一个Sprint开始前,产品负责人和团队要对于“完成的定义”达成共识,“完成的定义”是创建“潜在可交付产品增量”所需要的活动的子集(对于一个好的团队来讲两者是一样的)。团队会根据“完成的定义”来计划他们在Sprint中的工作。一个好的产品负责人总是会希望“完成的定义”与“潜在可交付”越接近越好,因为这样会增加开发中的透明度并降低延迟和风险。如果“完成的定义”不等同于“潜在可交付”,那么就会有工作被延迟到发布之前,这会导致风险和延迟。因此被延迟的工作有时被称为未完成的工作。Scrum团队应当持续地改进,这一点会表现在对“完成的定义”的扩展上。

January 29, 2019 · 1 min · jiezi

每⽇Scrum会议

概述:在团队成员间更新信息和进行协调。参与者:团队必须参加;产品负责人不是必须的;ScrumMaster通常会在场,但要保证团队自己主持会议。时长:最长15分钟。一旦Sprint开始,团队就要投身于另一个Scrum实践,那就是每日Scrum会议。在每个工作日指定时间都会举行这个很短的(15分钟,或者更短)会议。团队中的每个人都要参加。为了让它保持简洁,建议每个人都保持站立姿势。这是团队同步他们的工作并互相报告遇到的阻碍的机会。在每日Scrum会议中,每个团队成员一个接一个地向团队的其他成员报告三件事:(1)你昨天做了什么?(2)你今天要做什么??(3)遇到了什么阻碍?注意每日Scrum会议并不是向管理者报告状态的会议。这是一个自组织团队互相分享目前工作情况的时刻,从而帮助他们进行工作协调。有人要把这些阻碍记录下来,Scrum Master负责帮助团队成员解决它们。在每日Scrum会议中只有很少或不会有深入的讨论,其形式只是做回答那三个问题的报告。如果的确需要讨论,那么在每日Scrum会议后马上就会有一个或多个并行的跟进会议,但在Scrum中没要求任何人必须参加这些会议。部分或者全部的团队成员需要针对于他们在每日例会中所收到的信息进行调整时开跟进会议很常见,换言之,这是又一个审视并调整的周期。对于新接触Scrum的团队,通常情况下建议管理者或者其他会被认为有权威的人不要参加每日例会。这样做的风险是会让团队感到“被监视”。它使得团队在压力之下每天都报告出重大进展(这是不切实际的期望),并使团队不愿报告问题。并且它会破坏团队的自管理,引入微观管理。对于一个利益相关人,更有益的做法是在会议后再找到团队,并帮助解决那些让团队进展慢下来的阻碍。

January 29, 2019 · 1 min · jiezi

产品待办事项列表梳理 Product Backlog Grooming

概述:为了将来的Sprint拆分大事项、分析事项、重新估计并重排优先级。参与者:团队;如果产品负责人是能够帮助梳理细节的专家,那么他会全程参与整个活动,否则他可以只参与其中一部分来设定方向或者重排优先级;其他理解需求并能给予团队帮助的人;ScrumMaster将在会议的开始部分来指导团队如何有效地开这个会,否则的话他不必参加。时长:通常来讲不多于团队一个Sprint工作容量的10%,但有时对于“有大量分析工作”的事项来讲要更长一些。例如,对于两周的Sprint,可能要有一天的时间花在梳理上。Scrum中一个很少有人知道,但很有价值的指导原则是,每个Sprint中整个团队要把一定百分比的时间专门用于梳理产品待办事项列表上,做为对将来Sprint的支持。这包含了详细的需求分析、把大的事项拆小、估计新的事项以及重新估计已有事项。Scrum中没有说这个工作该如何来完成,但是一个经常用到的方法是在接近Sprint中部或者结尾时开一个专注的研讨会,这样团队和产品负责人以及其他利益相关人就可以不受打断地专门做这些事情。这种梳理活动并不是为了当前Sprint已经选择的那些事项。它是为了将来的事项,最可能是为了下一两个Sprint。有了这个实践方法,Sprint计划会议变得相对简单些,因为产品负责人和Scrum团队将从一组清晰的,被很好分析过并认真估计过的事项入手。没有开过这种梳理工作研讨会(或者没做好)的特征是Sprint计划会议中出现重大的疑问或者发现,或者令人困惑并感觉不完整。这样一来计划工作通常要延续到Sprint中去,这显然不是大家想要的。

January 29, 2019 · 1 min · jiezi

Sprint评审会议 (Sprint Review)

概述:对于功能性的产品增量进行审视并调整。参与者:团队、产品负责人、ScrumMaster。产品负责人可以邀请其他恰当的利益相关人参加。时长:时间箱为Sprint中的每一周对应一个小时。在Sprint结束后,就到了Sprint评审会议 (Sprint Review Meeting),人们会评审这个Sprint。出席会议的人有产品负责人、团队成员以及ScrumMaster,再加上客户、利益相关人、专家、领导层和任何有兴趣的人。对于两周的Sprint来讲最长为两个小时。任何参与者都可以问问题和提意见。评审会议常常会被错误地打上“演示”的标签,但这并没有抓住这个会议真正的用意。Scrum中的一个关键思想是审视并调整。观察并了解发生的情况,然后根据反馈进行演进,不断进行。Sprint评审会议是对于产品的审视并调整活动。它让产品负责人了解产品和团队的当前状况(也就是对于这个Sprint的评审),也让团队了解产品负责人和市场的当前状况。因此,评审会议中的一个关键元素是团队与产品负责人之间进行深入的对话来了解情况和得到建议等等。评审会议当然要包含使用团队所创造的真的,运行起来的软件,但如果评审的关注点只是在看产品而没有进行交谈,这么做就失衡了。Sprint评审会议中“运行起来的软件”这部分并不是由团队来做“报告”,不会用到幻灯片。它是指亲手来检验正在运行的真正的软件,例如在一个用于开发的沙盒环境中。在评审会议议室里会有一台或多台电脑,人们可以在上面检验和使用运行起来的软件。最好有一个积极交互的过程,由真实用户和产品负责人动手与软件交互,而不是由团队做出一个被动的展示过程。尽量做到在不超过30分钟的时间之内做完Sprint评审会议的准备,否则就意味着有什么地方做得不对。

January 29, 2019 · 1 min · jiezi

Sprint回顾会议

概述:针对流程和环境进行审视并调整。参与者:团队、ScrumMaster、产品负责人(非必须)。团队可能会邀请其他利益相关人,否则这些人不准参加。时长:时间箱为对应Sprint中的每一周为45分钟。Sprint评审会议包含了对于产品的审视并调整。而在评审会议之后的“Sprint回顾会议”则包含了针对流程和环境的审视并调整。这是团队讨论什么方式能工作,什么方式不工作的机会,并对要尝试的改变达成一致意见。有时Scrum Master可以扮演回顾会议的效率协调者,但可能还是找一个中立的外人来协调这个会议更好。一个好的做法是,Scrum Master们互相帮助协调彼此的回顾会议,这会起到在团队间“交叉受粉”的效果。组织Sprint回顾会议有很多技巧,《敏捷回顾》(《Agile Retrospectives》)一书中提供了很有帮助的一系列技巧。很多团队的回顾会议只关注于问题,这很不好。这使得人们以为回顾会议是某种让人情绪低落的或者负面的事件。正相反,要保证每次回顾会议也关注于正面的事物或者优势。有几本关于“欣赏式探询”的书在这方面给出了更多的点子。回顾会议如果总是用同样的分析技巧可能就会变得无聊起来,这样的话就要随着时间的推移引入不同的技巧。

January 29, 2019 · 1 min · jiezi

Scrum: 常⻅的挑战

Scrum不仅仅是一套具体的实践,确切地说更为重要的是这个框架提供了透明度并给出了“审视并调整”的机制。Scrum通过让影响产品负责人 (Product Owner) 和团队 (Development Team) 效率的机能失调和障碍变得显而易见,使它们得到及时处理。比如,产品负责人可能不清楚市场情况、特性或如何估算它们的相对商业价值。亦或者团队可能对于工作量估算或开发工作还不够熟练等。Scrum框架会迅速揭露这些弱点。Scrum并不能解决开发的问题,只是让问题都赤裸裸地显现出来,并为人们尝试用短周期和小改进试验来解决问题提供了框架。假设团队因为任务分析和估算技能不佳,而不能交付他们预期在首个Sprint完成的工作。对于团队而言,这是次失败。但是实际上,这是个必需经历的第一步,以使得团队对于以后的预期更加实际和周到。Scrum的这种模式使得机能失调显现出来,让团队能够及时处。正是这种基本的机制带给了使用Scrum的团队所能经历到的最大好处。一个常见的错误做法是当使用某个Scrum实践遇到挑战时改变Scrum。比如,团队交付有困难,他们可能决定延长Sprint,那么时间永远都是充裕的,并且在这过程中确保自己永远都不用学习如何更好地估算和管理时间。这样,没有经验丰富的Scrum Master的教练和支持,这个组织的Scrum就会蜕变成只是其自身弱点和功能不调的镜像,并且破坏了Scrum所能带来的真正利益:也就是使得好坏都显露无遗,给组织提供自我提升的机会。另一个常见的错误做法就是假定某个实践是不准许或禁止的,只是因为Scrum没有明确地提到。比如,Scrum没要求产品负责人为产品制定长期策略,也没要求工程师对于复杂的技术问题向经验丰富的前辈讨教。Scrum将这些都留给相关的个人来做正确的决定,在多数情况下,以上两个实践(和其他一些)都是特别推荐的。还有一个需要注意的是管理者强制团队使用Scrum。Scrum提供给团队空间和工具来自我管理,这种从管理层强压下来的命令并不是取得成功的方法。一个比较好的做法就是让团队先从同事或管理者处了解到Scrum,进行全面的专业培训,然后由团队决定在一定的时期内忠实遵循Scrum实践,在该时期结束时团队将评价其工作经历,再决定是否继续使用Scrum。虽然首个Sprint通常对于团队来说是极富挑战性的,但值得庆幸的是在Sprint结尾时Scrum带来的好处就会显现出来。所以很多新的Scrum团队都惊叫:“Scrum太难了,但是比起我们以前的做法它简直是太好了!”

January 29, 2019 · 1 min · jiezi

Scrum:产品负责人责任

Scrum Projects的主要利益相关者是产品负责人产品负责人的一个不可或缺的责任是向Scrum团队传达Scrum项目的重要性和重要性。这是通过使用Product Backlog成功实现任何敏捷项目的关键。现在让我们看一下产品负责人的一些主要职责 :产品Backlog的创建和维护:Scrum Process主要用于软件环境和新产品开发领域。这是产品负责人正在进行的工作和全职工作。在任何sprint计划会议之前,他必须不断地进行梳理。根据业务ROI确定Backlog的优先级:产品负责人还需要根据业务和情况的需要对待办事项进行优先级排序。他还将用户故事中的史诗,主题和特征详细阐述,这些故事足以在单个冲刺中实现。产品负责人负责不断提醒Sprint&Release团队,并确保团队在实现目标的过程中保持正轨。产品负责人负责与客户和利益相关方不断保持沟通,以确保团队正在构建正确的产品并提供预期的业务价值。同样在每个Sprint结束时,产品负责人都有机会引导团队朝着为利益相关者创造价值的方向发展。产品负责人还会在每个Sprint结束时不断检查Scrum团队所做的工作,并拥有接受或拒绝其工作或建议修改的绝对权限。产品负责人还充当团队对外界的代言人,并应确保所有沟通渠道保持开放,项目获得成功所需的正确的支持。如果产品负责人认为所需的方向发生了巨大变化并且不再需要花费,则有权终止Sprint。如果竞争对手发布新产品并且客户想要反击,则可能发生这种情况产品负责人的职责是繁重的,有很多必须由他穿着因此一个产品负责人的选择必须明智地做,因为它可能会导致成功或失败对整个项目可能最终意味着项目成功或失败。Scrum角色什么是Scrum团队?什么是Scrum的自组织团队?Scrum团队如何运作? - 简要指南如何成为Scrum项目的优秀产品负责人?什么是产品负责人在Scrum中的角色?敏捷开发:如何成为合格的Scrum Master?什么是Scrum中的猪和鸡?项目经理与Scrum Master对项目所有者什么是三个Scrum角色?什么是Scrum Master?角色和责任什么是敏捷中的跨职能团队?作为Scrum Master,您如何帮助您的项目所有者?

January 24, 2019 · 1 min · jiezi

Agile: 为什么要使用 scrum 而不是瀑布?

Scrum方法需要改变传统方法的思维方式。中心焦点已经从瀑布方法的范围转变为在Scrum中实现最大的商业价值。在瀑布中,改变成本和进度以确保达到预期的范围,在Scrum中,可以改变质量和约束以实现获得最大商业价值的主要目标。瀑布模型适用于有序和可预测的项目,其中所有要求都明确定义并且可以准确估计,并且在大多数行业中,此类项目正在减少。客户需求的变化导致企业适应和改变其交付方式的压力增大。Scrum方法在当前市场中更为成功,其特点是不可预测性和波动性。Scrum方法基于inspect-adapt循环,而不是Waterfall方法的命令和控制结构。Scrum项目以迭代方式完成,其中首先完成具有最高业务价值的功能。各个跨职能团队在Sprint中并行工作,以便在每个Sprint结束时提供潜在的可交付解决方案。因为每次迭代都会产生可交付的解决方案(这是整个产品的一部分),所以团队必须实现可衡量的目标。这可确保团队正在进行,项目将按时完成。传统方法没有提供这种及时的检查,因此导致团队可能会下班并最终完成大量工作。当客户定期与团队互动时,定期审查完成的工作; 因此,可以确保进度符合客户的要求。然而,在瀑布中没有这样的交互,因为工作是在筒仓中进行的,并且在项目结束之前没有可用的功能。在复杂的项目中,客户不清楚他们在最终产品中需要什么,并且功能需求不断变化,迭代模型可以更灵活地确保在项目完成之前可以包含这些更改。但是,当完成具有明确定义的功能的简单项目,并且当团队具有完成此类项目的先前经验(因此,估计将是准确的)时,瀑布方法可以是成功的。敏捷 Vs. 瀑布下面是一个表格,可以更好地了解Scrum和瀑布的差异。下面是一个表格,可以更好地了解Scrum和瀑布的差异。敏捷还是瀑布?见图Standish Group的最新报告涵盖了他们在2013年至2017年期间研究的项目。在这段时间内,敏捷和瀑布的成功,挑战和失败的整体突破如下所示,敏捷项目成功的可能性大约是后者的2倍,失败的可能性降低1/3。(来源:vitalitychicago.com - 比较瀑布和敏捷项目成功率)敏捷与瀑布 - 项目成功率更多推荐的 scrum 文章Scrum的基本功 - 集合中英文版本 (Scrum事件)Scrum的基本功 - 集合中英文版本 (Scrum工件)Scrum的基本功 - 集合中英文版本 (角色和责任篇)Scrum的基本功 - 集合中英文版本 (基础篇)

January 24, 2019 · 1 min · jiezi

伟大的Scrum团队的特征

在Scrum项目中,Scrum团队成员负责提供所需的产品或服务,而不是Scrum。因此,我们应该小心组建Scrum团队。Scrum团队有时被称为开发团队,因为他们负责开发产品,服务或其他结果。它由Sprint Backlog中的用户故事组成的一组人员为项目创建可交付成果。Scrum团队提供所需项目结果的基本特征如下所述:自组织 (self-organized): Scrum团队成员是有动力的人,他们不等待上级分配任务。他们承担责任,分担风险,做出决定,共同努力实现共同目标。授权:(Empowered) Scrum团队或开发团队获得所需的资源,以提供所需的产品或服务以及作出决策的权限。如果团队只有责任但没有权力做出决策,那么连续/迭代开发就很困难。协作 (Collaboration):项目管理是一个共享的价值创造过程,团队一起工作和互动,以提供最大的价值。Scrum团队应该分享知识,想法,风险和责任,并与团队成员协调工作,以提供理想的结果。共同目标 (Shared Goal): 团队中的个人应共同努力实现共同目标。团队目标应该叠加他们的个人目标,如成长,评估和金钱。最佳规模 (Optimum Size): 一个小型Scrum团队可能没有开发产品或服务所需的技能,而大型Scrum团队可能会破坏工作,因为团队内部的协作将很困难。根据SBOK的定义,Scrum团队的最佳规模应为6到10。这将确保Scrum团队足够大,能够拥有交付项目所需的技能,并且足够小,可以进行协作。多样化的技能 (Cross-functional): Scrum团队应该集体拥有提供项目可交付成果所需的技能。在Scrum团队组建期间,应该选择团队成员,牢记交付项目可交付成果所需的技能。并置 (Collocated): 建议组建一个Scrum团队,成员并置。这确保了团队成员之间的协作和协调可視化 (Visualized):工作任務的可視化。讓團隊成員瞭解工作任務項以及當前進度。

January 24, 2019 · 1 min · jiezi

Scrum团队的角色和职责

本教程适用于敏捷软件开发新手的Scrum团队成员,以了解他们的角色和职责。本教程还将帮助那些已经在敏捷模型中工作的人提高他们的技能,并帮助那些只想了解这些角色的人。它还将提供对责任及其所隐藏的每个角色的洞察力。Scrum团队的角色和责任Scrum团队主要由三个角色组成:Scrum Master,产品负责人和开发团队。核心团队以外的任何人都不会对团队产生任何直接影响。Scrum中的每个角色都有一套非常明确的职责,我们将在本教程后面详细讨论。在本节中,让我们关注Scrum团队的整体属性和理想的团队规模。Scrum团队属性以下是Scrum团队的2个属性:Scrum团队是自组织的Scrum团队是跨职能的自组织Scrum团队在完成工作方面是自力更生和自给自足的,无需外部帮助或指导。这些团队有足够的能力采用最佳实践来实现他们的Sprint目标。跨职能Scrum团队是团队中具备完成工作所需的所有技能和熟练程度的团队。这些团队不依赖团队外的任何人来完成工作项目。因此,Scrum团队是完成整个工作项所需的不同技能的非常有创意的融合。每个团队成员可能不一定具备构建产品所需的所有技能,但能够胜任他/她的专业领域。话虽如此,团队成员不需要交叉功能,但整个团队必须是。具有高自组织和跨职能的团队将带来高生产力和创造力。Scrum团队规模Scrum中推荐的开发团队规模为6 +/- 3,即3到9个成员,不包括Scrum Master和产品负责人。现在,让我们继续前进,详细讨论这些角色。Scrum MasterScrum Master负责促进/指导开发团队和产品负责人从事日常开发活动。他是确保团队理解Scrum价值观和原则并能够实践它们的人。与此同时,Scrum Master还确保团队对Agile充满热情,以便在框架内实现最佳效果。Scrum Master还帮助并支持团队自我组织。除了对团队成员进行有关敏捷重要性的培训和培训外,他还有责任确保团队始终保持积极性和强化。他还致力于加强团队成员之间的沟通和协作。Scrum Master是一名流程负责人,他帮助Scrum团队和Scrum团队以外的其他团队了解Scrum值,原则和实践角色和责任#1)教练 - Scrum Master为开发团队和产品负责人充当敏捷教练。Scrum Master在某种程度上可以作为开发团队和产品负责人之间正确沟通的推动者。Scrum Master负责消除其他角色之间的障碍。如果注意到产品负责人没有参与或没有给开发团队提供适当的时间,那么Scrum Master的工作就是指导产品负责人了解他参与整个团队成功的重要性。#2)辅导员 - Scrum Master也是Scrum团队的推动者。他促进和组织Scrum团队成员要求的所有Scrum活动。Scrum Master还帮助团队做出重要决策,从而提高Scrum团队的整体生产力。Scrum Master从不命令团队成员做某事,而是通过指导和指导帮助他们实现目标。#3)消除障碍 - Scrum Master还负责消除影响团队交付业务生产力的障碍。团队成员无法自行解决的任何障碍都会导致Scrum Master解决。Scrum Master根据对团队生产力和业务的影响对这些障碍进行优先排序,并开始研究这些障碍。#4)干扰关守 - Scrum Master还保护Scrum团队免受外界干扰和分心,以便团队可以在每次冲刺后继续专注于为业务提供最佳价值。如果团队在Scaled Scrum环境中工作,其中多个Scrum团队正在协同工作并且在他们之间具有依赖关系,那么干扰可能会引起更大的关注。Scrum Master确保团队不参与任何不相关的讨论,并专注于Sprint项目,而他自己则负责解决来自外部的查询和疑虑。Scrum Master负责保护团队免受外部干扰并消除障碍,以便让团队专注于提供业务价值。#5)仆人领袖 - Scrum Master通常被称为Scrum团队的仆人领袖。他最重要的职责之一就是向Scrum团队询问他们的顾虑并确保他们得到解决。Scrum Master的职责是确认团队的基本要求是优先考虑并得到满足,以使他们有效地工作并产生高绩效的结果。#6)流程改进者 - Scrum Master和团队还负责定期即兴创建所采用的流程和实践,以最大限度地提高交付价值。Scrum Master不负责完成工作,但是他有责任让团队设计一个让他们完成冲刺目标的流程。产品负责人我们将在本教程中讨论的另一个非常重要的角色是产品负责人。产品负责人是客户/利益相关者的代言人,因此负责缩小开发团队与利益相关者之间的差距。产品所有者以最大化正在构建的产品价值的方式管理差距。产品负责人将参与Sprint活动和开发工作,并在产品的成功中发挥至关重要的作用。角色和责任#1)弥合差距 - 产品负责人与内部和外部利益相关方密切合作,收集输入并综合愿景,将产品功能放入产品Backlog中。产品负责人有责任了解利益相关方/客户群体的要求和偏好,因为他是代理人并肩负着构建正确解决方案的责任。同时,产品负责人确保开发团队了解需要构建的内容以及何时构建。他每天都与团队合作。产品负责人与团队的互动增加了反馈频率和响应时间,从而提高了正在构建的产品的价值。产品所有者的缺席/减少协作可能导致灾难性的结果并最终导致Scrum失败。产品负责人确保产品待办事项项目透明且清晰表达,团队中的每个人对项目都有相同的理解。管理产品待办事项 - 作为上述结果,产品负责人负责创建和管理产品Backlog,订购产品Backlog中的项目以最好地实现利益相关方的要求,即产品Backlog项目的优先级,最后他应该随时可以回答或澄清所有开发团队的问题。总的来说,他负责培训产品Backlog以提高交付价值。任何想要在产品Backlog中添加/删除项目或需要更改项目优先级的人都应该定向到产品所有者#3)认证产品 - 他的另一个责任是认证正在构建的功能。在此过程中,他为每个产品待办事项项定义了接受标准。产品负责人还可以创建代表他定义的验收标准的验收测试,或者可以在创建它们时从中小企业或开发团队获得帮助。现在,他是通过执行验收测试来确保满足验收标准的人。他可以选择自己执行这些验收测试,也可以请专家这样做,以确保功能和质量方面得到满足并满足期望。此项活动通常在项目完成时在整个sprint中完成,以便可以发现错误并在实际Sprint审核会议之前修复。#4)参与 -产品负责人是Sprint相关活动的主要参与者。他与开发团队密切合作,解释项目,范围和价值。他还充当开发团队的推动者,能够在Sprint结束时获取他们应该提供的Product Backlog项目。除Sprint活动外,产品负责人还负责产品发布活动。在产品发布活动期间,产品负责人与利益相关方进行讨论,以讨论下一版本的项目。团队蓬勃发展的关键成功因素之一是整个团队应尊重产品负责人及其决策。产品负责人以外的任何人都不应该告诉团队要处理哪些项目。建议单个产品拥有一名全职产品所有者。但是,可以存在产品所有者是兼职角色的安排。代理产品所有者代理产品所有者是产品所有者自己注册的人,他可以接管他的所有职责,缺席并支持他。代理产品负责人对他所委派的所有责任负有责任,但最终完成的工作的责任仍然在于实际的产品负责人。代理产品负责人还有权代表实际产品负责人做出必要的决策。开发团队Scrum团队的另一个非常重要的部分是开发团队。开发团队由熟练掌握自己专业领域的开发人员组成。与其他Scrum团队成员不同,开发团队负责实际实施潜在可交付软件/增量,并在每个Sprint结束时交付。开发团队可能包括具有专业技能的人员,如前端开发人员,后端开发人员,开发人员,QA专家,业务分析师,DBA等,但他们都被称为开发人员; 没有其他标题是允许的。开发团队甚至不能像测试团队,需求规范团队等那样拥有子团队。团队的成立考虑了在没有外界帮助的情况下成功开发,测试和交付每个Sprint产品增量所需的所有基本技能。因此,该团队应该是自给自足和跨职能的。开发团队不会从Scrum团队外部获得任何帮助并管理他们自己的工作。开发增量的责任始终在于整个开发团队,但Scrum团队中的每个人都负责整体交付。完全由开发团队决定添加/删除团队成员。如果需要新的技能组合,开发团队可以选择在团队中构建专业知识或向团队添加新成员。角色和责任#1)开发和交付 - 开发团队负责根据每个sprint结束时的“完成定义”创建完成增量。完成增量可能不一定是下一个生产版本的一部分,但它绝对是最终用户可以使用的潜在可释放功能。产品负责人致电决定需要成为发布的一部分。开发团队负责开发和交付符合“完成定义”标准的每个Sprint的完成增量。任务和提供估算 -开发团队还负责从下一个Sprint中提取优先产品Backlog中的用户故事/项目。因此,这些项目构成了Sprint Backlog。Sprint Backlog是在Sprint计划会议期间创建的。开发团队的另一项非常重要的职责是通过分解Sprint项目并为这些Sprint项目提供估算来创建任务。没有人告诉开发团队做什么以及如何做。开发团队有责任从下一个Sprint中提供的Product Backlog中获取项目。Sprint启动后,无法更改/添加/删除项目。开发团队规模应明智地选择开发团队规模,因为它可能直接妨碍团队的生产力,从而影响产品交付。开发团队不应该非常庞大,因为它可能需要团队成员之间的大量协调。但是,对于一个非常小的团队来说,获得递增所需的所有技能将非常困难。因此,应为开发团队规模选择最佳数量。建议的开发团队规模为3到9个成员,不包括Scrum Master和产品负责人,除非他们还与其他开发人员一起开发软件增量。摘要Scrum团队角色产品拥有者开发团队Scrum Master尺寸Scrum团队规模 - 3到9自组织团队知道完成工作的最佳方式。没有人告诉自组织团队该做什么。跨职能团队拥有完成工作所需的所有技能,无需任何外部帮助。产品拥有者代表委员会或受其影响。与利益相关者和Scrum团队合作。管理产品积压解释产品待办事项。确定工作项的优先顺序。确保产品积压易于理解和透明。清楚地定义要处理的项目。确保开发团队了解产品待办事项中的项目在产品负责人中添加/删除/更改的任何内容都应通过产品所有者进行。接听电话以释放工作项。Scrum Master确保团队清楚地理解和采用Scrum。是Scrum团队的仆人领导者。删除障碍物保护团队免受无用的交互,最大限度地提高Scrum团队创造的业务价值。根据要求促进Scrum事件。确保会议时间安排。开发团队在每个Sprint结束时提供可能可释放的“完成”产品增量。它们是自组织和跨职能的。没有人告诉开发团队什么和如何做。没有标题是允许的。所有人都是团队中的开发人员。不能创建子团队。他们对Sprint项目负责。开发团队负责任务并提供估算。这就是我们在Scrum团队角色和责任方面的全部内容。我们讨论了每个团队成员所承担的责任以及他们作为一个整体团队的工作方式。Scrum的基本功 - 集合中英文版本 (角色和责任篇)Scrum的基本功 - 集合中英文版本 (基础篇)

January 11, 2019 · 1 min · jiezi

敏捷简介:什么是敏捷开发?

敏捷软件开发敏捷是世界上使用最广泛,最受认可的软件开发框架之一。大多数组织已经以某种形式采用了它,但是在采用计划的成熟度方面还有很长的路要走。本系列教程的唯一目的是将技术和非技术专业人员融入敏捷世界。我们将逐步引导您完成敏捷之旅,直到您了解使用敏捷背后的理念,优势以及如何实践它。本系列旨在使读者能够将敏捷和Scrum学习应用到他们的工作中。这个特别的教程专门向您解释为什么需要敏捷以及如何创建它。这里的基础是让您了解软件开发行业中敏捷采用的概念。敏捷的历史敏捷出生在一个晴朗的日子,当时有17个人具有不同的开发方法背景,在一起探索可能的替代软件开发解决方案,可以共同进行头脑风暴,寻求可能会缩短开发时间并减少文档的需求量。当时,软件开发过去发生的时间太长,以至于当项目准备交付时,业务已经向前发展,需求已经发生变化。因此,即使项目能够实现其既定目标,也无法满足业务需求。因此,这些不同软件工程技术的精英聚集在一起,他们会议的最终结果就是他们所谓的“敏捷宣言”,我们将在本系列的下一个教程中详细讨论。但是那天出生的敏捷并不是我们今天在组织中看到的。专家们同意的方法被称为“轻量级”且速度快。但是,本次会议的主要成果是认为更快的产品交付和持续的反馈是实现软件开发成功的关键。现有的瀑布技术过于繁琐,在最终产品准备交付之前没有提供反馈。这意味着没有进行要求修正的余地,并且在整个产品准备好之前,客户对进度没有任何看法。这就是这些专家想要避免的。他们想要一个能够持续反馈的解决方案,以避免后期返工的成本。敏捷挑战当时现有的瀑布技术过于繁琐,在最终产品准备交付之前没有提供反馈。它被称为开发的瀑布模型,因为团队首先完成了一步,然后才进入下一步。这意味着没有进行要求修正的余地,并且在整个产品准备好之前,客户对进度没有任何看法。这就是这些专家想要避免的。他们想要一个可以持续反馈的解决方案,以避免在以后阶段返工的成本。这就是为什么敏捷也是关于自适应和持续改进的原因,同时也是关于持续反馈和交付速度的原因。什么是敏捷承诺?敏捷承诺敏捷不仅仅是在开发软件时应用设定的实践。它还带来了团队思维方式的变化,这促使他们构建更好的软件,协同工作并最终让他们成为一个满意的客户。敏捷的价值观和原则使团队能够转移他们的注意力并改变他们构建更好软件的思维过程。敏捷到底是什么?敏捷不是一套规则。敏捷不是一套指导方针。敏捷甚至不是一种方法论。相反,敏捷是一套原则,鼓励灵活性,适应性,沟通和工作软件超越计划和流程。它在所谓的敏捷宣言中非常简洁地被捕获。敏捷软件开发使团队能够在开发复杂项目时更有效地协同工作。它由练习迭代和增量技术的实践组成,这些技术很容易被采用并显示出很好的结果。在将敏捷应用于行动中,我们有各种基于敏捷的方法去满足软件开发行业的所有需求,从软件设计和架构,开发和测试到项目管理和交付。不仅如此,敏捷方法和方法还为流程改进打开了一个范围,作为每个交付的一个组成部分。敏捷是一种软件开发的实践理念,建构一个自给自足且跨职能的团队致力于通过迭代进行持续交付,并通过收集最终用户的反馈在整个过程中发展。如何练习敏捷?各种多样化行业都有各种敏捷方法论。然而,所有这些方法中最流行的方法是:Scrum看板 (Kanban)极限编程 (XP)所有这些方法都侧重于精益 (Lean) 软件开发,并有助于有效和高效地构建更好的软件。这就是敏捷引言的全部内容。该部分的结构旨在帮助您了解团队在敏捷模式和思维模式下工作时应采用的核心价值观和原则。敏捷方法论和模型敏捷方法论简介:众所周知,敏捷是一种软件开发方法。我们还了解了敏捷创始人在敏捷宣言中提到的价值观和原则。在我们最初的讨论中,我们还避开了敏捷和传统瀑布模型之间的差异。在本教程中,我们将了解敏捷方法的优缺点。我们会看到什么是scrum?它与敏捷有何不同?然后我们将了解不同组织正在使用的各种敏捷方法,以及如何使用它们实现敏捷。您还将能够理解这些方法的不同之处以及优缺点。敏捷方法论的优点下面给出了敏捷方法的各种优点:客户在每次迭代 (iterative) /冲刺 (Sprint) 结束时不断获得项目进度的外观和感觉。每个sprint都为客户提供了一个工作软件,该软件根据他们提供的完成定义满足他们的期望。开发团队对不断变化的需求做出了很好的响应,即使在开发的高级阶段也能适应变化。持续的双向沟通 (feedback) 使客户参与其中,因此所有利益相关者 (Stakeholders) - 业务和技术 - 都能清楚地了解项目的进展情况。产品设计高效,满足业务需求。敏捷方法论的缺点虽然敏捷方法有几个优点,但它也有一些缺点。他们是:#1)不希望使用全面的文档,这会导致敏捷团队错误地解释这一点,因为敏捷不需要文档。因此严谨性会因文档而丢失。应该通过不断询问自己这是否是足够的信息来避免这种情况。#2)有时,在项目开始时,要求并不十分清晰。团队可能会继续发现客户的愿景已经重新调整,在这种情况下,团队需要整合许多变更,而且很难衡量最终结果。敏捷方法的类型世界各地都有几种敏捷方法。我们将详细了解最受欢迎的四个。#1)ScrumScrum很容易被认为是最流行的敏捷框架。“scrum”一词被大多数从业者认为是“敏捷”的同义词。但这是一种误解。Scrum只是您可以实现敏捷的框架之一。Scrum这个词来自体育橄榄球 (Rugby)。球员们在一个互锁的位置挤在一起推着对手。每个球员在他们的位置上都有明确的角色,并且可以根据情况的需求发挥进攻和防守的作用。同样,IT中的Scrum相信赋予自我管理的开发团队有三个具体且明确定义的角色。这些角色包括 - 产品负责人(PO),Scrum Master(SM)以及由程序员和测试人员组成的开发团队。它们在迭代时间盒装持续时间中一起工作,称为冲刺。第一步是PO创建产品待办事项。这是scrum团队要做的事情的待办事项列表。然后scrum团队选择优先级最高的项目并尝试在称为sprint的时间框内完成它们。记住所有这一切的更简单方法是记住3-3-5框架。这意味着scrum项目有3个角色,3个工件,5价值 和5个事件。这些是 -3 角色: PO,Scrum master和开发团队。3 工件:产品Backlog,Sprint Backlog和产品增量。5 价值: 集中,勇气, 开放性,承诺,尊重。5 事件: Sprint,Sprint计划,Daily Scrum,Sprint评论和Sprint回顾。我们将在后续教程中更详细地了解每个内容。#2)看板 (Kanban)看板是日语术语,意思是卡片。这些卡包含要在软件上完成的工作的详细信息。目的是可视化。每个团队成员都了解通过这些视觉辅助工作要完成的工作。团队使用这些看板卡进行持续交付。就像Scrum一样,看板也可以帮助团队有效地工作,并促进自我管理和协作的团队。但是这两者之间也存在差异 - 比如在scrum sprint期间,团队正在处理的项目是固定的,我们无法向sprint添加项目,而在看板中,如果有可用容量,我们可以添加项目。当需求经常变化时,这尤其有用。同样,另一个区别是,虽然scrum已经定义了PO,Scrum master和开发团队的角色,但是在Kanban中没有这样的预定义角色。另一个不同之处在于,尽管scrum建议对产品待办事项进行优先排序,但看板没有这样的要求,而且完全是可选的。因此,看板需要较少的组织并避免非增值活动,并且适用于需要对变化做出响应的过程。#3)精益 (Lean)精益是一种专注于减少浪费的理念。它是如何做到的?在精简中,您将流程划分为增值活动,非增值活动和基本的非增值活动。任何可归类为非增值活动的活动都是浪费,我们应该尝试在过程中消除这种浪费,使其更加精简。更精简的流程意味着更快的交付和更少的工作浪费在任务上,这无助于实现团队目标。这有助于优化软件开发周期中的每个步骤。这就是精益原则从精益制造转变为软件开发的原因。通过应用以下所示的七项精益原则,可以在任何IT项目中使用精益软件开发:正如他们的名字所暗示的,这些都是不言自明的。消除浪费是第一个也是最重要的精益原则,我们看到了如何做到这一点,我们只是将活动分类为价值和非增值。非值添加活动可以是代码的任何部分,可能使其不那么健壮,增加所涉及的工作量并占用大量时间而不添加合理的业务价值。它也可能是模糊的用户故事或不良测试或添加大图中不需要的功能。第二个原则放大学习再次易于理解,因为团队需要各种技能,以在快速变化的环境中提供产品,新技术可以在短时间内出现。做出迟到的决定可以在减少返工的情况下获得回报,就像预期会有任何变更,然后更好地延迟,以便团队不必在业务需求变化时重做工作。但是这里总是存在一种权衡,因为团队需要平衡这一点与提供更快速的第四个原则。推迟决策不应影响整体交付,也不得减少工作节奏。一只眼睛应该始终在完整的画面上。赋予权力的团队现在也非常普遍,这甚至是敏捷的建议。赋权团队更负责任,可以更快地做出决策。拥有权力的团队的所有权意识可以带来更好的结果。为了赋予团队权力,应该允许他们自己组织并自己做出决定。因此,我们看到精益和敏捷有很多共同之处,只有一个明显的区别 - 精益团队可以帮助改进产品,敏捷团队就是实际构建产品的团队。#4)极限编程(XP)极限编程是另一种最流行的敏捷技术。根据extremeprogramming.org,第一个XP项目于1996年3月6日开始。他们还提到XP以五种不同的方式影响软件项目开发 - 沟通,简单,反馈,尊重和勇气。这些被称为XP的值。其中,一切都始于沟通。XP团队定期与业务团队和其他程序员协作,并从第一天开始构建代码。这里的重点是在其他视觉辅助工具的帮助下尽可能地进行面对面的交流。极端程序员还会构建一个简单的代码,并从第一天开始获得反馈。重点是不要过分或预测尚未共享的要求。这使设计简单,只生产出满足要求的最小产品。反馈有助于团队改进并提高工作质量。这有助于他们在彼此学习的过程中建立对彼此的尊重,并学习如何分享他们的观点。这也给了他们勇气,因为他们知道他们已经收集了每个人的最佳想法,并根据其他人的反馈产生了一个好的产品。因此,他们也不害怕包含变更或收到有关其工作的进一步反馈。这在需求经常变化的项目中特别有用。持续的反馈将帮助团队以勇气包含这些变化。因此,我们已经看到了不同的敏捷方法,如Scrum,XP,看板和精益,以及它们各自的优缺点。现在,我们可以轻松区分它们,也欣赏它们之间的微妙差异。我们还了解了每种方法的基本原理,并了解了如何在需要时将它们应用于我们的项目中。在下一部分中,让我们了解Scrum的一切。Scrum框架 (Scrum Framework)SCRUM是敏捷方法中的一个过程,它是迭代模型和增量模型的组合。传统瀑布模型的主要障碍之一 是 - 在第一阶段完成之前,应用程序不会移动到另一阶段。而且,如果在周期的后期阶段发生一些变化,那么实施这些变化就变得非常具有挑战性,因为这将涉及重新审视早期阶段并重做变更。SCRUM的一些关键特性包括:自我组织和专注的团队。没有巨大的要求文件,而是有一个非常精确和重点的故事。跨职能团队作为一个单元一起工作。与用户代表密切沟通以了解功能。有一个最长一个月的明确时间表。Scrum不是一次完成整个“事物”,而是以给定的间隔做一些事情。在提交任何内容之前,会考虑资源功能和可用性。要很好地理解这种方法,理解SCRUM中的关键术语非常重要。重要的SCRUM术语1)Scrum团队Scrum团队由7人组成,其中包括+或 - 两名成员。这些成员是能力的混合体,由开发人员,测试人员,数据库人员,支持人员等组成,还包括产品所有者和Scrum主管。所有这些成员通过紧密协作一起工作,以递归和确定的间隔,开发和实现所述特征。SCRUM团队的坐姿安排在他们的互动中起着非常重要的作用,他们从不坐在小隔间或小木屋里,而是一张巨大的桌子。2)冲刺 (Sprint)Sprint是预定义的时间间隔或时间范围,其中必须完成工作并使其准备好进行审查或准备进行生产部署。这个时间框通常在2周到1个月之间。在我们的日常生活中,当我们说我们遵循1个月的Sprint周期时,它只是意味着我们在任务上工作了一个月,并准备好在该月底之前进行审核。3)产品负责人 (Product Owner)产品所有者是要开发的应用程序的主要利益相关者或主要用户。产品所有者是代表客户方的人。他/她拥有最终权力,应始终为团队提供。当任何人有任何需要澄清的疑问时,他/她应该可以到达。对于产品所有者而言,了解并且不在sprint中间或sprint已经开始时分配任何新要求非常重要。4)Scrum MasterScrum Master是Scrum团队的推动者。他/她确保Scrum团队富有成效和进步。如有任何障碍,scrum master会跟进并为团队解决问题。SCRUM Master是PO和团队之间的中介。他/她让PO了解Sprint的进展情况。如果团队存在任何障碍或问题,请与PO讨论并解决问题。就像团队的每日站立时一样,每天都会有一个关于PO的SCRUM Master的站立。5)业务分析师(BA)业务分析师在SCRUM中扮演着非常重要的角色。此人负责完成要求并在需求文档(基于其创建用户素材)中起草。如果用户故事/接受标准中存在任何含糊之处,他/她是技术(SCRUM)团队接洽的人,然后他将其接收到PO或者如果可能的话自行解决。在大型项目中,可能有超过1个BA,但在小规模项目中,SCRUM Master也可能作为BA。项目启动时获得学士学位总是一个好习惯。6)用户故事 (User Story)用户故事只不过是必须实现的要求或功能。在scrum中,我们没有那些巨大的需求文档,而是需求在一个段落中定义,通常具有以下格式:作为<用户/用户类型> 我想<一些可实现的目标/目标> 实现<做某事的某些结果或理由>例如:作为[管理员],我想[要密码锁],实现[以防用户连续3次输入错误的密码以限制未经授权的访问]。应该遵守用户故事的一些特征。用户故事应该简短,逼真,可以估计,完整,可协商和可测试。用户故事永远不会在Sprint中间被更改或更改。SCRUM Master和BA(如果适用)负责确保PO使用适当的“验收标准”正确起草用户故事“。如果要进行任何会影响sprint发布的更改,那么这些故事将从sprint中撤出,或者按照可用时间完成。每个用户故事都有一个验收标准 (Acceptance Criteria),应由团队明确定义和理解。验收标准详细说明了提供支持文档的用户故事。它有助于进一步完善用户故事。团队中的任何人都可以写下验收标准。测试团队根据这些验收标准确定测试用例/条件。7)史诗 (Epic) 史诗是模棱两可的用户故事,或者我们可以说这些是未定义的用户故事,并保留用于未来的冲刺。试着把它与生活联系起来,假设你要去度假。当你下周去的时候,你已经准备好了所有的东西,比如你的酒店预订,观光,旅行支票等等。但是你明年的假期计划呢?你只有一个模糊的想法,你可能会去XYZ的地方,但你没有详细的计划。史诗就像你明年的假期计划一样,在那里你只知道你可能想去,但是在这个时间点你不知道所有这些细节的地点,时间,对象。以类似的方式,存在将来需要实现的特征,其细节尚不清楚。大部分功能都以Epic开头,然后分解为可以实现的故事。8)产品积压 (Product Backlog)产品待办事项是一种存储所有用户故事的存储桶或源。这由产品负责人维护。产品待办事项可以设想为产品所有者的愿望清单,产品所有者根据业务需求对其进行优先级排序。在计划会议期间(参见下一节),从产品待办事项中获取一个用户故事,然后团队进行头脑风暴,理解并完善它,并在产品所有者的干预下共同决定要采取哪些用户故事。9)Sprint Backlog根据优先级,用户故事一次一个地从Product Backlog中获取。Scrum团队的头脑风暴决定了它的可行性,并决定了在特定冲刺上工作的故事。Scrum团队在特定sprint上工作的所有用户故事的集合列表称为Sprint backlog。10)故事点 (Story Point)故事点是用户故事复杂性的定量指示。基于故事点,确定故事的估计和努力。故事点是相对的而不是绝对的。为了确保我们的估计和努力是正确的,检查用户故事并不重要是很重要的。用户故事越精确,越小,估计就越准确。每个用户故事都根据Fibonacci系列(1,2,3,5,8,13和21)分配到故事点。数字越高,复杂就是故事。确切地说如果你给出1/2/3的故事点,那就意味着故事很小而且复杂度很低。如果你给分数为5/8,它是一个中等复杂的13和21非常复杂。这里的复杂性包括开发和测试工作。为了确定一个故事点,头脑风暴发生在Scrum团队中,团队共同决定一个故事点。开发团队可能会为特定故事提供3个故事点,因为对于他们来说可能有3行代码更改,但测试团队给出了8个故事点,因为他们觉得这个代码更改会影响更大的模块所以测试工作量会更大。无论你给出什么样的故事,你都必须证明这一点。因此,在这种情况下,头脑风暴发生,团队集体同意一个故事点。无论何时决定故事点,请记住以下因素:故事与其他应用程序/模块的依赖关系。资源的技能组合。故事的复杂性。历史学习。用户故事的接受标准。如果您不了解特定故事,请不要调整大小。每当故事大于或等于8分时,它就被分解为2个或更多故事。11)烧掉图表刻录图表是一个图表,显示了scrum任务的估计v / s实际工作量。它是一种跟踪机制,通过该机制,对于特定的冲刺,跟踪日常任务以检查故事是否正在朝着完成提交的故事点的方向前进。示例:要了解这一点,请查看下图:我假设:2周冲刺(10天)2个实际在冲刺上工作的资源。“故事” - >此列显示为sprint拍摄的用户故事。“任务” - >此列显示与用户素材关联的任务列表。“努力” - >此栏显示了努力。现在,这项措施是完成任务的总工作量。它没有描述任何特定个人的努力。“第1天 - 第10天” - >此列显示完成故事的剩余时间。请注意,小时不是已经完成的小时,但仍然是剩下的小时数。“估计的努力” - >是努力的总和。对于“开始”,它只是整个单独任务的总和:SUM(C5:C15)必须在1天内完成的总工作量是70/10 = 7.因此在第1天结束时,努力应该减少到70 - 7 = 63.以类似的方式,计算所有的直至第10天,估计的努力量应为0(第16行)“实际努力” - >顾名思义,实际上是完成故事的努力。也可能发生实际努力增加或减少的估计值。您可以使用内置函数和Excel中的图表来创建此燃尽图表。刻录图表步骤将是:输入所有故事(A5列 - A15列)。输入所有任务(B5 - B15列)。输入天数(第1天 - 第10天)。输入起动工作(总结任务C5 - C15)。应用公式计算每天(第1天至第10天)的“估计工作量”。在D15(C16- $ C $ 16/10)输入公式并将其拖动一整天。对于每一天,输入实际的努力。在D17(SUM(D5:D15))输入公式,用于总结剩余的实际工作量,并将其拖动到所有其他日期。选择它并按如下方式创建图表:12)速度Scrum团队在sprint中归档的故事点总数称为Velocity。Scrum团队通过其速度来判断或引用。话虽如此,但应该记住,这里的目标不是达到最大的故事点,而是要获得高质量的交付,尊重Scrum团队的舒适程度。例如:对于特定冲刺:用户故事总数为8,故事点如下所示。所以这里的速度将是故事点的总和= 30完成的定义:当所有故事都完成后,Sprint被标记为完成,所有开发,研究,QA任务都标记为“已完成”,所有错误都是固定关闭的,否则可以在以后完成(如不完全相关或不太重要)在备份日志中提取并添加代码审查和单元测试,估计的小时数已经达到了任务中的实际小时数,最重要的是,已经向PO和利益相关者提供了成功的演示。在SCRUM方法论中完成的活动#1)规划会议计划会议是Sprint的起点。这是整个Scrum团队聚集的会议,SCRUM Master根据产品积压和团队头脑风暴的优先级选择用户故事。根据讨论,Scrum团队根据Fibonacci系列决定故事的复杂程度并根据其进行调整。团队确定任务以及完成用户故事实施所需的工作(以小时为单位)。很多时候,计划会议之前都是“预先计划会议”。这就像scrum团队在参加正式计划会议之前所做的一项功课。团队试图在计划会议中写下他们想要讨论的依赖关系或其他因素。#2)执行Sprint任务顾名思义,这些是scrum团队完成任务并将用户故事带入“完成”状态所做的实际工作。#3)每日站立在冲刺周期中,scrum团队每天都会遇到,不超过15分钟(可能是一个直接的电话,建议在一天开始时)和状态3点:昨天团队成员做了什么?团队成员今天计划做什么?任何障碍(障碍)?促进这次会议的是Scrum大师。如果任何团队成员遇到任何困难,scrum master会跟进以解决问题。在Stand ups中,董事会也会进行审核,并自行显示团队的进展情况。#4)审核会议在每个sprint周期结束时,SCRUM团队再次会面并向产品所有者演示实现的用户故事。产品所有者可以根据其验收标准交叉验证故事。Scrum大师再次负责主持这次会议。同样在SCRUM工具中,Sprint关闭,任务标记完成。#5)回顾会议回顾会议在审议会议之后召开。SCRUM团队会见,讨论并记录以下几点:Sprint(最佳实践)期间进展顺利?什么在Sprint中表现不佳?得到教训行动项目。Scrum团队应该继续遵循最佳实践,忽略“不是最佳实践”,并在随后的冲刺中实施经验教训。回顾会议有助于实施SCRUM流程的持续改进。流程如何完成?一个例子!阅读了SCRUM的技术术语。让我试着用一个例子来演示整个过程。例:步骤1:让我们拥有一个由9人组成的SCRUM团队,其中包括1个产品所有者,1个Scrum master,2个测试人员,4个开发人员和1个DBA。步骤2:Sprint决定遵循4周的周期。所以我们从6月5日到 7 月4 日开始为期一个月的Sprint 。步骤3:产品所有者在产品待办事项中具有优先级的用户故事列表。步骤#4: 团队决定于 6月4 日举行“预先规划”会议。产品所有者从产品积压中获取1个故事,描述它并留给团队进行头脑风暴。整个团队直接与产品所有者讨论并进行沟通,以便清楚地了解用户故事。以类似的方式,采用各种其他用户故事。如果可能的话,团队也可以继续调整故事的大小。在所有讨论之后,个人团队成员回到他们的工作站和确定每个故事的各自任务。计算他们将要工作的确切小时数。让我们来看看会员如何结束这些时间。总工作小时数= 9 减1小时休息,减1小时会议,减去1小时电子邮件,讨论,故障排除等 所以实际工作时间= 6.Sprint 期间的总工作天数= 21天。 总可用小时数= 21 * 6 = 126. 该成员休假2天= 12小时(每个成员有所不同,有些可能请假,有些可能不休。) 实际小时数= 126 - 12 = 114小时。这意味着该成员实际上可以在此sprint中使用114小时。所以他将打破他的个人冲刺任务,总共达到114小时。第五步: 6月5 日,整个Scrum团队召开“规划会议”。产品待办事项中的用户故事的最终判决已完成,故事将移至Sprint Backlog。对于每个故事,每个团队成员都会声明他们确定的任务,如果需要,他们可以讨论这些任务,可以调整大小或调整大小(请记住Fibonacci系列!!)。Scrum主人或团队在工具中输入他们各自的任务以及每个故事的小时数。完成所有故事后,Scrum主人注意到了最初的Velocity并正式启动了Sprint。步骤#6:Sprint启动后,根据分配的任务,每个团队成员开始处理这些任务。第7步:团队每天开会15分钟并讨论3件事:他们昨天做了什么?他们今天打算做什么?任何障碍(障碍)?步骤#8:Scrum master在“Burn down chart”的帮助下每天跟踪进度。步骤#9:如果遇到任何障碍,Scrum主管会跟进解决这些问题。步骤#10: 7 月4 日,团队再次召开审查会议。成员向产品所有者演示实现的用户故事。步骤#11: 7 月5 日,团队再次召开会议,讨论回顾什么进展顺利?什么不顺利?行动项目。步骤#12: 7 月6 日,团队再次召开下一次冲刺的预先计划会议,并继续进行循环。推荐阅读Scrum ArtifactsWhat are Scrum Artifacts?Definition of Done vs Acceptance CriteriaWhat is Definition of Ready in Scrum?How to Write a Sprint Goal?What is Product Backlog in Scrum? Who Responsible for It?How to Refine Product Backlog?Agile & Scrum BasisComprehensive Scrum GuideWhat are Scrum’s Three Pillars?What is Agile Software Development?Scrum in 3 MinutesWhat are the 5 Scrum Values?What is the Evolution of Scrum?Agile & Scrum PrinciplesThe Agile Manifesto and Twelve Principles10 Most Frequently Mentioned Basic Rules in ScrumScrum RolesWhat is Scrum Team?What is a Self-Organizing Team in Scrum?How Scrum Team Works? - A Brief GuideHow to be a Good Product Owner in Scrum Project?What is Product Owner’s Role in Scrum? ...

January 8, 2019 · 2 min · jiezi

你认为每天的站立会议对Scrum有用吗?

每日Scrum (Daily Scrum Meeting) 可能是开发团队当天最令人沮丧的活动之一。虽然这个简短的站立是为了让每个人都能快速了解每个团队成员的活动,但它往往会陷入我们都鄙视的冗长会议中。那么我们如何才能重新获得日常反会议的简单性呢?这些最常见问题的解决方案将帮助您解决问题。问题:我们将Daily Standup格式化为会议当一群人离开办公桌聚在一个房间谈论某事时,你怎么称呼它?是的,你的本能是正确的,它被称为会议,而不是立场(即使你的Scrum大师让每个人都站起来)。每日站立或争吵的目标是最大限度地提高效率,消除团队在大厅里蜿蜒前行,再喝一杯咖啡是一个很好的方法。解决方案:将Scrum Master发送给团队这提出了一个新问题:如果站立不应该在会议室举行,那么团队应该聚集在哪里?那么为什么不在他们已经在使用的空间!正如我们在之前的文章中所讨论的那样,一个理想的开发团队在一个房间里一起工作,以便让所有的创意成果汇集在一起。这个环境也是进行站立的最有效的地方,即使Scrum主人必须喘气来到他们身边。问题:每日站立感觉就像一次重大的中断想象一下,你正在更换汽车中的油,你楔入发动机下方,肘部深入车内,准备拔出机油滤清器(试着想象一下你以前从未真正做过这个) 。现在想象一下,你必须放弃一切,完全离开汽车,告诉大家你在换油方面取得的进展。现在你可以放松自己回到汽车下面,将你的手臂楔回油过滤器并重新开始。如果这是日常事情,那么我也会开始生气。解决方案:尽早完成理想情况下,应该在早上和任何人开始执行当天任务之前首先进行站立。实际上,这并不总是有效,因为开发人员可能会在不同的时间进入。在任何认真的工作开始之前,尽早做好准备。如果一个重要的利益相关者,产品负责人或团队成员以外的任何人不在那里,那么他们会错过它。问题:没有人关注我们都在这里,做每日站立,每个团队成员轮流告诉每个人他昨天所做的事情的细节。二十分钟后,几乎所有人都将手机拿出来,并没有灵魂注意到。我们现在基本上没有工作日的1/24丢失到基本无用的Scrum练习解决方案:快速有趣“我昨天修复了那个日期/时间转换错误,今天我要抓住那个排序速度任务。”“昨天遇到了搜索问题的一个问题,它只返回了最多400个结果,得到了解决了我今天将完成用户管理页面的搜索任务。“现在想象一下7人团队中的每个团队成员都会发生这种情况。站起来相当快不是吗?会议应该进行的唯一时间是,如果有人有一个非常有趣的问题,那么开发人员可能会花一些时间讨论它。站立应该是非常短或非常有趣但不乏味。如果它很无聊,那就是你没有教育团队如何利用这段时间是你的错(作为Scrum Master)。简而言之:每日站立是建立一个伟大的Scrum团队的一个主要部分,前提是你不要把它变成另一个公司活动。站立在Scrum团队周围,没有别的。Scrum团队需要花费很少的时间(强调小的)来集中他们的进步,目标和对他们来说很重要的问题。在站立期间你做的任何事都等于开销。从那里开始,团队可以围着房间四处聊聊进度和问题,每个人都会在10-15分钟内重新开始工作,除非出现非常有趣的事情。

January 7, 2019 · 1 min · jiezi

前20名Scrum Master和敏捷Scrum面试问题

我们汇总了您可能会在面试中获得的20个面试问题的清单,以及有效的答案,帮助您为梦想的敏捷Scrum工作做好准备!1.在30秒内解释敏捷。敏捷是一种方法和行为框架,鼓励“及时”生产,使客户能够更快地获得高质量的软件。2.敏捷和传统项目管理(瀑布)之间有什么区别?敏捷鼓励包括设计,开发和测试在内的一切都在同一时间完成。相反,传统的项目方法在下一个开始之前关闭并完成一个阶段。敏捷鼓励短暂,频繁的反馈循环并包含对需求的更改。在瀑布中,通常直到项目结束才收集反馈,并且不鼓励进行更改。3.您是认证Scrum Master吗?如果您没有认证并且他们问您这个问题,请不要感到惊讶!职位描述可能需要或不需要认证 - 面试官可能会或可能不会认为认证足以使专业知识成为您所申请职位的良好候选人。如果您还没有Agile Scrum Master认证,请告知他们您是否计划在不久的将来投资该认证。请务必提及您在该领域多年的经验。4. Scrum中有哪些角色?Scrum只规定了三个角色:产品负责人,Scrum Master和交付团队。理想情况下,这些角色应该是跨职能的,而不是在其他项目之间共享。许多Scrum大师没有机会与一个跨职能或专注的团队合作,因为该组织的抵制或无法允许一些人称之为“奢侈品”。这个问题可能会导致面试官问你怎么样会处理与团队中没有设计师或测试人员的团队合作,或者如何处理非专职团队。准备好了!5.什么是每日站立?关于敏捷的一个面试问题肯定是每日站立。答案?每天,最好是在早上,团队会面不超过15分钟回答三个问题:你昨天做了什么? 你今天打算做什么? 是否存在阻碍您工作的障碍或障碍?这次Scrum仪式并不意味着成为利益相关者的状态会议,而是一种激励团队并让他们为当天设定焦点的方式。6.描述Sprint计划会议中发生的事情。在Sprint计划中,产品负责人介绍了sprint的目标,并讨论了高优先级产品待办事项。交付团队然后选择下一个sprint的工作量。7. Scrum Master的作用是什么?以下是如何处理这样的Scrum Master面试问题:Scrum Master为团队服务并保护他们免受任何可能妨碍他们完成冲刺目标的干扰。他们还会删除障碍,教会团队自我组织,并担任教授敏捷和Scrum价值观和原则的教练。8.敏捷和Scrum之间有区别吗?是! 敏捷是Scrum所涵盖的更广泛的保护伞。敏捷有四个主要价值观和十二个原则。Scrum有自己的一套价值观和原则,并提供一个轻量级的“框架”来帮助团队变得敏捷。9.列举其他一些敏捷框架。除了Scrum之外,还有其他框架,例如看板,测试驱动开发和特征驱动开发。提及您遵循的框架并提供方案。10.什么时候应该使用瀑布而不是Scrum?如果需求简单,可预测,完全定义和理解,并且不会更改,请使用瀑布。11.您会为您的项目推荐自动化测试吗?Scrum鼓励使用自动化性能或回归测试,以便您可以尽快地连续交付软件。提供您的团队可能使用过的任何自动化测试工具的示例。12.你的短跑多久了?理想的冲刺长度在一到四周之间,两周的冲刺是最广泛使用的。13.什么是速度?速度是过去3-4次冲刺的平均点数。它用于帮助预测何时交付积压物品。14.如果有人想改变要求,可以吗?是。敏捷鼓励客户和利益相关者经常反馈,以便改进产品。我们需要能够接受改变。15.您使用了哪种类型的指标或报告?Sprint,发布刻录和刻录图表是标准报告。大多数公司还希望了解每个sprint完成的故事数量以及发布到生产后发现的缺陷数量。16.什么是烧毁图表?刻录图表显示团队已经烧毁的工作量 - 例如冲刺期间的小时数。讨论你过去如何使用它们。17.什么是回顾?回顾会是检查和调整过程的会议。这个敏捷方法访谈问题正在寻找进行回顾的许多方法 - 所以准备好解释一种或两种格式。18.您一次管理了多少个Scrum团队?这是一个很受欢迎的问题。不要提供Scrum指南,每个团队只有一个Scrum Master作为您的答案!在这个新角色中,您可能需要领导多个团队。注意使用“托管”和“领导”这个词.Scrum Masters不管理,他们领导团队 - 所以一定要在你的回复中使用这个词。你的面试官可能会非常仔细地听!19.您对团队使用了哪些类型的要求?Scrum中的要求是使用标准编写的用户故事,“作为___,我想要__以便我可以___。”作为Scrum Master,您不一定要编写用户故事,但是您可以帮助产品负责人确保用户故事的编写,优先级和准备好冲刺。20.描述交付团队成员似乎没有相处的时间。你是怎么处理的?注意一点冲突总是好的,但是你的面试官正在寻找你成为有效领导者的能力。反思你有几个团队成员,似乎从来没有能够解决问题。您是如何鼓励这些团队成员一起工作的?这是一项团队建设活动吗?你确定他们有一个共同的目标吗?说明你遇到的问题,你如何解决它以及结果。与任何面试准备一样,您需要自定义您的答案,以满足您面试的公司。想想大公司如何在他们的日常实践中使用敏捷Scrum方法。他们[希望充当这个角色的人能够擅长什么?]推薦的Scrum角色文章What is Scrum Team?What is a Self-Organizing Team in Scrum?How Scrum Team Works? - A Brief GuideHow to be a Good Product Owner in Scrum Project?What is Product Owner’s Role in Scrum?Agile Development: How to Become a Qualified Scrum Master?What is Pig and Chicken in Scrum?Project Manager vs Scrum Master vs Project OwnerWhat Are The Three Scrum Roles?What is a Scrum Master? The Role and ResponsibilitiesWhat is Cross-Functional Team in Agile? ...

January 4, 2019 · 1 min · jiezi

成為一個偉大的Scrum Master的標準

自我評估作為Scrum大師, 你在扮演什麼角色(上面? 還是下?)哈哈!有些人仍然無法改變舊的思維方式一个伟大的Scrum Master确保整个团队支持所选的Scrum流程;管理超出团队自组织能力的障碍,阻止他们实现Sprint目标;认识到健康的团队冲突并促进建设性的分歧;准备好具有颠覆性,以便在组织内部实施变革;理解自组织的力量;理解稳定的冲刺节奏的价值,并尽一切努力创造和维护它;知道如何真正倾听并且沉默舒适;理解教练的力量,并且用心去学习一些有力的问题;教导产品负责人如何最大化ROI并实现目标;也适合XP,看板和精益。A great Scrum Master (英文原文)Ensures the entire team supports the chosen Scrum process;Manages the impediments that exceed the self-organizing capabilities of the team and it prevents them in achieving the Sprint Goal;Recognizes healthy team conflict and promotes constructive disagreement;Is prepared to be disruptive enough to enforce a change within the organization;Understands the power of a self-organization;Understands the value of a steady sprint rhythm and does everything to create and maintain it;Knows how to truly listen and is comfortable with silence;Understands the strength of coaching and has learned some powerful questions by heart;Teaches the Product Owner how to maximize ROI and meet objectives;Is also competent with XP, Kanban and Lean.推薦的Scrum文章What is Burndown Chart in Scrum?What is the Role-Feature-Reason Template?Sprint Increment vs Potential Shippable Product vs MVP vs MMPWrite SMART Goals & INVEST for User StoriesWhat is DEEP in Product Backlog?How to Write Product Vision for Scrum Project?How to Use Scrum Board for Agile Development?Who Create Product Backlog Items or User Stories in Scrum?What is Agile Estimation?What is Story Point in Agile? How to Estimate a User Story? ...

January 4, 2019 · 1 min · jiezi

Scrum框架和規則

Scrum框架Scrum是一种管理项目的敏捷方式,通常是软件开发。使用Scrum进行敏捷软件开发通常被视为一种方法论; 但不是将Scrum视为方法论,而是将其视为管理流程的框架。要做Scrum,我们所需要的只是16个必需品,即3个角色,3个文物,5个价值观和5个事件。这些16个要素通过Scrum指南中描述的某些规则和指南绑定在一起。这些规则和指南可帮助Scrum团队尽可能充分利用Scrum框架来创建最大的业务影响。Scrum是3355的组合.scrum框架的核心概念可以简单地记为3.3.5.5,如下所示:3个角色产品拥有者开发团队Scrum Master3件文物产品积压Sprint Backlog - Sprint待办事项列表产品增量- 潜在的可发货产品增量5个事件短跑Sprint计划会议每日Scrum会议Sprint评审会议Sprint回顾会议5个值打开尊重勇气焦点承诺3355的目标落后于三个Scrum支柱透明检查适应“完成”(DoD)的定义是通过Scrum团队的5个事件来实现3个支柱来实现的。3355 Scrum框架Scrum依赖于一个自组织,跨职能的团队。Scrum团队是自我组织的,因为没有整体团队负责人决定哪个人将完成哪项任务或如何解决问题。这些是由整个团队决定的问题。在Scrum中,团队是跨职能的,这意味着每个人都需要从构思到实现。在敏捷开发中,Scrum团队由两个特定角色提供支持。第一个是ScrumMaster,可以被认为是团队的教练,帮助团队成员使用Scrum流程在最高级别执行。Scrum规则 (Scrum Rules)当我提到规则时,我的意思是那些无法修补以适应特定背景的方面。例如:没有3个角色,你不能做Scrum - 产品负责人,开发团队和Scrum Master。当我提到指南时,我指的是那些可能被改变以适应特定背景的方面; 然而,影响只能在实施后进行验证。然后我们相应地检查(insepction) 和调整(adaptation)。例如,Product Backlog Refinement消耗的不超过团队容量的10% (<10% of the sprint duration)。是容量-小时数;故事点数; #天-好吧,没有规则。Scrum团队自我组织并选择最适合他们背景的东西;遵循我们消耗的指导方针,无论如何不超过团队容量的10%。在这篇文章中,我将探讨一些这样的指导方针,这些指南将11个要素绑定在一起,并赋予Scrum团队灵活性以适应这些方面的背景。#1。开发团队规模:开发团队的规模建议为3-9名成员。根据具体情况,可能会有更多人或更少。它的影响因团队环境而异。来自Scrum指南:不到三个开发团队成员减少了交互,导致生产率降低。较小的开发团队可能会在Sprint期间遇到技能限制,导致开发团队无法提供可能可释放的增量。拥有超过九名成员需要太多协调。大型开发团队为实证过程提供了太多的复杂性。#2。开发团队的标题/角色: Scrum不承认开发团队中的任何标题/角色。在开发团队中,每个人都是开发团队成员。虽然在组织内,团队成员可能拥有头衔/角色。根据我的经验,我与Scrum有关;我没有遇到任何只有一个职位/角色的团队。#3。每日Scrum的三种问题格式:我使用过的大多数团队都使用Daily Scrum的3个问题的格式:昨天我做了什么帮助开发团队实现Sprint目标?今天我将做些什么来帮助开发团队实现Sprint目标?我是否看到任何阻碍我或开发团队达到Sprint目标的障碍?令人惊讶的是,这3个问题只是开始使用Scrum的团队的模板。只要他们专注于Sprint目标的进展,开发团队就可以以他们认为合适的任何方式构建Daily Scrum。#4。事件的时间框:事件的时间框表示事件为1个月冲刺所允许的最长时间。准则是:对于较短的短跑持续时间,它通常较短。 这是否意味着,对于为期两周的Sprint,Sprint Planning的时间限制为4小时,Sprint Review为2小时,Sprint回顾为1小时和半小时?编号 为尽可能满足他们的目的所需要的事件可以短/长;但不能超过最大分配时间。例如:Sprint规划活动为期2周Sprint可能会在2小时内结束,如果达到目的,或者可能会持续到8小时(如果没有)。#5。进展趋势: Scrum指南建议使用烧毁图表,累积流量等实践来监控进度趋势。但是,团队完全可以自由选择他们认为合适的任何练习来达到目的。根据我的经验,我见过团队创建视觉路线图,基于里程碑的进度,旅程线,发布燃烧图等。虽然,我们还需要记住在复杂的环境中;只有经验数据才能帮助我们做出正确的决定。#6。估算:该的Scrum指南介绍了积压的产品项目需要估计。他们应该如何估计完全取决于Scrum团队。故事点,理想日,T恤尺码,狗尺码是一些方法。Scrum团队可以做“没有估计”吗?当然,只要Scrum团队能够起草一份支持经验主义的计划; 创建透明度并帮助团队在Sprint结束时创建可能可释放的“完成”增量; 没关系。Scrum团队自行组织选择适合其背景的内容。#7。工作分解:在“选择的工作将如何完成?”部分。对于Sprint计划,Scrum指南提到-开发团队在Sprint的头几天计划的工作在本次会议结束时分解,通常分为一天或更短时间。这通常有助于发展团队这样做,但这并非强制要求。根据我的经验,我已经看到几个团队没有将工作项目细分到如此精细的水平。他们非常清楚如何将功能转换为“完成”增量。#8。Sprint评审:这是一项重要的Inspect&Adapt活动,Scrum团队与主要利益相关方就Sprint期间取得的成果进行合作,以及在下一个Sprint中可以做些什么来优化产品的价值。Scrum指南还描述了Sprint Review的一部分:与会者包括Scrum团队和产品负责人邀请的主要利益相关者产品负责人解释了产品待办事项项目已“完成”且未完成的内容开发团队讨论Sprint期间的情况,遇到的问题以及这些问题是如何解决的开发团队演示了它“完成”的工作并回答了有关增量的问题产品负责人会按原样讨论产品Backlog。他或她根据迄今为止的进展预测可能的目标和交付日期(如果需要)整个小组就下一步做什么进行合作,以便Sprint Review为后续的Sprint Planning提供有价值的信息回顾产品的市场或潜在用途如何改变下一步最有价值的事情审查下一个预期的产品功能或功能版本的时间表,预算,潜在功能和市场对于每年获得资助的Scrum团队来说,每两周进行一次Sprint评估的预算是否合理?也许不吧。 并非所有上述元素都适用于所有Scrum团队。它们作为指导提供,以便Scrum团队可以选择在Sprint评审期间讨论和触及产品交付的各个方面,因为他们认为适合他们的背景。#9。发布到生产:每个Sprint的目的是创建可能可释放的“完成”增量。这意味着增量需要处于可用状态并符合Scrum团队的DoD。 但是,将增量发布到生产中的选择由产品负责人决定。基于团队的背景和他们创造的增量; Scrum团队可能决定每个sprint执行多个版本,每个sprint一个版本或多个sprint的累积发布;无论如何优化产品的价值。#10。完成的定义:完成的定义有助于提高透明度并创建对完成工作意味着什么的共同理解。根据Scrum指南,Scrum团队有望扩展其国防部并使其更高质量的更严格。 同样,这不是一个规则。取决于团队的背景; Scrum团队可能会在每次回顾中重新审视它的国防部,或者可能继续使用相同的国防部,除非它学会了新的东西以提高产品的质量。结论:这些只是在Scrum指南中传播的一些指导原则。我想提出这个区别,因为我经常发现Scrum团队对Scrum规则和指南感到困惑。很少有人很常见- 将Sprint Planning的时间框修改为4小时进行为期2周的冲刺,或者开发团队花费太多时间和精力将Product Backlog Items (PBI) 分解为“任务” - 其他人则不那么常见。我相信这篇文章将帮助团队识别Scrum的一些方面,他们可以修改这些方面以适应他们的背景,以及他们能够区分那些无法改变的方面。Scrum ArtifactsWhat are Scrum Artifacts?Definition of Done vs Acceptance CriteriaWhat is Definition of Ready in Scrum?How to Write a Sprint Goal?What is Product Backlog in Scrum? Who Responsible for It?How to Refine Product Backlog?What is Sprint Backlog in Scrum? ...

January 4, 2019 · 1 min · jiezi

Scrum指南 (2017) 更新

今天(2017年11月7日),Ken Schwaber 和 Jeff Sutherland 发布了 Scrum 指南的更新。Scrum指南是Scrum的最终定义,由Scrum的创建者Ken和Jeff编写。《Scrum指南》描述了Scrum框架。而且,它只有19页长。通过保持简短的定义,它不仅强制实现一个明确的重点,而且提醒每个人它不是一种方法论。过程是根据团队所处的情况使用框架而产生的。因为Scrum关注复杂的问题,所以不可能定义完整的方法论。相反,Scrum提供了一个简单的框架,鼓励正确的经验过程出现。这使得现在超过1200万人可以练习Scrum,同时在非常不同的情况下解决非常不同的问题。添加了有关Scrum使用的部分: Scrum最初是为管理和开发产品而开发的。从20世纪90年代初开始,Scrum在全球广泛使用:研究和确定可行的市场,技术和产品能力;开发产品和改进;每天多次发布产品和增强功能;开发和维护云(在线,安全,按需)和其他操作环境以供产品使用; 和,维持和更新产品。Scrum已被用于开发软件,硬件,嵌入式软件,交互功能网络,自动驾驶汽车,学校,政府,市场营销,管理组织的运作以及我们日常生活中使用的几乎所有东西,如个人和社会。随着技术,市场和环境的复杂性及其相互作用的迅速增加,Scrum在处理复杂性方面的实用性每天都在证明。事实证明,Scrum在迭代和增量知识转移方面特别有效。Scrum现在广泛用于产品,服务和上级组织的管理。Scrum的本质是一个小团队。个人团队非常灵活和适应性强。这些优势继续在单个,多个,多个团队网络中运行,这些团队开发,发布,运营和维护数千人的工作和工作产品。他们通过复杂的开发架构和目标发布环境进行协作和互操作。当Scrum指南中使用“develop”和“development”这两个词时,它们指的是复杂的工作,例如上面提到的那些类型。更改了“Scrum Master”部分中的措辞,以更好地阐明角色。现在的案文如下: Scrum Master负责推广和支持Scrum指南中定义的Scrum。Scrum Masters通过帮助每个人理解Scrum理论,实践,规则和价值观来实现这一目标。Scrum Master是Scrum团队的仆人领导者。Scrum Master帮助Scrum团队以外的人了解他们与Scrum团队的哪些互动是有用的,哪些不是。Scrum Master帮助每个人改变这些交互,以最大化Scrum团队创造的价值。添加到产品负责人的Scrum Master Service部分 确保Scrum团队中的每个人都能够理解目标,范围和产品领域。将Daily Scrum部分的第一段更新为: Daily Scrum是一个15分钟的开发团队时间盒活动。每日Scrum每天都在Sprint举行。在此,开发团队计划在接下来的24小时内开展工作。通过检查自上次每日Scrum以来的工作并预测即将到来的Sprint工作,这可以优化团队协作和性能。Daily Scrum每天都在同一时间和地点举行,以降低复杂性。更新了每日Scrum部分,以明确Daily Scrum的目标,包括以下文本: 会议结构由开发团队制定,如果侧重于Sprint目标的进展,可以采用不同的方式进行。一些开发团队将使用问题,一些将更多基于讨论。以下是可能使用的示例:昨天我做了什么帮助开发团队实现Sprint目标?今天我将做些什么来帮助开发团队实现Sprint目标?我是否看到任何妨碍我或开发团队满足Sprint目标的障碍?在时间框周围增加了清晰度 使用“最多”一词来删除任何问题,即事件的时间框意味着最大长度,但可能更短。添加到Sprint Backlog部分: 为了确保持续改进,它包括至少一种团队工作的高优先级方式,在之前的回顾会议中确定。为增量部分添加了清晰度: 增量是一个可检查的,“完成”的工作,支持Sprint结束时的经验主义。增量是迈向愿景或目标的一步。2013年和2016年Scrum指南之间的变化关于Scrum值的部分。当Scrum团队体现并实践承诺,勇气,专注,开放和尊重的价值观时,透明度,检查和适应性的Scrum支柱将栩栩如生,为每个人建立信任。Scrum团队成员在使用Scrum事件,角色和工件时学习和探索这些值。成功使用Scrum取决于人们是否越来越熟练地掌握这五个价值观。人们个人致力于实现Scrum团队的目标。Scrum团队成员有勇气做正确的事情并处理棘手的问题。每个人都关注Sprint的工作和Scrum团队的目标。Scrum团队及其利益相关者同意对所有工作以及执行工作所面临的挑战持开放态度。Scrum团队成员互相尊重,是有能力的独立人士。2011年和2013年Scrum指南之间的变化添加了关于工件透明度的部分。Scrum依赖于透明度。根据工件的感知状态做出优化价值和控制风险的决策。在透明度完成的情况下,这些决定具有良好的基础。如果工件不完全透明,这些决策可能存在缺陷,价值可能会降低,风险可能会增加。Sprint Planning现在是一项活动。其中涉及两个主题:Sprint可以做什么,以及如何完成所选择的工作。在开发团队预测Sprint的产品Backlog项目之后,Scrum团队制定了Sprint目标。Sprint目标在开发团队的工作中创造了一致性,如果没有共同的目标,这些工作就不会出现在单独的计划中。请注意正式包含Sprint目标。产品Backlog经过精炼而非整理。精确的产品Backlog项目是透明的,足够的理解和粒度足以输入Sprint计划和Sprint的选择。具有此透明度的产品Backlog项称为“Ready”。Ready和Done是两个强化透明度的状态。Scrum规定其事件以创建规律性并最小化对未在Scrum中定义的会议的需求。所有事件都是时间盒事件,因此每个事件都有最长持续时间。作为容器事件的Sprint具有不能缩短或延长的固定持续时间。只要达到事件的目的,剩下的事件就可以结束; 确保花费适当的时间而不会在过程中浪费。Daily Scrum作为计划活动的重要性得到了加强。它经常被视为一种状态事件。每天,开发团队应该了解它打算如何作为一个自组织团队一起工作,以实现Sprint目标,并在Sprint结束时创建预期的增量。会议的输入应该是团队如何实现Sprint目标; 输出应该是一个新的或修订的计划,以优化团队在满足Sprint目标方面的努力。为此,重新制定了三个问题,以强调团队对个人的影响:昨天我做了什么帮助开发团队迎接Sprint今天我将做些什么来帮助开发团队实现Sprint目标?我是否看到任何妨碍我或开发团队满足Sprint目标的障碍?价值观的概念得到了加强,可以在Sprint评论中使用。在Sprint评审期间,Scrum团队和利益相关者就Sprint的工作进行了合作。基于此以及Sprint期间产品Backlog的任何更改,与会者将就可以采取的下一步措施进行协作以优化价值。2010年和2011年Scrum指南之间的变化开发团队不承诺完成Sprint计划会议期间计划的工作。开发团队创建了它认为将要完成的工作的预测,但是随着Sprint中的更多知识的出现,预测将会发生变化。Scrum没有要求使用刻录图来监控进度。Scrum仅需要:Sprint的剩余工作每天汇总并且已知。整个Sprint都保持着完成Sprint工作的趋势。在使用Scrum时,发布计划是一件很有价值的事情,但Scrum本身并不需要。Sprint Backlog是为Sprint选择的Product Backlog项目,以及交付它们的计划。不再需要“Sprint Backlog项目”的概念,尽管这种技术可以制定一个很好的计划。自组织开发团队总是有一个计划。产品待办事项是“有序的”,而不是“优先”,为产品负责人提供灵活性,以便在其独特情况下优化价值。添加了Product Backlog Grooming的做法。删除许多提示,可选的做法和技术。执行创建增量工作的人员团队是开发团队。无论各个团队成员的工作如何,他们都被称为开发人员。删除了对鸡和猪的参考。删除了对撤消工作的引用。Agile & Scrum BasisComprehensive Scrum GuideWhat are Scrum’s Three Pillars?What is Agile Software Development?Scrum in 3 MinutesWhat are the 5 Scrum Values?What is the Evolution of Scrum?Classical Project Management vs Agile Project ManagementWhy is Scrum Difficult to Master? ...

January 4, 2019 · 1 min · jiezi

最新的Scrum指南中有什么更新?

最新版Scrum指南已由来自Scrum, Inc的Scrum共同发明人Ken Schwaber和来自Scrum.org的Jeff Sutherland联手发布。上一版发布于2013年,此版最大的变化是包含了Scrum价值观。Scrum指南包含有关Scrum的权威指南,「整个游戏的规则」。Schwaber和Sutherland通过合作定期更新该Scrum指南,并通过Scrum指南网站的User Voice区域响应来自社区的反馈。新版发布后,InfoQ与Schwaber谈到了最新版中的改动和未来的计划。Scrum Guide 指南的目的Scrum 是一個框架,這框架適用於開發,交付,與持續支援具有錯綜複雜的產品。這份指南包含 Scrum 的定義,其中定義涵蓋了 Scrum 中的角色,活動,產出物,與它們之間如何進行的規則。Scrum 是由 Ken Schwaber 和 Jeff Sutherland 共同發展出來的;Scrum 指南也是由他們所撰寫及提供,他們是 Scrum 指南背後的共同推手。Scrum 的定義Scrum (名詞):一個框架,人們可以運用這個框架來處理錯綜複雜的調適性問題,善用生產力與創意來交付盡可能最高價值的產品。Scrum 是:● 輕量的 ● 淺顯易懂的 ● 難以精通Scrum 是一個流程框架,從 1990 年代初期它就被用來管理生產錯綜複雜的產品。Scrum 不是一種流程,一個技巧,或明確既定的方法。倒不如説 Scrum 是一個框架,在其中你可以使用各種不同的流程與技巧。運用 Scrum 可以清楚的呈現不同產品管理方法和工作技巧的功效,因此你可以持續改善產品,團隊,還有工作環境。Scrum 框架中包含了 Scrum Teams 和他們相關的角色,活動,產出物,和規則。每個框架中的組成都有特定的目的,也都是讓 Scrum 成功和運行的必要條件。Scrum 規則把角色,活動和產出物整合在一起,也主宰了各個組成之間的關係和互動。這整份文件都是在描敘 Scrum 規則。各種使用 Scrum 框架的具體策略有很大的差異,這些策略不在這指南中描述。Scrum 的運用Scrum 一開始是為了管理和開發產品而發展出來的。從 1990 年代初期開始,Scrum 就在全世界被大量的運用在:研究和辨識出市場,技術,產品性能的可行性;開發產品和加強功能;發佈產品和加強功能,頻率高到一天可能發佈許多次;開發和支援雲端服務(線上,高安全性,隨時存取)和其他營運環境來幫助產品的運用,以及支援和更新產品。Scrum 已經被使用於開發軟體,硬體,韌體,互動的網路,自駕車,學校,政府,行銷,管理組織的營運,還有幾乎所有我們日常生活中的事物上,不論是個人或是社會。在科技,市場,環境都日趨錯綜複雜,而且各個因素之間的互動快速增加的情況下,每天都可以看到運用 Scrum 來處理錯綜複雜的問題的效用。Scrum 被證明在迭代和漸進式的知識轉移中特別有效。目前 Scrum 已經被廣泛的使用在組織內的產品,服務,和管理。Scrum 的精華在於小型的團隊。每個團隊都具有高度彈性和調適性。這些團隊從事開發,發佈,營運,和支援的工作,不論是一個團隊,一些團隊,許多團隊或是更多串連在一起的團隊所組成,都擁有這些優勢,他們藉由精細複雜的開發架構和鎖定發佈環境來協同合作和交互運作。當 Scrum Guide 中使用「開發 (develop)」這個字的時候,指的是從事複雜的工作,如上面所陳述到的那些類型。Scrum 的理論Scrum 是立基於經驗導向的流程控制理論,或是經驗主義。經驗主義立論於知識來自於經驗和依照已知的資訊來下判斷。Scrum 使用迭代和逐步 Increment 的方式,來最大化可預測性和控制風險。 有三根支柱支撐了所有經驗導向的流程控制的實行:透明性,檢視性,調適性。透明性負責產生成果的人員必須清晰地看見流程中重要的部分,這些部分被共同的標準來定義,所以觀看的人能得到一致的認知,這就是透明性。例如:● 所有的參與者對該流程都有共同的語言;以及● 真正執行的人員和檢視 Increment 成果的人員,需要對「完成」之定義,有一個共同的認知。檢視性Scrum 的成員必須經常檢視 Scrum 的產出物和 Sprint 目標的進度來檢測意料之外的變數。他們的檢視不應該頻繁到會阻礙工作的進行。最有效益的檢視方式,是由盡職且擁有技能的檢視者在工作的當下進行。調適性如果檢視者判斷流程中的某些部分超出了可以接受的範圍,且會造成產品不被接受,就必須調整當下的流程或使用材料。調整必需越快越好來減少未來更多的偏差。在 Scrum 中規定了四個幫助檢視性和調適性的正式活動,在 Scrum 活動的章節會介紹:● Sprint Planning● Daily Scrum● Sprint Review● Sprint RetrospectiveScrum 價值觀當 Scrum Team 體現和活化承擔,勇氣,專注,開放和尊重這五種價值觀時,Scrum 的三根支柱:透明性,檢視性,調適性就會出現並幫助大家建立信任。隨著 Scrum Team成員從事 Scrum 角色,活動和產出物的過程中,他們就會學習和探索這些價值。 要成功運用 Scrum 取決於成員是否精通並融入這五個價值。成員個人承諾會達到 Scrum Team 的目標,Scrum Team members 有勇氣做對的事情和處理艱難的問題,每個人專注在 Sprint 的工作和 Scrum Team 的目標上,Scrum Team 和利害關係人同意對工作和工作上的挑戰保持開放的心態,Scrum Team members 互相尊重對方是有能力和獨立的人。Scrum TeamScrum Team 由 Product Owner,Development Team 和一位 Scrum Master 組成。Scrum Teams 是一個自我組織和跨職能的團隊。自我組織的團隊會自行選擇最好的方式來完成工作,而不是被團隊外的人指示如何做。跨職能的團隊不需依靠非團隊成員而擁有所有完成工作所必備的能力。Scrum 中的團隊模式是設計用來將彈性,創意,和生產力最大化。Scrum Team必須證明自己在前述的情況和錯綜複雜的工作中越來越有效。Scrum Teams 用迭代和逐步 Increment 的方式交付產品,將回饋的機會最大化。用逐步Increment 的方式交付「完成」的產品,可以確保一直提供一個潛在可用的產品版本。The Product OwnerProduct Owner 負責將產品的價值最大化,而價值來自於 Development Team 的工作成果。如何做到這點可能在每個組織,Scrum Teams,或個人,都差異很大。Product Owner 這個角色只能由一個人來擔任,專門負責管理 Product backlog。Product backlog 管理包含:清楚的表達 Product Backlog items;針對 Product backlog 上的事項進行排序來達到最好的目標和使命;將 Development Team 工作所產生的價值最佳化確保 Product backlog 是每個人都可以看見的,是有透明度的,以及清晰瞭解的,而且可以顯示出 Scrum Team 接下來要做的事;和確保 Development Team 對 Product Backlog 的了解有到達所需要的程度Product Owner 可以自己做以上的工作,或由 Development Team 來做。但不管如何都是由 Product Owner 當責。Product Owner 是由一個人來擔任,而不是一個委員會。Product Owner 可能代表一個委員會對於 Product backlog 的期望要求,但任何人想要改變 Product Backlog 的優先順序,都需要經過 Product Owner 的同意。要讓 Product Owner 成功,整個組織必須尊重他/她的決定。Product Owner 對於Product Backlog 內容和順序之決定是透明的,沒有人可以強迫 Development Team 做 Product backlog 以外的需求。The Development TeamDevelopment Team 由一群專業人士組成,他們可以在每個 Sprint 結束時交付「完成」潛在可發佈的產品 Increment。「完成」的產品 Increment 必須在 Sprint Review 上呈現。只有 Development Team 的成員可以產生產品 Increment。組織建立並授權 Development Team,讓他們可以自行組織和管理他們自己的工作。所達成的綜效可讓 Development Team 整體的效率和效能達到最大化。Development Team 有以下的特性:他們是自組織的。沒有人(甚至是 Scrum Master)可以對 Development Team 下指導棋,告訴他們如何把 Product backlog 轉換成潛在可發佈的產品 Increment;Development Team 是跨職能的,擁有產出產品 Increment 所需要的所有技能;Scrum 認為 Development Team members 沒有職稱,不管個人所做的工作是什麼;Scrum 認為 Development Team 中沒有小團隊,不管需要解決的是什麼領域,如測試,架構,營運或商業分析;和Development Team members 雖然可能各自有專精的技能和領域,但仍是由Development Team 整體來當責。Development Team 的大小最理想的 Development Team 大小,是小到足夠靈活而且大到能夠完成 Sprint 內重大的工作。少於三個人的 Development Team member 之間的互動會減少,以至於只能提升小部分的生產力。小一點的 Development Team 可能會在 Sprint 中遇到技能的限制,使得Development Team 無法交付潛在可發佈的產品 Increment。如果成員多過九個人則會造成太多的協調。大的 Development Teams 產生太多的複雜性,而使得經驗導向的流程沒辦法那麼有效。Product Owner 和 Scrum Master 的角色並不包含在 Development Team人數中,除非他們也執行 Sprint Backlog 上的工作。Scrum MasterScrum Master 依照 Scrum 指南中的遊戲規則來負責推廣和支持 Scrum。Scrum Master 幫助每個人了解 Scrum 的理論,實務,規則和價值觀,來達成推動 Scrum。對於 Scrum Team 來說,Scrum Master 是一個僕人式的領導。Scrum Master 幫助Scrum Team 外的人了解哪些與Scrum Team 之間的互動是有幫助的,而哪些是沒有幫助的。Scrum Master 幫助每個人改變這些互動的方式,讓 Scrum Team 產生的價值能夠最大化。Scrum Master 對 Product Owner 提供的服務Scrum Master 對Product Owner 提供多方面的服務,包含:確保 Scrum Team 的每位成員都盡可能地理解目標,範圍與產品領域;找出有效管理 Product backlog 的技巧;幫助 Scrum Team 理解為什麼需要清楚簡潔的 Product Backlog items;在經驗導向的環境中理解產品規劃;確保 Product Owner 知道如何安排 Product backlog 來讓價值最大化;理解和實踐敏捷;與當需要或被要求時,引導 Scrum 活動的進行。Scrum Master 對 Development Team 提供的服務Scrum Master 對 Development Team 提供多方面的服務,包含:作為教練指導 Development Team如何自我組織和跨職能;幫助 Development Team 創造高價值的產品;移除 Development Team 在過程中的障礙;當需要或被要求時,引導 Scrum 活動的進行;與在組織環境還沒有完全採用與理解 Scrum 的情況下,作為教練指導 Development Team。Scrum Master 對組織提供的服務Scrum Master 對組織提供多方面的服務,包含:帶領和作為教練指導組織來採用 Scrum;規劃 Scrum 在組織內的實施;幫助員工和利害關係人理解及制定 Scrum 與經驗導向的產品開發;造成改變來增加 Scrum Team 的生產力;與其他 Scrum Master 一起合作來加強組織內 Scrum 應用的有效性。Scrum 的活動Scrum 規定了幾項活動來創造規律性,以此來減少其它 Scrum 未定義的會議。這些活動都是有時間盒限制的,也就是在某個時間長度內必須要完成。當 Sprint 開始,Sprint 的長度就固定下來了,不可以縮短或是延長。剩下的活動在達成其目的後就可以結束了,以確保在過程中只使用了適當的時間而不會造成流程中的浪費。Sprint 本身包含了其他的活動,除了 Sprint 本身之外,每次活動都是用來檢視與調適某些事情的正式機會,這些活動都是特別設計來促成嚴格的透明性與檢驗性。遺漏其中的任何一種活動可能導致透明性降低,檢視和調適的機會變少。SprintScrum 的核心是 Sprint,Sprint 是一個月或更短的時間盒。在 Sprint 內,會產出「完成」的,可用的,潛在可發佈的產品 Increment。Sprint 長度在整個開發過程中都是固定的,前一個 Sprint 結束後,下一個新的 Sprint 立刻接著開始。Sprint 包括了 Sprint Planning,Daily Scrums,開發工作,Sprint Review 與 Sprint Retrospective。在 Sprint 過程中:不可以發生會危及 Sprint 目標的改變;對於品質的目標不可以降低;與隨著獲得了更多關於產品的細節,Product Owner 與 Development Team 之間對於範圍內要做的事可以加以澄清與重新溝通。每個 Sprint 可視為一個不超過一個月的專案,如同其他專案一般,Sprint 是用來完成某些事情的。每個 Sprint 有著要打造些什麼的目標,而由一份設計和有彈性的計畫來引導其打造的過程,工作與最後的產品 Increment。Sprint 被限制在一個月內,當 Sprint 時間拉的太長時,現在正在打造的東西的定義可能會發生改變,而其複雜性也許會增加,導致風險上升,Sprint 藉由至少一個月一次的檢視與調適 Sprint 目標進度來達成可預期性,也因此,Sprint 便可將成本風險限制在一個月內。取消 SprintSprint 可在時間盒限制結束前取消,但只有 Product Owner 有取消 Sprint 的權力,雖然Product Owner 的這個決定可能是來自於利害關係人,Development Team 或是 Scrum Master 的影響。當 Sprint 目標已經變得過時,不重要的時候,就可以取消 Sprint,這可能是因為公司改變了方向或是因為市場或技術上的改變。一般而言,如果當下的情況已經變得不合理,那就應該取消 Sprint,但因為 Sprint 的時間很短,取消通常是不太合理的事情。當 Sprint 被取消時,會檢視已經「完成」的 Product Backlog items,如果有某部分的工作已經是潛在可發佈了,Product Owner 一般會接受這些成果。而尚未完成的 Product Backlog items 會被重新估計,並放回 Product backlog 內,花在這些尚未完成的 Product Backlog 上的工作價值會流失得很快,所以需要經常不斷的重新估計來反映。取消 Sprint 會消耗資源,因為要在新的 Sprint Planning 把每個人集合起來,重新開始新的 Sprint,Sprint 的取消會對 Scrum Team 造成重大傷害,所以並不常發生。Sprint PlanningSprint 內要做的事會在 Sprint Planning 中來訂定。工作計劃是由整個 Scrum Team 協同合作來制定的。Sprint Planning 是有時間盒限制的,以一個月的 Sprint 來説,Sprint Planning 最多為八小時。對於少於一個月的 Sprint,這個會議所需的時間更短。Scrum Master 確保這個會議活動的發生,以及出席人員了解這個會議的目的。並且教導 Scrum Team 在時間盒限制內完成此會議。Sprint Planning 回答以下問題:這次 Sprint 可以發佈什麼樣的 Increment?如何做才能夠達成 Increment?第一個討論題目:這次 Sprint 能做出什麼?Development Team 預測在這次Sprint內能開發出什麼功能。Product Owner 討論這次 Sprint 所應該達成的目標,以及完成哪些 Product Backlog items 可以達成這個目標。整個 Scrum Team 協同合作來了解 Sprint 要做的工作。這個會議的輸入包含: Product backlog ,最近的 Increment,在 Sprint 內 Development Team的產能預測,以及 Development Team 的過去表現。從 Product backlog 之中要選出那些項目完全取決於 Development Team。只有 Development Team 可以評估即將到來的 Sprint 所能達成的事情。在 Sprint Planning 中 Scrum Team 同時草擬本次的 Sprint 目標。Sprint 目標經由實作Product Backlog 來達成,同時指引 Development Team 知道為何要做這次的 Increment。第二個討論題目:如何完成所選的工作?在設定 Sprint 目標與選出 Product Backlog Items 之後,Development Team 決定如何在這次 Sprint 內,建造這個功能來做出一個「完成」的產品 Increment。Sprint Backlog 指的是:這次 Sprint 所選的 Product Backlog items 加上如何交付它們的計劃。Development Team 通常從系統的設計開始,到找出那些工作可以將 Product backlog 轉換成一個可運作的產品 Increment。工作通常有不同的大小,或不同的預估工作量。然而,在 Sprint Planning 中,Development Team 只預測他們在本次 Sprint 要完成的工作量即可。在 Sprint Planning 結束之際,Development Team 應該已經規劃出在 Sprint 的前幾天內所要做的工作,通常以一天或更少為一個單位。不管是在 Sprint 計劃會議中以及在Sprint 期間內,Development Team 自我組織的來承擔 Sprint Backlog 的工作。Product Owner 能夠幫助釐清所選定的 Product Backlog items 以及做出折衷。如果 Development Team 發現 Product Backlog 的工作內容太多或太少,他們可以與 Product Owner 重新商討所選的 Product Backlog items。Development Team 也可以邀請在技術領域或者其它領域的專家一起來參加會議提供建議。在 Sprint Planning 結束之際,Development Team 應該能夠解釋給 Product Owner 以及 Scrum Master,他們要如何自我組織來完成 Sprint 目標以及開發出預定的 Increment。Sprint 目標Sprint 目標是實作 Product backlog 過程中所必須達到的目的。它指引 Development Team 爲什麼要做這個 Increment。Sprint 目標是在 Sprint Planning 中產生的。對於在 Sprint 內要實作的功能,Sprint 目標提供了 Development Team 要實作哪些功能的彈性。這些被選定的 Product Backlog items 提供一個連貫的功能,而這個功能即可成為 Sprint 目標。Sprint 目標也可以是任何有連貫性的工作,這些工作讓 Development Team 一起合作,而不是讓他們各自做各自的。當 Development Team 工作時會牢記 Sprint 目標。Development Team 會實作出需要的功能和工藝來達到 Sprint 目標。如果要做的事情和 Development Team 預期的不同,他們會跟Product Owner 協同合作來溝通商量本次 Sprint Backlog 之範圍。Daily ScrumDaily Scrum 是一個針對 Development Team 的活動,其時間盒限制是 15 分鐘,此會議在 Sprint 期間內每日召開。在這個會議裡,Development Team 會規劃未來 24 小時的工作。透過檢視前次 Daily Scrum 後的工作及展望接下來的Sprint工作,將會逐步優化團隊協同合作和表現。Daily Scrum 在同一時間與地點舉行來降低其複雜性。 Development Team 藉由 Daily Scrum 來檢視達成 Sprint 目標的進度,以及檢視所完成的Sprint Backlog 進度的趨勢。Daily Scrum 優化了 Development Team 達到 Sprint 目標的可能性。每一天,Development Team 都應該理解如何以一個自我組織的團隊來一起完成Sprint 目標,並在 Sprint 結束時創造出符合預期的 Increment。 會議的架構由 Development Team決定,只要聚焦在達成 Sprint 目標的進度上,都可以用不同的方式進行。 一些 Development Team 會使用提出問題的方式,而有一些則會以討論的方式進行。以下是一個可以使用的範例:我昨天做了什麼事來幫助 Development Team 達到 Sprint 目標?我今天要做什麼事來幫助 Development Team 達到 Sprint 目標?我是否有察覺到任何障礙使得我或者 Development Team 無法達到 Sprint 目標?Development Team 或團隊成員經常在 Daily Scrum 後再立即會面,以便進行詳細的討論,調適或重新規劃 Sprint 的其餘工作。 Scrum Master 確保 Development Team 有進行 Daily Scrum,但 Development Team 要負責召開此會議。 而 Scrum Master 要教導 Development Team 將 Daily Scrum 保持在時間盒限制 15 分鐘內完成。 Daily Scrum 是 Development Team 的內部會議。 如果有其他人在場,Scrum Master 要確保他們不會打擾到會議的進行。 Daily Scrums 改善溝通品質,淘汰其他會議,發現並移除開發上的障礙,突顯及促進快速決策,還有提升 Development Team 的知識水平。 這是一個用來做為檢視和調適的重要關鍵會議。Sprint ReviewSprint Review 是在 Sprint 結束時舉行,目的是檢視 Increment以及在必要時調適 Product Backlog。在 Sprint Review 中,Scrum Team 和利害關係人一起協同合作檢視在 Sprint 中所完成的事項。依照這些事項和在 Sprint 過程中 Product Backlog 的變動,參與者一起協同合作討論接下來能做完哪些最有價值的事情。這是一個正式但輕鬆的會議,並不是一個進度回報的會議,關於 Increment 的展示是為了引發意見的反饋和提升協同合作。 對於為期一個月的 Sprint 來説,這是一個最多四個小時的會議。 在長度更短的 Sprint,通常所需的時間更短。Scrum Master 確保這個會議活動的發生,以及出席人員了解這個會議的目的。Scrum Master 教導參與的每個人如何在時間盒限制內完成會議。 Sprint Review 包含以下要件:參與者包含 Scrum Team 和 Product Owner 邀請的主要利害關係人;Product Owner 解釋哪些 Product Backlog items 已經「完成」,與哪些尚未「完成」;Development Team 討論在 Sprint 中進行順利的事項,遇到那些問題與及這些問題如何被解決;Development Team 展示已「完成」的工作並回答關於 Increment 的問題;Product Owner 討論目前的 Product backlog 的現況,他/她(視情況而定)根據到目前為止的進度來預測可能的的交付日期;整個團體協同合作來決定下一步要做什麼,所以 Sprint Review 提供了有價值的資訊給接下來的 Sprint Planning 當作輸入;檢視市場或潛在的產品使用情況是否改變了接下來最有價值的下一步;與檢視接下來期待會發布的產品功能的時間,預算,潛力,和市場。 Sprint Review 的結果,是一個修正過的 Product backlog ,在清單中定義了在下個 Sprint 可能會做的Product Backlog items。 Product backlog 亦可以調整來因應新的機會。Sprint RetrospectiveSprint Retrospective 提供 Scrum Team 一個自我檢視的機會,並建立一個改進計劃以便在下一個 Sprint 中落實。 Sprint Retrospective 召開在 Sprint Review 之後,下一個 Sprint Planning 之前。對於為期一個月的 Sprint 來説,這是一個最多三個小時的會議。 在長度更短的 Sprint,通常所需的時間更短。 Scrum Master 確保這個會議活動的發生,以及出席人員了解這個會議的目的 Scrum Master 確保這個會議是正向積極並有成效的。 Scrum Master 教導所有人在時間盒限制內完成會議。 Scrum Master 以團隊成員的身分來參與這個會議,因為他對 Scrum 的流程當責。Sprint Retrospective 的目的是:檢視上次 Sprint 內關於人員,關係,流程和工具的情況;找出並加以排序做的很好的重要事項,及具有改善潛力的事項;同時,制定一個計劃來落實如何改善 Scrum Team 的工作方法。Scrum Master 鼓勵 Scrum Team 在 Scrum 流程框架內改善其開發流程和實務,使其在下一個 Sprint 的工作中能更有效能及愉快。 在每個 Sprint Retrospective 中,Scrum Team 會規劃各種方法來提升產品的品質,在恰當且不與產品或組織標準相衝突為前提下,改善工作流程或調整「完成」之定義。在 Sprint Retrospective 結束之際,Scrum Team 應該已經確定了在下一個 Sprint 中要實施改善的地方。 在下一個 Sprint 中執行這些改善,即是 Scrum Team 在自我檢驗後的調適。雖然改善可能在任何時間點落實,但 Sprint Retrospective 提供了一個正式的機會來專注在檢視與調適上。Scrum 產出物Scrum 的產出物代表了工作或價值,用以提供透明化以及檢視和調適的機會。 Scrum 所定義的產出物是專門設計用於讓關鍵資訊有最大的透明性,以便每個人對該產出物有相同的理解。Product BacklogProduct Backlog 是產品所有已知需求的排序表。它是對產品進行任何更改的唯一需求來源。Product Owner 對 Product backlog 負責,包含其內容,可取得性和排序。Product backlog 永遠沒有完成的一天。早期的開發僅排定了最初已知和最被理解的需求。 Product backlog 隨著產品和使用環境的演變而演化。 Product backlog 是動態的;它不斷地變化來找出什麼對產品而言是恰當的,有競爭力以及有用的。只要產品存在的一天,它的 Product backlog 也會同時存在。Product backlog 列出了所有特性,功能,需求,改善功能和修補程式,這些事情構成了對未來要發布的產品的更新。Product Backlog items 的屬性包括了其描述,順序,估計和價值。Product Backlog items 通常包括測試描述,用來證明「完成」的完整性。隨著產品的使用和獲得價值,以及市場提供的反饋, Product backlog 將成為更大更詳盡的列表。 需求永遠不會停止改變,所以 Product backlog 就如同一個活的產出物。商業需求,市場狀況或技術的變化可能都會造成 Product backlog 的變動。數個 Scrum Teams 通常會一起參與對同一個產品的開發。 一個 Product backlog 便被用於描述該產品即將進行的工作,並採用 Product Backlog 的某一種屬性來把這些事項分類。 Product backlog refinement,是向 Product backlog 中的事項添加詳細資訊,估算大小和排序的動作。這是一個持續的過程,由 Product Owner 和 Development Team 就 Product Backlog items 的細節進行協同合作。在 Product backlog 精煉的過程中,事項會被進行審查和修訂。Scrum Team 決定如何以及何時來完成精煉。精煉所花的時間通常不超過Development Team 百分之十的產能。 然而,Product Backlog items 可以隨時由Product Owner 或在 Product Owner 的斟酌下來做更新。 較高排序的 Product Backlog items 比起較低的 Product Backlog items,通常比較清楚,同時包含更多細節。因為比較明確以及更多細節,可以讓預估更精準;而排序較後的 Product Backlog items,細節會越少。Development team 會在下一個 Sprint 開發的 Product Backlog items 會先被精煉,使得這些事項都可以合理的在 Sprint 時間盒期限內「完成」。「備妥」的 Product Backlog 可以在 Sprint Planning 中被挑選出來,而能夠 Development Team 在下一個 Sprint 內「完成」。 Product Backlog items 的透明性通常要經過上述的精煉化活動來獲得。 Development Team 負責所有的估計。Product Owner 也許可以經由幫助 Development Team 了解以及選擇取捨來影響他們,然而還是要由實際做事的人來決定最終的預估。監測達成目標的進度 在任何時候,用來達成目標的所有剩餘工作量都能夠被加總。Product Owner 至少在每次的 Sprint Reviews 中追蹤剩餘的工作量。Product Owner 將這次的剩餘工作量與之前做比較,進而評估預定的工作進度,是否能在期望時間內達成目標。這些資訊對所有的利害關係人都是透明公開的。 可以用各種不同關於趨勢走向的實務來預測進度,譬如:燃盡圖,燃起圖或累積流量圖。這些工具被證實是有用的,然而它們並不能用來取代經驗主義的重要性。在錯綜複雜的環境中,會發生什麼事是未知的。已經發生的事情,才能用來當做前瞻的決策的參考依據。Sprint BacklogSprint Backlog 是一組在這次 Sprint 要執行的 Product Backlog items 加上如何交付產品Increment 和達到 Sprint 目標的計劃。 Sprint Backlog 是 Development Team 對下一個Increment 中所需要的功能以及將該功能轉換到「完成」Increment 所需工作的預測。Sprint Backlog 讓 Development Team 識別出所有用來完成 Sprint 目標的必要工作。為了確保持續改善,它包含了至少一個在前次Sprint Retrospective 中優先級高的流程改進。 Sprint Backlog 是一個具有足夠細節的計劃,使得在 Daily Scrum 中可以了解正在發生的改變。 Development Team 在整個 Sprint 期間都會去修改 Sprint Backlog,使得 Sprint Backlog在 Sprint 期間裡慢慢變化而逐漸成形。 這樣的逐漸成形會隨著 Development Team 實作Sprint Backlog 的過程來發生,加上過程中學習而得到更多如何完成 Sprint 目標。 當需要有新的工作時,Development Team 便將其加到 Sprint Backlog 內。 隨著工作的進展或完成,團隊會去更新預估的剩餘工作量。當計劃內的某些部份被認定是不需要的,這些部分就會被移除。只有 Development Team 才能在 Sprint 期間內更改 Sprint Backlog。 Sprint Backlog 是 Development Team 在 Sprint 內計畫完成的工作,是一個可視性高且即時的工作畫面,且只屬於 Development Team 所擁有。監督 Sprint 的進度在 Sprint 的任何時間點都可以加總在 Sprint Backlog 內剩餘的總工作量。 Development Team 至少在 Daily Scrum 追蹤剩餘工作的總和,以預測達成本次 Sprint 目標的可能性。Development Team 可以藉由追蹤 Sprint 的剩餘工作來管理本身的進度。Increment Increment 是指在 Sprint 期間內完成的所有 Product Backlog items,以及所有先前 Sprint Increment 的價值總和。在 Sprint 的最後,新的 Increment 必須是「完成」的,這意味著它必須是可用的狀態,並符合 Scrum Team 對於「完成」之定義。在 Sprint 結束時,Increment 是一種可檢視,完成的工作實體,並可支持經驗主義。向願景或目標邁出更前進的一步。 無論 Product Owner 是否決定將其發佈,Increment 都必須是處於可用的狀態。產出物透明性Scrum 建立在透明性上,基於對產出物的理解做出把價值最佳化和控管風險的決策。在產出物完全透明的情況下,這些決定才會有可靠的基礎。 而當產出物沒有達到完全透明,可能會做出有瑕疵的決定,進而減低了價值,增加了風險。Scrum Master 必須與 Product Owner,Development Team,和其它相關人員一起努力來了解產出物是否完全透明。當不是完全透明時 Scrum Master 必須幫助所有人應用最合適的作法。Scrum Master 可以透過檢視產出物,對模式的感知,仔細傾聽周圍發生的對話,以及檢視預期和實際結果之間的差異,來發現不完整的透明性。 Scrum Master 的工作是與 Scrum Team 和組織合作來提高產出物的透明性。 這項工作通常涉及學習,使人信服和改變。 透明性不會在一夜之間發生,然而它是一條道路。「完成」之定義當一個 Product Backlog item 或者 Increment 被描述為「完成」時,每個人都必須了解什麼是「完成」之定義。 雖然這會隨著 Scrum Team 的不同而有很大的差異,但成員們必須對什麼叫做工作完成有共識,如此才能確保透明性。 這就是 Scrum Team 對「完成」之定義,並且用它來評估產品 Increment 上的工作是否完成。 同樣的定義用來指導 Development Team,讓團隊知道在 Sprint Planning 中可以選擇多少 Product Backlog items。 每一個 Sprint 的目的是交付潛在可發佈的功能 Increment,而這些功能符合 Scrum Team 目前對「完成」之定義。 Development Team 在每個 Sprint 交付產品功能的 Increment。 這個 Increment 是可用的,因此 Product Owner 可以選擇立即發佈它。 如果「完成」之定義對 Increment 來說是開發組織的慣例,標準或指導方針的一部分,那麼所有的 Scrum Teams 都必須要遵守。 如果 Increment的「完成」不是開發組織的慣例,那麼 Development Team 就必須對這個產品訂下一個合適的「完成」之定義。如果有多個 Scrum Teams 在同一個系統或產品發佈上工作,那麼所有的 Development Team 就必須一起訂下一致的「完成」之定義。 每個 Increment 都是遞加於先前的 Increment,並經過徹底地測試以確保所有 Increment 都能一起運作。 隨著 Scrum Teams 的成熟,可以被預期的是,他們對「完成」之定義將擴大到包含更多更嚴謹的標準以達到更高的品質。當使用了新的定義,可能會發現一些之前已「完成」的Increment需要更多的工作。 任何一個產品或系統都應該有一個「完成」之定義,作為工作的標準。結語經由此指南提供 Scrum 知識,Scrum 同時也是免費的。Scrum 的角色,活動,產出物和規則都是不能改變的,雖然實施部分的 Scrum 是可能的,但結果並不是 Scrum。Scrum 只有在完整的時候才會存在,也才能有效的成為其他技巧,方法論,和實務發揮的運作舞臺。 ...

January 4, 2019 · 7 min · jiezi

Scrum 概述

Scrum是产品开发和团队组织的迭代和增量过程。借助Scrum框架,可以更快,更高质量地完成任务。这是可能的,因为团队的高自我激励,自己选择如何执行任务。客户需求将被迭代优先级并快速实现Scrum - 敏捷框架 (Agile Framework)Scrum是一个框架,支持迭代和增量产品开发,允许在正确的时间完成工作,最大化交付的价值。通过自组织团队,任务执行速度更快,质量更高。实现了高水平的自我激励,这也是Scrum允许团队更快地实现更高生产力的原因。根据业务价值不断优先考虑客户需求,并定期将其集成到产品中,使客户能够及时向团队提供反馈,从而按时提高产品质量。Scrum项目主要从对待开发的产品或系统的愿景开始。一开始,这个愿景可能含糊不清,并且肯定会在市场问题而不是技术术语上说明。随着项目的进展,它将变得更加清晰。出于这一愿景,产品负责人正在撰写产品Backlog。在迭代开始时(Sprint),产品负责人将优先级产品Backlog呈现给团队,团队选择它认为可以在Sprint结束时变为可发送功能的增量。这样做,就会创建Sprint Backlog。之后,团队将独自开发他们所选择的功能。该团队现在更深入地了解需求,考虑可用技术,并评估自己的技能和能力。然后它共同确定如何构建功能,每天修改其方法以找出新的复杂性或困难。团队确定需要做什么,并选择最佳方式。这一创作过程是Scrum生产力的核心。在Sprint结束时,团队向产品负责人展示了功能的增加,因此他可以一方检查功能,另一方面及时调整项目。Scrum角色 (Scrum Roles)Scrum - 3个角色:产品拥有者团队Scrum Master管理项目的所有职责分为这三个角色。产品拥有者 (Product Owner)产品负责人代表与项目有利害关系的每个人的利益(利益相关者),他负责最终产品。他从利益相关者那里获得产品需求,创建产品Backlog(需求细分为用户故事),负责投资回报(ROI),并且他正在制定发布计划。产品负责人使用业务价值点对产品Backlog进行优先级排序,以确保首先开发最有价值的功能。 企业想要的和团队可以做的事情之间的紧张关系是什么使Scrum成为高质量生产的有效工具。团队 (Team)该团队计算出如何将产品Backlog转换为Sprint内的功能增量。每个团队成员共同负责每次迭代和整个项目的成功。该小组负责/:软件质量用户故事的技术实施交付功能软件增量整理自己Scrum MasterScrum Master负责Scrum流程。他确保每个人都遵守规则。他还消除了球队的障碍。Scrum Master不属于团队。猪和鸡 - 承诺还是参与?所描述的三个角色已经致力于该项目。其他人可能只是对项目感兴趣(参与),但他们并没有陷入困境。Scrum明确分开了这两个群体。承诺:负责项目的角色有权为其成功做必要的事情。参与:对直接成功不负责任的其他利益相关者不能不必要地进行干预。应该总是清楚谁是负责投资回报率的人,谁与ROI有利害关系但不负责任。Scrum - 笑话一只鸡和一只猪走在路上。鸡对猪说:“你想和我一起开餐馆吗?” 猪仔细考虑了这个问题并回答说:“是的,我想那样。你想叫什么餐馆?” 鸡回答说:“火腿和鸡蛋!” 猪停下来,停下来回答:“我想,我不想和你一起开餐馆。我会承诺,但你只会参与其中。”Scrum工件Scrum - 3个主要的工件:产品积压 (Product Backlog)Burndown图表Sprint积压 (Sprint Backlog)产品积压产品的要求列在产品Backlog中。它是一个始终在变化,动态优先排序的业务价值排序要求列表。需求由PO分解为用户故事。Burndown图表Burndown图表显示了每个Sprint剩余的工作量。这是一种非常有用的方法,可视化任何时间点剩余工作与团队进度之间的相关性。它通过使用Burndown图表检查他们在规划方面的进展,并根据需要进行调整。Sprint积压 (backlog)Sprint Backlog包含团队分解为任务的当前Sprint的所有已提交用户故事。Sprint Backlog上的所有项目都应该进行开发,测试,记录和整合,以充分履行承诺。潜在的可交付产品功能 (Potential Shippable Product)Scrum要求团队在每个Sprint中构建产品功能的增量。此增量必须是可以发送的,因为产品负责人可能会选择立即实现该功能。这要求增量为:彻底测试过结构良好的写得很好的代码记录功能的用户操作新的管理职责三个主要角色 - 产品负责人,Scrum Master和团队 - 是管理角色。他们都是“猪”,因为他们在项目中承诺。组织中的所有其他管理者都是鸡,他们可能对项目感兴趣并且可能对其成功有浓厚的兴趣,但他们必须通过猪来解决问题。他们只是参与其中,因此他们对项目的执行或进展没有直接的权力。Scrum可以大大简化与项目相关的问责制和权限问题,但Scrum管理角色很难发挥作用。管理复杂的工作绝非易事,但定期使用Scrum实践可以使项目的进度,问题和社会学变得明显。Scrum - 易于使用?Scrum听起来很简单,在您阅读完这篇简短的文档之后,您可能会觉得可以毫无问题地开始使用。那是错的!与任何其他方法,流程或框架一样,scrum可能会对您的工作方式产生深刻的变化,因此请做好准备:-)Scrum活动什么是Scrum活动?什么是Scrum Ceremonies?什么是产品Backlog修饰?每日Scrum中的3个重要问题是什么?Scrum Sprint循环8个步骤什么是Scrum中的Sprint?Scrum的心跳 - 每日站立每日Scrum会议 - 快速指南为什么在Scrum中固定长度冲刺?什么是Scrum发布计划?什么是Sprint计划?什么是Sprint评论?什么是Scrum的Sprint回顾会议?什么是产品Backlog改进?什么是Scrum中的持续集成/交付/部署?什么是Scrum中的时间盒事件?什么是Scrum中的Spike?什么是敏捷计划扑克?

January 3, 2019 · 1 min · jiezi

什么是敏捷软件开发?

敏捷是一个术语,用于描述软件开发的方法,强调增量交付,团队协作,持续计划和持续学习,而不是试图在接近结束时立即交付。敏捷专注于保持流程的精益,并创建最小的可行产品(MVP),在最终结果出现之前经历多次迭代。不断收集和实施反馈,总而言之,这是一个更加动态的过程,每个人都在朝着一个目标努力。Scrum和其他领先的敏捷方法敏捷是一种思维方式,它是一套价值观和原则。敏捷是一种思考和行动的方式。敏捷就是短周期,迭代和增量交付,快速失败,获得反馈,及早向客户提供商业价值,关于人员,协作和互动。敏捷是一种关于透明度,检查和适应的心态。但是,敏捷不包含任何角色,事件或工件。这是一种心态。例如,Scrum是敏捷伞下广泛使用的框架之一,它可以帮助你变得更敏捷,但敏捷运动中有更多的框架,如看板,XP,Crystal等等,如图所示下面:ScrumScrum是一个框架,人们可以在其中解决复杂的自适应问题,同时高效且创造性地提供具有最高价值的产品。它用于管理软件项目和产品或应用程序开发。它的重点是适应性产品开发战略,其中跨职能团队作为一个单元在2-4周内达成共同目标(Sprint)。它由一系列价值,文物,角色,仪式,规则和最佳实践组成。Lean (精益)精益起源于丰田生产系统(TPS),它在20世纪50年代,60年代及以后彻底改变了实物商品的生产。精益保持其在制造业中的地位,但也在知识工作中找到了新的应用,帮助所有行业的企业消除浪费,改进流程并促进创新。软件开发是精益方法的自然应用,因为与制造业一样,它通常遵循一个确定的过程,具有一定的接受条件,并导致有形价值的传递。指导精益方法所有实践的关键概念,我们称之为精益支柱。他们是:连续的提高尊重人轻量级领导看板 (Kanban)看板是一种高度可视化的工作流管理方法,在精益团队中很受欢迎。事实上,83%的精益生产团队使用看板来可视化并积极管理产品的创建,重点是持续交付,同时不会使开发团队负担过重。与Scrum一样,看板是一个旨在帮助团队更有效地协同工作的流程。看板基于3个基本原则:可视化您今天要做的事情(工作流程):查看彼此上下文中的所有项目可以提供非常丰富的信息限制正在进行的工作量(WIP):这有助于平衡基于流的方法,因此团队无法启动并立即承诺过多的工作增强流程:当某些内容完成后,积压中的下一个最高优先级项目将被激活看板通过定义最佳的团队工作流程,促进持续协作并鼓励积极,持续的学习和改进。动态系统开发方法(DSDM)DSDM是一个由八个原则组成的框架,包括生命周期和产品,角色和职责以及几种最佳实践技术。这些支撑和支持的理念是尽早提供具有战略意义的商业利益,从而为组织提供最佳的投资回报率(ROI)。DSDM是一种优先考虑计划和质量而非功能的方法,它在一开始就修复了成本,质量和时间,并使用MoSCoW优先级排序方法,将项目分解为四种不同类型的要求:必须有(Must have)应该有(Should have)可以有(Could have)不会有(Won’t have)支持DSDM Atern的原则有八个[13]。这些原则指导团队必须采取的态度和他们必须采取的思维方式,以始终如一地提供。专注于业务需求按时交货合作绝不妥协质量从坚实的基础逐步建立起来迭代开发持续清晰地沟通表现出控制力极限编程最初由Kent Beck描述的极限编程(XP)已经成为最受欢迎和最有争议的敏捷方法之一。XP是一种快速,持续地提供高质量软件的规范方法。它旨在提高面对不断变化的客户需求的软件质量和响应能力。它促进了高客户参与度,快速反馈循环,持续测试,持续规划以及密切的团队合作,以非常频繁的间隔(通常每1-3周)提供工作软件。该方法的名称来源于传统软件工程实践的有益元素被带到“极端”水平的想法。例如,代码审查被认为是一种有益的做法。极端情况下,可以通过结对编程的实践不断检查代码。最初的XP方法基于四个简单的价值观 - 简单,沟通,反馈和勇气。它还有12个支持实践:规划游戏 (Planning Game)小版本 (Small Releases)客户验收测试 (Customer Acceptance Tests)简单的设计 (Simple Design)配对编程 (Pair Programming)测试驱动开发 (Test-Driven Development重构 (Refactoring)持续集成 (Continuous Integration)集体代码所有权 (Collective Code Ownership)编码标准 (Coding Standard)隐喻 (Metaphor)可持续发展 (Sustainable Pace)特征驱动开发(FDD)功能驱动开发(FDD)由Jeff De Luca于1997年在一家大型新加坡银行的软件开发项目中开展。它是一个迭代和增量的软件开发过程,是一种开发软件的敏捷方法。FDD将许多业界公认的最佳实践融合为一个有凝聚力的整体。这些实践是从客户端值的功能(特性)角度推动的。其主要目的是及时反复提供有形的,有效的软件。使用FDD的优势在于,由于“初期设计足够”(JEDI)的概念,它甚至可以扩展到大型团队。由于其以功能为中心的流程,它是一个很好的解决方案,可以保持对敏捷,增量和固有复杂项目的控制。它由五个基本活动组成:开发整体模型构建功能列表按功能规划按功能设计按功能构建。每个项目都有自己独特的模型,这将产生一个功能列表。最后三个活动是短迭代过程,其构建时间不超过两周。如果它需要两周以上,那么它将被分解为更小的功能。水晶 (Crystal)水晶方法是由Alistair Cockburn在20世纪90年代中期开发的一系列方法(Crystal系列)。这些方法来自Cockburn多年的学习和团队采访。Cockburn的研究表明,他采访过的团队并没有遵循正式的方法,但他们仍然提供了成功的项目。Crystal家族是Cockburn对他们所做的事情进行编目的方式,这些项目使项目成功。水晶方法主要关注:人 (people)相互作用 (Interaction)社区 (Community)技能 (Skills)人才 (Talents)通讯 (Communications)敏捷宣言“敏捷”一词是在2001年的敏捷宣言中创造的。该宣言旨在建立指导更好的软件开发方法的原则。敏捷宣言由4个重要的价值观组成。阅读敏捷宣言的方式并不是右侧的物品不再具有价值,而是敏捷运动更重视左侧的物品。那么让我们来看看敏捷宣言的第一行。这条线表明,我们重视人,他们的互动,沟通和协作,而不是拥有各种广泛的流程和工具。当然,流程和工具很有价值,但是,如果它们真正支持人们一起工作并提供优质产品,那么它们就更有价值。我们现在在很多组织中看到的是,流程和工具本身就是目标。从敏捷的角度来看,我们对此有不同的看法。流程和工具应该支持人们共同合作并为客户创造价值。敏捷宣言原则作为敏捷宣言的补充,敏捷联盟还定义了一套12项基本原则,除了敏捷宣言之外,还提供了指导和更详细的解释:我们的首要任务是通过早期和持续交付有价值的软件来满足客户。欢迎不断变化的要求,甚至是开发后期。敏捷流程利用变化来实现客户的竞争优势。经常提供工作软件,从几周到几个月,优先考虑更短的时间尺度。业务人员和开发人员必须在整个项目中每天一起工作。围绕有动力的个人建立项目。为他们提供所需的环境和支持,并相信他们能够完成工作。向开发团队内部和内部传达信息的最有效和最有效的方法是面对面交谈。工作软件是进步的主要衡量标准。敏捷过程促进可持续发展。赞助商,开发者和用户应该能够无限期地保持稳定的步伐。持续关注技术卓越和良好的设计可提高灵活性。简单性 - 最大化未完成工作量的艺术 - 至关重要。最好的架构,要求和设计来自自组织团队。团队定期反思如何变得更有效,然后相应地调整和调整其行为。摘要敏捷开发是软件开发行业的一个流行词,它是管理软件开发项目的另一种方式。它不是特定的软件开发方法,而是基于敏捷宣言中表达的价值观和原则的一套方法和实践的总称。解决方案通过自组织,跨职能团队之间的协作发展,利用适合其背景的实践。基本的Scrum閱讀Scrum和自组织团队 (Scrum and Self-Organizing Team)敏捷和Scrum - 有什么区别?在Scrum Sprint中发布的频率是如何确定的?通过3个步骤建立自组织团队The Best Free Scrum Learning Resources, Guides and Articles为什么敏捷开发是您项目的更好选择?为什么Scrum是 - 快速失败技术?8经常被误解的Scrum Master角色Scrum Events - 初学者阅读文章Scrum在3分钟内完成Scrum工件什么是Scrum工件?完成与接受标准的定义Scrum中Ready的定义是什么?如何写短距离目标?如何使用MoSCoW方法确定产品积压的优先级如何使用100点方法确定产品待办事项的优先级? ...

December 31, 2018 · 1 min · jiezi

什么是Scrum的三大支柱?

SCRUM使用经验方法(或有时称为经验主义)以适应客户不断变化的需求。经验主义是根据实际经历的内容做出决策的行为。经验方法意味着以事实为基础,以经验为基础,以证据为基础的方式开展工作,特别是,进展是基于对现实的观察,而不是基于大量前期要求的虚构计划。简而言之,我们可以学习和改进过去的错误和经验。Scrum支持经验过程控制的每一个实施的三大支柱是:透明度,检查和适应性,如下图所示:Scrum的三大支柱透明度Scrum中的透明度可以通过Scrum工具实现,例如产品Backlog,任务板和Burndown图表,每日站立,回顾,完成定义,Sprint评论等。这些工具用于通过跨职能团队转移工作流程。这是SCRUM的关键优势之一 - 允许关于工作和团队进度的可见性。这意味着当团队实现其目标时,负责该目标的人员可以得到认可和赞赏。检查必须经常检查Scrum工件并朝着目标前进,以检测不希望的差异。Scrum中的检查可以通过scrum活动来实现,例如:使用通用的Scrum板和其他信息来清除每个人的项目当前状态在开发史诗期间收集客户和其他利益相关者的反馈创建优先产品Backlog,并执行发布计划流程产品负责人检查和批准交付物演示和验证Sprint流程中的客户适应在敏捷世界中,我们始终拥抱和适应变化,以便我们不断改进。适应意味着我们改变不起作用的东西或者更好的作用。这意味着我们不断进行小型实验,保持正常工作,并在失败时进行改变。我们使用检查结果来决定接下来要运行的实验,例如:开发团队,每日站立仪式期间每天检查和调整。Sprint Review是另一个仪式,Scrum团队将要求所有股东提供反馈并相应调整。在Sprint Retrospective期间,Scrum团队在内部讨论问题和改进机会。将作为一个团队准备和调整新计划,以产生更多价值。摘要在Scrum中,决策是基于观察和实验而不是基于详细的前期规划。经验过程控制依赖于透明度,检查和适应性这三个主要思想。这意味着项目成果应该:向负责结果的人员了解流程的重要方面及时检查Sprint目标的进度,以检测不良差异尽快调整流程,以尽量减少任何进一步的偏差或问题总之,经验主义和三大支柱不仅对Scrum过程很重要,它们也是它的基础。这是您的团队在您创建的产品和您为团队使用的流程中实现持续改进的方式。角色,事件和工件只有在遵守基于价值的渐进式改进的情况下才能发挥作用,这些改进是通过接受频繁的反馈和接受变革而产生敏捷和Scrum基础综合Scrum指南什么是Scrum的三大支柱?什么是敏捷软件开发?Scrum在3分钟内完成什么是5个Scrum值?经典项目管理与敏捷项目管理为什么Scrum难以掌握?什么是Scrum中的速度?什么是敏捷?什么是Scrum?敏捷中的三个Amigos发展战略是什么?经验过程控制与定义过程控制如何保持Scrum的透明度?Scrum vs Waterfall vs Agile vs Lean vs Kanban什么是Scrum框架中的3355?为什么选择Scrum?Scrum如何克服我们总是面临的8个痛点?最好的免费和商业敏捷工具 - 每个Scrum团队都需要!什么是Scrum中的猪和鸡?什么是8种精益废物?

December 31, 2018 · 1 min · jiezi

Scrum综合指南

Scrum是一个项目管理框架,强调团队合作,问责制和迭代进展,以实现明确的目标。该框架从一个简单的前提开始:从可以看到或已知的东西开始。之后,跟踪进度并根据需要进行调整。Scrum的三大支柱Scrum的基础是经验主义,它指出知识来自经验,我们应该根据已知的事情做出决定。有三个支柱将Scrum结合在一起。为什么选择Scrum?Scrum一次提供功能,而瀑布只提供阶段。典型的瀑布式开发是基于阶段的顺序过程,在项目结束之前不会给出价值。Scrum将这种模式转变为每一周提供新功能,而不是专注于未来的大发布。Scrum将复杂的工作划分为简单的部分,将大型组织划分为小型团队,将影响深远的项目划分为一系列短时间的称为sprint的视野。通过迭代和渐进式构建,公司能够更快,更有效地为客户提供他们真正需要的产品和服务。使用Scrum,您可以在每个小开发周期结束时接收并整合客户反馈,这意味着您的结果将通过实际使用而非您的假设来塑造。这使得让客户和主要利益相关者密切参与和参与变得更加容易。敏捷与Scrum敏捷方法是一种有助于在SDLC过程中持续迭代开发和测试的实践。敏捷将产品分解为更小的构建。Scrum只是众多迭代和增量敏捷软件开发过程中的一个,它使我们能够专注于在最短的时间内提供业务价值。Scrum框架通常处理的是需求可能会发生变化,或者大部分时间在项目开始时都不知道。Scrum的特点是:轻量级简单易懂很难掌握Scrum的好处以下是scrum为组织,团队,产品和个人提供的好处。更好的质量:存在实现愿景或目标的项目。Scrum提供持续反馈和曝光的框架,以确保质量尽可能高。Scrum通过以下实践帮助确保质量缩短产品上市时间:Scrum已被证明能够为传统方法提供比最终客户快30%到40%的价值。提高投资回报率:缩短上市时间是Scrum项目实现更高投资回报率(ROI)的一个关键原因。由于收入和其他目标福利开始提前,早期积累意味着更高的总回报率。这是净现值(NPV)计算的基本原则。士气高级团队:与喜欢工作的快乐人士一起工作可以令人满意和有益。自我管理将通常由经理或组织做出的决策放入scrum团队成员的手中。加强团队协作:当Scrum团队负责项目和产品时,他们可以产生很好的结果。Scrum团队通过增强团队参与和沟通来协作并掌握质量和项目绩效。Scrum框架Scrum很简单。它与大量交织的强制组件相反。Scrum不是一种方法论。Scrum实现了经验主义的科学方法。Scrum用启发式方法取代了程序化的算法方法,尊重人和自组织,以处理不可预测性和解决复杂问题。下图显示了Ken Schwaber和Jeff Sutherland在他们的“30天软件”一书中描述的Scrum in Action,它将我们从规划到软件交付。Scrum流程的组成部分Scrum框架本身非常简单。它仅定义了一些通用指南,仅包含一些规则,角色,工件和事件。然而,这些组件中的每一个都很重要,用于特定目的,对于成功使用框架至关重要。Scrum Framework的主要组件是:Scrum角色:Scrum Master,Scrum产品负责人和Scrum团队工件:Sprint积压,产品积压,燃尽图,日志等……Scrum活动:Sprint计划,春季评论,每日站立,冲刺复古等……短跑下图显示了SCRUM框架的关键元素。该过程已由敏捷软件工具Scrum Process Canvas应用。Scrum角色当一个组织决定接受Scrum时,首先要了解的是Scrum角色与传统项目执行角色的不同之处。虽然Scrum中只有三个主要角色,但它们并不会自动与我们大多数人熟悉的标题保持一致。让我们从每个的简要定义开始:产品拥有者产品所有者是代表业务或用户社区的人员的scrum开发角色,负责与用户组合作以确定产品版本中的功能。产品负责人的主要职责是:制定产品和服务的方向和战略,包括短期和长期目标;提供或获取有关产品或服务的知识;了解并解释开发团队的客户需求;收集,优先排序和管理产品或服务要求;接管与产品或服务预算相关的任何责任,包括其盈利能力;确定产品或服务功能的发布日期;每天与开发团队一起回答问题并做出决定;接受或拒绝与Sprint相关的已完成功能;在每个Sprint的最后展示开发团队的主要实现;负责产品BacklogScrum大师Scrum master是敏捷开发团队的推动者。Scrum是一种方法,允许团队根据敏捷原则自我组织并快速进行更改。Scrum master管理信息交换的过程。Scrum Master的主要职责是:充当教练,帮助团队遵循Scrum价值观和实践;帮助消除障碍并保护团队免受外部干扰;促进团队与利益相关者之间的良好合作;促进团队内部的常识;保护团队免受组织干扰;Scrum团队Scrum团队(又名开发团队)由3到9人组成,他们必须满足提供产品或服务的所有技术需求。它们将由Scrum Master直接引导,但不会直接管理。他们必须是自我组织的,多才多艺的,并且负责任地完成所有必需的任务。开发团队负责从分析,设计,开发,测试到技术写作等每个sprint提供潜在的可交付产品增量。对于Scrum团队具有以下特征非常重要:团队必须是自组织的。所有团队组件必须管理自己的工作以完成已经给出的任务。在Agile Scrum中,没有团队负责人或直线经理的身影。每个人都必须做出足够的承诺来开展自己的活动,并为团队的成功做出贡献。如果一个失败,每个人都会失败。团队必须是跨职能的。所有团队成员必须拥有所有必需的知识和技能,以提供做得好并且随时可用的服务或产品。专家可用于必要的案例,但仅作为教练将知识传授给团队以实现特定差距。成为产品负责人需要企业愿景。产品负责人代表客户的声音,需要将他们的需求转化为Scrum Master和开发团队。这通常是一份全职工作。Scrum Master不是直线经理。他们帮助向开发团队提供所需的教练,并帮助消除团队面临的任何障碍。Scrum工件SCRUM工件用于帮助定义进入团队并且当前正在团队中工作的工作负载。还有更多的工件,例如,用户故事,发布积压,刻录图表等。但我们将专注于核心三:产品积压产品待办事项是用户故事的集合,其呈现产品团队所需/期望的功能。通常,产品所有者负责此列表。Sprint积压Sprint积压包含一系列可以包含在当前sprint中的故事。有关sprint积压与将项目包含在sprint中之间关系的两个要点需要注意。1)团队决定添加到sprint的内容。因此,团队负责交付这些物品的所有权和责任。2)在将项目从sprint backlog中删除并添加到sprint之前,团队必须确保他们拥有积压中所需的所有信息。通常,团队定义在添加项目之前必须存在的项目清单。产品Backlog与Sprint Backlog在冲刺积压是Scrum的冲刺过程中完成了由Scrum团队确定的任务列表。在sprint计划会议期间,团队通常以用户故事的形式选择一些产品待办事项,并确定完成每个用户故事所需的任务,如下图所示:刻录图表刻录图表是剩余工作与时间的图形表示。突出的工作(或积压工作)通常在垂直轴上,沿水平方向的时间。也就是说,这是一份杰出工作的运行图表。它可用于预测何时完成所有工作。它通常用于敏捷软件开发方法,如Scrum。但是,刻录图表可以应用于任何包含一段时间内可衡量进展的项目。杰出的工作可以用时间或故事点来表示。Scrum活动沟通是关键!SCRUM依赖于团队的所有方面并且透明地工作(Scrum支柱#1)。考虑到这种核心理念,该方法围绕一系列关键事件构建,以确保其他两个支柱:检查和调整如下表所示:事件检查适应Sprint计划产品积压(承诺回顾)(Done的定义)冲刺目标预测Sprint积压每日Scrum冲刺目标的进展Sprint积压每日计划Sprint评论产品增量产品积压(发布)市场商业条件产品积压Sprint回顾团队合作技术与工程完成的定义切实可行的改进注意:在执行每个sprint期间,Scrum中有五个主要会议,如下图所示:Sprint计划所有冲刺都从计划开始。团队需要确定并承诺将作为sprint的一部分交付哪些项目。可能的项目总是从Sprint Backlog中获取,如下图所示:这是SCRUM主人可以发光的时间。产品所有者从业务/客户的角度确定他们需要的方面,SCRUM团队,确定他们认为可以提供哪些项目,以及SCRUM主人适应所有项目并确保满足两个方面的最佳要求。每日Scrum会议一旦团队确定了他们承诺作为sprint的一部分交付的项目。该团队将举行每日站立会议。此次会议的核心目标是确保团队中的每个人(以及可能的观察员)完全了解正在完成的任务的状态和进度:他们做了什么他们今天要做什么什么阻止他们此每日更新向团队提供实例反馈并提供。这些会议意味着简短,每人不超过3分钟。注意:观察员在那里观察,SCRUM主人必须尽可能减轻外部干扰和团队干扰。Sprint评审会议在Sprint结束时举行Sprint评审/演示会议以检查增量。团队根据完成定义演示增量,重点关注Sprint目标。产品负责人审核并接受交付的增量。Sprint回顾冲刺回顾通常是冲刺中最后完成的事情。许多团队将在冲刺审查后立即执行此操作。包括Scrum Master和产品所有者在内的整个团队都应该参与其中。您可以安排scrum回顾展达一个小时,这通常是足够的。回顾展让团队有机会确定3个关键方面:应该开始做什么?什么不顺利(并再次停止做)?什么进展顺利(并且应该继续做什么?)?这种方法的目的是不断提高团队效率。积压细化会议将积压视为项目的路线图。当团队协作创建需要为项目完成构建或完成的所有事项的列表时,可以修改此列表并将其添加到整个项目中,以确保满足项目的所有必要需求。短跑在Scrum框架中,Scrum产品Backlog中实现条目所需的所有活动都在Sprint中执行(也称为“Iterations”)。短跑总是很短:通常大约2-4周。每个Sprint都遵循一个定义的过程,如下所示:如前所述,产品待办事项中的项目按优先级排序并选择sprint backlog。一个sprint只包含几个大项目,即使单个项目低估工作的影响也会对sprint产生深远的影响。而且由于较大的项目往往难以估计和理解,因此短跑失败的可能性会进一步增加。经验丰富的Scrum团队花费时间和精力将复杂和较大的项目(即用户功能或史诗)分解为较小的用户故事(或随后分解为任务或子任务)。史诗史诗捕捉了大量的作品。它本质上是一个“大型用户故事”,可以分解为许多小故事。完成史诗可能需要几次冲刺。因此,当我们将epic用于开发时,它必须被分解为更小的用户故事。在项目周期的早期,我们提出了Epics。这些是非常高级的,几乎以营销为中心的功能性要点。我们将大型故事称为“史诗”,以传达有关它们的信息。我喜欢把这与电影有关。如果我告诉你一部特定的电影是一部“动作冒险电影”,它会告诉你有关电影的一些信息。可能有一些汽车追逐,可能是一些射击,等等。同样,将一个故事称为“史诗”有时可以传达其他意义。用户故事故事是产品要求或业务案例的简要陈述。通常,故事用简单的语言表达,以帮助读者理解软件应该完成的内容。产品所有者创建故事。然后,scrum用户将故事分成一个或多个scrum任务。用户故事通常是最终用户可见的功能。用户故事遵循“我作为世界卫生组织想要做什么”的格式,以便为什么。用户故事为客户/用户提供价值。这是客户/用户的产品要求。例如“作为客户,我希望能够创建一个帐户,以便我可以看到我去年购买的商品,以帮助我明年的预算。”任务另一方面,任务更具技术性,任务通常类似于代码,设计,为此类创建测试数据,自动执行等等。这些往往是由一个人完成的事情。任务不是以用户素材格式编写的。任务更具技术性。例如“评估用户界面的角度材料设计”或“将应用程序提交到应用商店”。為初學者提供更多敏捷和Scrum文章Scrum和自组织团队 (Scrum and Self-Organizing Team)敏捷和Scrum - 有什么区别?在Scrum Sprint中发布的频率是如何确定的?通过3个步骤建立自组织团队The Best Free Scrum Learning Resources, Guides and Articles为什么敏捷开发是您项目的更好选择?为什么Scrum是 - 快速失败技术?8经常被误解的Scrum Master角色Scrum Events - 初学者阅读文章Scrum在3分钟内完成

December 31, 2018 · 1 min · jiezi

精益,敏捷,Scrum的相当不错的总结

词汇表:精益,敏捷,Scrum,Sprint,看板将Lean和Agile看作几乎相同的事情,它们基本上是处理具有很多不确定性的项目的好方法,这就是为什么成功的初创公司采用这种方法。 (有关精益,敏捷和Scrum起源的事实历史,请参阅 此处 。)Scrum和Kanban是最受欢迎的两个敏捷项目管理框架。 它们有很大的不同 - Scrum似乎更常用,纯粹的看板更少。 但实际上每个人都使用他们自己的Scrum修改版本,这是鼓励的,通常采用看板的元素(我们也这样做)。Sprint是一个Scrum术语。 这是Scrum中的迭代周期。所以: 精益≈敏捷> Scrum>冲刺为什么精益和敏捷?因为在这个不断变化的社交和数字参与世界中,我们需要更好的方式来开展业务和管理组织。精益和敏捷是现代组织功能失调的两个主要原因的解毒剂:瀑布项目管理 ,和功能层级组织结构 。瀑布与敏捷项目管理当我们想到项目管理时,我们大多数人都会想象一个规范,循序渐进的工作方法,并有良好的规划和明确的目标设定。 这基本上是瀑布项目管理。瀑布项目管理思想在我们的文化中根深蒂固。 我们的教育强调良好的准备和一步一步的审慎。 进展正在达到检查点的标记。 了解我们正在走上正轨可以让我们感到舒适和自信,同时也有助于我们的教师和领导者更轻松地监控和管理。 这是一个很好的方法。 没有瀑布,世界上许多现代奇迹都不会存在。 全球各地的企业已成功扩展瀑布。 但瀑布有其局限性:它在重复性和相对较低的不确定性项目中运行良好。现实是,世界充满了不确定性。 人类的行为很难预测。 在您正在开发尚未找到市场的产品的项目中,瀑布式项目管理是寻找适合产品市场的非常昂贵的方式。 您可以负担得起废弃和重建产品的次数有限,并且在瀑布中进行另一次产品构建迭代所需的时间会使您在竞争中处于劣势。敏捷成为解决瀑布缺点的解决方案。 对于企业来说,它是一种更快,更具成本效益且风险更低的方法,可以应对其业务的诸多不确定因素。 在这个快速数字化转型的世界中,不再仅仅是创业公司必须应对扰乱市场。 跨行业的各种规模的企业都需要更好的方法来应对变化,敏捷是一种解决方案。传统与敏捷组织结构委派工作对领导者和管理者来说是一项日常挑战。 团队之间的移交文化为追求更高层次的企业目标创造了障碍。 敏捷通过重新定义的团队合作和领导模式从根本上解决了这些组织挑战。在传统组织中,领导和管理团队负责决策 - 战略和解决问题,预计答案将来自上方。 这给领导者“做出正确决策”带来了巨大风险。 再一次,在这个快速发展的数字和社交时代,对任何人而言,很难一气呵成。 认识到解决问题是一个发现过程,敏捷鼓励假设建立和实验作为一个整体组织练习。 简单地说,更多的眼睛和集体智慧增加了“把事情做对”的机会。精益与敏捷的精神精益和敏捷是方法,而不是方法。 即使是敏捷的实施框架Scrum,也拒绝称之为方法论。 这是因为没有一种严格的方法可以解决所有不确定性问题。 相反,你遵循某些共同的原则,或者可以概括为精益和敏捷的精神,并且大量适应:坚持不懈地追求产品市场契合度 (=为客户提供真正的价值)作为整体组织的努力。列表项目建立,衡量,学习 :接受不确定性 - 这就是为什么我们假设,测试和验证我们是否越来越接近客户真正想要的东西。 在它被钉住之前,以小增量进行并继续迭代。了解客户,而不仅仅是销售和营销或领导团队,这是每个人的工作。 认为客户不是别人的工作 - 这也是你的工作。 因此,您被允许并被鼓励与客户一起进行构建测量 - 学习实验(即使您不是直接面向客户),领导团队将作为仆人领导者,促进系统化的协作工作框架。在Lean&Agile中,没有人会受到指责。 如果出现故障,我们不会责怪某人,而是检查产生故障并修复故障的系统。实施Scrum视觉层次结构首先,您的企业愿景需要以“连接”的方式与组织中的每个人共享:您的员工所做的一切,一直到个人工作的任务级别,需要连接到愿景。这比人们想象的要难。 领导能够分辨和销售愿景,但这并不一定能让每个人都参与其中。 视觉分享练习实际上是与您的员工一起进行的视觉形成练习。输入Scrum:Epic,Story,Task是Scrum术语,可帮助人们思考产品或项目中需要构建或完成的所有关键事项,以实现共享愿景。 根据设计,Scrum通过沿着视觉层次结构进行“Backlog”创建练习,将每个人放在同一页面上。运行SprintScrum是一个由时间限制的项目管理框架,由Sprint组成,根据团队工作的特点,您可以设置一个固定的工作周期,通常在一到四周之间。 (据您所知,另一个流行的敏捷项目管理框架看板是一种“容量受限”的方法。)我们的想法是以小增量和快速迭代的方式完成工作,特别强调审查工作以帮助团队实现目标。 假设构建和重复实验是Scrum不可或缺的一部分,因为大多数项目都面临不确定性,而发现是关键(营销是一个很好的例子 - 产品市场适合自己是一个发现过程)。1.积压 (backlog)想想可能包含在产品中或需要在项目中完成的所有事情。 踏上用户旅程的道路:用户故事是将客户需求和需求置于背景中的一种很好的方式。用户故事:作为[用户],我想[什么],所以[值]。2. Sprint计划 (Sprint Planning)优先考虑和估计Backlog,决定在即将到来的Sprint中做什么。为了估计完成每项工作需要多长时间, 规划扑克 很有用。该 看板 (或Scrum的董事会)是Scrum的一个关键项目。 这是信息持久显示,可视化和与团队共享的地方。 鼓励定制以适应团队的工作流程。完成的定义 是Scrum中另一个必须遵守的规则。 Done的定义不仅仅是Sprint团队成员在发布前验证工作的质量保证概念。 它也是Sprint中发生的许多假设和实验的测量和学习标准。Scrum中有两个辅导员角色。 第一个是 产品所有者 ,“什么”的人,第二个是 Scrum Master ,“如何”的人。 关键在于促进 - Scrum团队的生产力以“ 速度 ” 来衡量 ,或者他们能够以多快的速度完成任务,并且最有效的是促使团队成员单独和共同决定做什么和做什么,而不是而不是像传统的等级组织那样指导他们。3.每日站立 (Daily Standup)一个典型的Scrum团队应该在3到9人之间 ,包括产品负责人和Scrum Master。 任何更大的,团队的速度下降,所以最好分成不同的Scrum团队。速度的关键在于团队成员之间在进步和障碍方面的丰富沟通。 固定格式每日站立被证明是用于这一目的非常有效: 每天都 在 同一时间 ,为 不到15分钟 ,球队在看板前聚集,并且每个团队成员通过回答以下分享他们的进步三个问题:✓昨天做了什么工作?✓今天计划做些什么?✓任何阻碍的方式?或者,团队也可以按照看板上的完成和待办事项的顺序进行。 如果多个团队成员参与每个看板委员会项目的工作,这可以是更好的格式。在 每日站立不是状态更新会 为经理,找出谁是落后于计划或给工作指令。 状态更新仅提供快照 - 重要的是签入流程。 站起来是团队了解已完成的工作和剩下的工作,以便人们加快团队合作。 如果有人被困,其他团队成员会帮忙。 如有必要,Scrum Master会重新调整工作流程,以便于移除障碍物。4. Sprint评论和回顾 (Sprint Review and Retrospective)在每个Sprint结束时,Scrum团队会召开两次会议。第一个是“什么”会议:Sprint Review将讨论由产品负责人推动的最后一个Sprint所做的工作。 这次会议通常伴随着新版本和其他成就的演示,欢迎来自组织其他成员的成员加入。第二个是“如何”会议:Sprint回顾展。 这是Scrum团队成员反映和讨论在上一个Sprint期间出现的障碍,即使事情进展顺利,还有改进的想法。 Scrum所有者通过确保重点仍然是修复流程而不是人们责备来促进此会议。在两次会议结束时,团队更新Backlog并计划下一个Sprint。Scrum的常见陷阱‣无灵魂的Scrum:冲刺为迷你瀑布通常,用户故事成为迷你规范文档。 然后,执行编码或任何活动,然后进行UAT(用户验收测试)或其他签核过程。 乍一看,这听起来并不错,许多团队陷入了这个陷阱。问题是,这只是以迷你瀑布风格运行的迷你项目。 分析,设计,编码和测试以顺序方式完成,可能跨越多个Sprint,最有可能作为功能之间的移交过程(例如BA(业务分析师)>开发人员> QA(质量保证))。精益与敏捷是关于不确定性的发现。 在Scrum中,构建 - 度量 - 学习周期被设计为在Sprint中发生,并且从事假设,MVP(最小可行产品)构建和测试的团队成员需要彼此尽可能地工作; 即跨职能团队合作。 工作不必是顺序的 - 如果某些东西不起作用或缺少标记,那么完全可以进行设计更改和修改,或者做出有意识的决定以采用不同的方法; 即调整和微型旋转。 迷你瀑布击败了迭代的目的,只实现了Scrum的小增量优势。‣领土Scrum敏捷现在在软件开发团队中很常见。 问题是,在许多组织中,只是运行Scrum的开发团队,有效地在组织内创建了一个岛。结果是开发团队与组织其他部门(即销售团队)之间的交流文化:“我们按照您的规范将产品整合在一起,现在就去销售它”。传播组织范围敏捷的关键是让人们将敏捷视为一种更广泛的沟通,合作和共同创造概念,而不仅仅是一个项目管理框架。 问一个问题,如果我们内部无法很好地连接,我们如何与客户建立联系? 这应该会促使持续的客户价值创造和产品市场适应各个团队的思维。在组织范围的敏捷的实际实施方面,销售和营销的Scrum可以与开发团队的Scrum并行运行。 最终,最好的目标是转向跨职能的Scrum团队,其中开发,销售和营销职能都在每个Scrum团队中,并与产品或客户项目保持一致。‣Scrum Master in Command在每日站立期间,如果人们向Scrum Master提供状态更新,并且Scrum Master告诉人们该做什么,那么你就是在击败Scrum的目的。Scrum是一种系统性的努力,可以使组织脱离管理者 - 工作者模式。 在解决问题的企业中,指挥领导模式失败 - 它依靠领导者得到所有答案,使领导者自己成为障碍。在敏捷组织中,你试图从人们身上带出所有“合作” - 合作,协作,协调,共同创造,沟通,联系等等。 Scrum Master的作用是保持“co”流向侧面,而不是像指挥一样垂直。我们还必须了解“工人”在经理 - 工人模式中的被动安慰:接受工作指示是令人欣慰的,因为您不必考虑原因和方法,并且您不受决策责任的影响。 Scrum以多种方式解决了转变为自主工作模式的痛苦; 小型构建模块方法使工作更容易管理,每日站立是为了让团队成员在遇到困难时互相帮助,并且不责备人的文化鼓励个人承担实验风险。‣冲刺直到你掉落如果一个领导者设计“冲刺”作为一种系统的手段,使人们在永久的高度戒备中尽可能地努力工作,那只是危机的习惯性管理,或者更糟糕的是,剥削劳动力。一个不那么邪恶的领导者可能将“冲刺”定位为类似于赛道或游泳中的间歇训练。 他可能会说,通过持续不断的紧张工作,团队将能够突破其表现的界限。 但这会给团队成员带来精神疲惫的风险。 在如此高压力的环境中吸引和留住人才是很难的。在一次Sprint之后,下一个Sprint立即开始。 如果团队开始尝试从最后一个恢复新的Sprint,显然他们已经过度踱步。 Sprint必须以可持续的速度运行,不需要Sprint之间的休息或恢复时间。实际上,Scrum Sprints可能不应该被称为sprint。 它应该更像是慢跑或其他东西。 是的,你确实希望你的团队的“速度”增加(在Scrum中我们使用“ Burn Down Charts ”来衡量这一点),但这并不是你追求的终极速度。 你追求的是平均速度的提高,即在相同的时间内覆盖更多的距离。 正如任何长跑运动员都会证明的那样,找到合适的节奏和节奏是迈向远方的关键。采用精益和敏捷并非易事。 精益和敏捷背后的意识形态是理性的,对大多数人来说都是有意义的,但是将其付诸行动需要思维方式的转变和许多破碎的习惯。 虽然如果做得好,精益和敏捷将带来令人难以置信的生产力,积极性和突破组织。 在Lifecycle,我们非常了解组织行为和黑客攻击方法,以推动成功的精益和敏捷组织转型。Agile & Scrum BasisComprehensive Scrum GuideWhat are Scrum’s Three Pillars?What is Agile Software Development?Scrum in 3 MinutesWhat are the 5 Scrum Values?Classical Project Management vs Agile Project ManagementWhy is Scrum Difficult to Master?What is Velocity in Scrum?What is Agile? What is Scrum? ...

December 28, 2018 · 1 min · jiezi