• [活动打卡] [第5期] 结业实践结果征集【云享读书会-猎豹行动:硝烟中的敏捷转型之旅】
    感谢关注华为云 · 云享读书会系列活动~本期活动已结束~查看本期读书会领读视频   请戳:云享读书会《猎豹行动:敏捷转型之旅》查看本期读书笔记   请戳:读书笔记征集【云享读书会-猎豹行动:硝烟中的敏捷转型之旅】获取近期读书会活动安排,请私信小助手咨询哈~开发者,你好哟~华为云 · 云享读书会 2020年首期活动上线!本期为系列活动的第五期,领读书籍为《猎豹行动:硝烟中的敏捷转型之旅》邀请书籍原作者-敏捷圈内大咖——刘华 现身领读,带你了解敏捷转型的高效实施策略!!!如果你已完成结业实践作业,请在此帖回复结果截图~01. 征集时间2020.03.09 - 2020.03.1502. 截图示例回帖时请务必留下你的微信昵称和华为云账号截图示例:03. 注意事项1. 截图提交后,小助手会在3个工作日内按续完成审核,并增加活动积分200分;2. 本次活动共包含1个结业实践任务,通过完成结业实践,可获得的积分上限为200分;3. 请务必按照上述要求提交内容,以免影响积分增加;4. 若积分值相同则以完成学习任务的时间先后排序,其中任务完成时间的判定优先级为:结业实践>读书笔记>自测题;5. 其他积分获取方式请查看活动社群公告;6. 其他未说明事项请参照 云享读书会《猎豹行动:硝烟中的敏捷转型之旅》04. 活动奖励05. 关于云享读书会每期云享读书会活动,会选取一本技术相关的畅销书籍,由原作者提炼书籍精华,在读书会的专属微信社群中,每日输出精华知识的领读视频,帮助大家快速积累专业知识。活动期间会设置每日自测题、结业实践任务、提交读书笔记三种积分获取任务,并根据活动结束后的积分排行发放活动奖励。
  • [问题求助] 读《敏捷教练》: 迭代结束时,团队没有“完成”怎么办?
    讨论主题我们总是在讲,如何使团队在迭代结束时“完成”所有的故事,那么如果没有完成呢,你应该怎么办?关键字敏捷教练、承诺、团队书中建议归纳慎重对待。谈谈在迭代演示和回顾会议上出现的情况。帮助团队理解发生这种情况的原因,询问他们有什么建议可以阻止这种情况再次发生。在规划下一个迭代前,团队需要决定如何避免“完不成”对其速率的影响。心得帮助团队制定务实的计划是需要通过更多的迭代来完成的,需要有耐心。后继的几个迭代中作为教练需要让团队明白问题的存在,真正相信自己的承诺是不靠谱的,然后才会有改变的意愿。有一种情况确实比较头疼:客户压力大,对他们提出的所有要求都接受。即使团队心里明明清楚承诺太多,也不知道应该怎么拒绝,他们一直拼命加班的干活,专注于构建更多的软件,以至于没有认真思考这个问题。教练需要想想办法给团队争取时间喘喘气,同时要让团队相信说“不”也是一个选择。以便团队能够真正地理解。教练要帮团队多收集数据,以佐证可以承诺更少。在规划下一个迭代时用数据提醒他们注意团队速率,不要承诺超出速率的工作内容,当然这需要多积累几个迭代。教练同时要让客户了解过多承诺会有无法交付的风险。如果客户坚持,那就把用户故事拆分得更细,以便在迭代结束时至少可以交付一些故事。以上,欢迎大家交流,共同探讨和分享。
  • [交流吐槽] 【讨论帖】MoSCow法则是鸡肋不?
    讨论主题在敏捷转型的过程中,一致以来被一个问题所困扰——如何对Sprint 待办列表的故事进行优先级排序。在学习敏捷(参加过ACP的培训)的时候,学到的排序方法是MoSCow法则,也就是“Must have:必须有,Should have:应该有,Could have:可以有,Won’t have:可能不会有”的四个优先级。所以也就依葫芦画瓢实践过一段时间,但是发现只有这4种优先级还是不够用,因为我们团队的工作(故事、任务)比较多,有时候会出现7、8个 Must have,甚至上10个,所以也就搞不清哪个更需要优先做,也经常会因此发生一些battle……所以想关于MoSCow法则是不是一个鸡肋的问题和大家讨论一下,如果是,为什么都在推行这种方式呢?如果不是,那么应该怎么使用呢?
  • [交流吐槽] 【讨论帖】估算的单位用什么?
    讨论主题在我之前所做的项目中,都是用小时数来做任务的单位。但自从我接触了敏捷后,开始使用故事点为单位(曾经有一位外部的敏捷教练给我们培训后,说这种方式很快!)。关于故事点的这种方式在团队中实践过,但是最后其实又变成了小时数(老板说,你就告诉我,到底用多长时间?)。为此也查阅过一些书籍,但是却不是很认同!比如,“当估算使用任务小时的方式时会有造成混乱,人们总是期待着,只要2个小时就能完成估值2小时的任务。事实并非如此,有时候任务只要20分钟就可以完成,有时候则5个小时都做不完。这就是估算的本质,也是估大小往往比估时间更有效的原因”。这个说法我觉得有过牵强,难道只是因为一个单位的问题,导致20分钟和5个小时的差别吗?所以,发此贴希望能得到各位专家的答疑解惑——在敏捷开发中,估算的单位用什么?为什么呢?谢谢~~~~
  • [交流吐槽] 读《敏捷教练》: 谁应该来测试?
    讨论主题谁应该来测试?关键字敏捷教练、引导、测试、完成书中建议归纳测试并不是某一个人的事情,它是整个团队的责任,共同促成“完成”。心得敏捷教练应该帮助团队成员学会互相配合,共同努力完成“进球”。(想想足球比赛,场上所有运动员相互配合,追着球跑或是加强防守,而不是一个地方一直等待)如果再具体点讲,到底哪些人员可以参与测试,如何测试呢?开发人员、客户、测试人员、外部团队均可,需要他们对“完成”的定义达成共识后一同协作。开发人员:自己通过故事测试之后才提交,减少COPQ(不良质量成本)。鼓励开发人员利用编码优势做测试。客户:要让客户获得最新版本进行尝试测试。他们最清楚软件的预期使用环境,关注用户在用户故事中的目标是否达成。提示:他们也许会对边界情况测试不足。测试人员:可以尝试和开发人员结对做测试。他们更专业(各种专业测试),帮助团队充实故事测试。外部团队:多数是一些特定的测试工作。比如安全测试、易用性测试等。需求负责人或PO:团队尽量与PO沟通,可以做一些Show Case。在条件允许的情况下,开发人员可以在未完全开发完毕的情况下与需求负责人沟通,确认方向是否正确,风险前置。以上,欢迎大家交流,共同探讨和分享。
  • [交流吐槽] 读《敏捷教练》: 身为敏捷教练你是如何引导会议的?
    讨论主题敏捷教练如何引导会议关键字敏捷教练、引导、敏捷会议书中建议归纳为团队引进新实践时,需要展示具体做法,不能任由团队自力更生。心得新形式的敏捷会议对团队来说不容易开成功,第一次的会议要由敏捷教练引导。实时进行点评,重要的是要团队理解你在引导会议时的思考过程。之后的会议慢慢退出引导角色,可以做些帮助团队做准备并在会后给予反馈。首次尝试敏捷会议时,教练主动请缨引导会议,向团队展示具体做法。把流程解释给团队,让团队学习如何自主引导会议。下次时,改为协助会议的引导者,最后退居二线。几点提示帮助更好地开会:选择恰当的时间开会,确保整个团队都能参加。布置好场地,准备好工具。明确会议目的,开场时声明会议目的和议程,还要提醒遵守敏捷会议的基本准则。保持会议顺畅,引导者发挥充分作用。鼓励全体参与,确保所有人都发表自己的观点。总结要点,可以记录在白板,复述理解,确认团队真的理解。结束会议,确保产出都已记录。欢迎大家参与讨论。
  • [交流吐槽] 读《敏捷教练》: 你知道敏捷教练的职责吗?
    讨论主题敏捷教练的职责关键字敏捷教练、职责书中建议归纳敏捷教练的使命是帮助团队驾驭敏捷,开发出色的软件。敏捷教练的目标是培养高产出的敏捷团队,成员有自我判断能力,不依赖教练为他们制定敏捷法则。需要改变团队的工作方式和思维方式。心得敏捷教练在辅导团队的时候不能一层不变,要按情况分类:1,新团队,没有接触过敏捷。敏捷教练应该像运动教练一样,积极示范敏捷实践是如何操作的。2,敏捷经验丰富的团队。敏捷教练应该像生活教练一样,通过倾听和提问来帮助他们提升,而非直接给出解决方案。下面给出具体事项供敏捷教练们参考:留意:留意团队的工作方式,思考他们为什么这样做,有些哪诱因。反馈:反馈,分享你的观察到的情况。帮助他们利用这些反馈改进工作方式,做到团队可以自己发现问题。教育:鼓励学习。演示敏捷方法,可以讲故事,可以开设培训课程。引导:清理障碍。促进有建设性的沟通和协作,可以使团队更容易走向敏捷。支持:团队受阻时教练要在场,鼓励团队继续前进,帮助他们保持动力。以上看上去有好多事情要做,但需要注意不一定要一步到位。教练得一步一步脚印地走下去,而不是发起重大变革,这一点非常重要。成功在于建立正确的态度。欢迎大家一起讨论,你认为敏捷教练的职责是什么?应该怎么样做?
  • [技术干货] 用瀑布开发模式的企业是否可以直接上DevOps
    在Jez Humble的《持续交付》一书中,我们能看到反模式和持续交付原则提倡的开发方式的对比,持续交付能给我们带来的好处,包括但不限于如下:更早的交付需求提高版本质量减少由不良好的配置管理引入到生产环境的错误。缓解积压发布带来的压力更加灵活地部署书中很多地方提到了精益敏捷,已经假定你所在的公司开发模式就是敏捷了,然后再实践持续交付。但是在我们走访企业的时候,发现很多企业,依旧使用的是瀑布开发模式,因为敏捷转型是一场变革,有的企业由于高层领导不接受转型,所以一直保留着瀑布开发方式。那么在这种情况下,是否可以进行DevOps落地?是否可以采用持续集成、持续交付呢?这里我说的DevOps指的是狭义的DevOps,即Dev-Ops的部分。因为端到端的DevOps已经包括了敏捷部分。在考虑这个问题的时候,想到了一张图,见下图,也是Jez Humble的图。这里我们可以看到,对于瀑布开发模式职能团队来说,开发和测试团队的交接,开发团队和运维团队的交接,分支模式的使用,严格控制发布窗口,这一系列使得交付频率受限,是高不了的。也就是说,瀑布开发的模式,决定了你无法完全进行DevOps落地。那么再看看有哪些能改善的地方呢?能不能在不受职能团队影响的情况下,落地DevOps的一些好的实践呢?比如持续集成的几个原则,这些是纯开发团队自己能做的,不涉及到多职能团队,所以可以独立进行开展。包括如下构建失败之后不要提交新代码提交前在本地,或持续集成服务器,运行所有测试 提交测试通过后再继续工作 回家之前,构建必须处于成果状态不要将失败的测试注释掉开发人员每天开始时至少拉取一次代码开发人员每天结束时至少提交一次代码通过这些实践,可以提高代码的质量,减少协作间的代码冲突,降低反复工作所消耗的时间。测试方面,开发人员自己要做单元测试,同时可以适当加入接口自动化测试,来保证一定的业务场景是好用的。因为每次提交代码都要运行测试来保证质量,所以测试比如使用自动化来进行,考虑到开发人员在测试方面的投入不会高,所以用接口测试来覆盖场景就可以。每次提交新的代码,自己运行一遍接口自动化测试,可以提高代码的质量,降低代码交付给测试团队后,出现的问题。最重要的是,每开发一段新代码,自己运行一遍以接口自动化测试承担的回归测试工作,大大降低了手工的工作量。版本控制方面,由于环境配置等内容涉及到跨职能团队了,所以这里我们只考虑代码版本库。建立版本库进行管理,并保证提交的代码和对应的需求进行关联,这样当回溯问题的时候,方便追踪。部署流水线方面,由于运维团队控制着生产环境,所以我们只考虑开发人员在开发环境的部署,目的是可以尽早做一些集成测试和验收测试。而部署到开发环境做的频率又是很高的,即使这是瀑布开发模式。所以在这里可以引入部署流水线,并配置上代码检查、基本的测试等内容。综上所述,笔者的意见是,对于不接受转型敏捷开发的团队,可以在持续集成、版本控制、部署流水线方面采用DevOps的一些理论、支撑的工具及最佳实践,来帮助团队提供更高质量的代码。
  • [问题求助] 读《如何构建敏捷项目管理团队》: 当敏捷经理发现团队存在问题要修复的时候,敏捷教练要不要阻止?
    书籍名称《如何构建敏捷项目管理团队》丽萨·阿金斯著 徐蓓蓓 白云峰 刘江华译讨论主题场景描述:一位经理向敏捷教练说:“我想团队最近有些士气低落。在昨天的站例会上,我注意到他们没有什么活力。我们得做些什么。也许带他们玩一天来帮助他们充电?”作为敏捷教练要不要阻止?注:敏捷经理指的是团队成员的直属经理、团队所在的开发项目或者平台的管理者、其他具有合作关系的团队的经理,或者整个公司范围内的利益相关人。书中建议告诉经理把这个问题交给团队自己解决,而不是由自己插手代劳。敏捷工作方式中,发现问题和解决问题都应顺其自然。旁观者不需要通过额外干预而让一些事情发生。团队可以通过回顾来解决问题,不要让经理从团队之外的角度“修复”问题。个人观点书中建议是完全从敏捷的角度出发,让团队自组织和自管理,重点强调的是把问题留给团队。在敏捷实施过程中,有些团队不具备自组织和自管理的能力,需要逐步培养和形成,因此关于是否要把问题留给团队要分阶段分情况进行。向敏捷转型是有一个过渡的过程,在初期需要敏捷经理的干预,等到团队真正成长起来后逐步放手。
  • [问题求助] 读《敏捷教练》: 评审会无可演示产品,也一定要开吗?
    讨论主题敏捷团队在迭代结束时,没有可演示的产品,是否每次都需要开评审会议?书籍名称《敏捷教练》-如何打造优秀的敏捷团队关键字敏捷、团队、客户、承诺、转型、教练书中建议归纳鼓励团队坦然面对,想办法按照产品当前的状态进行展示。如果轻易取消会给团队和干系人发出一个信号,即每个迭代结束交付可工作软件这件事并不那么重要。需要通知重要干系人,以免他们觉得是在浪费时间。提醒团队,即使软件尚未完成,他们仍然可以拿到一些有意义的反馈。个人观点书中建议很好,需要提醒一点,特别在和客户初次合作,彼此磨合期信任度不够时,应该加强有效沟通频率,评审会议是比较不错的反馈工作成果的机会,加强客户信任感。即使是成果不多,哪怕一点点,只要让客户知道团队在这个迭代付出了努力,有过程产出即可。相反,如果与客户合作时间已经很久了,彼此有很强的信任感,可以减少相对意义不大的沟通,不要给客户一个错觉,好像做了一点成果就要汇报的感觉,也要考虑客户的工作时间是否饱和,客户的关注点在哪里,做好充足准备,有可演示的产品增量时汇报效果会更好。当然,如果客户对敏捷有热情,愿意参与敏捷活动中的各个环节,那么邀请客户参与无演示成果的评审会议,一同聊聊迭代工作内容也不错,我们也鼓励这样做。欢迎大家留言讨论。
  • [活动打卡] [第5期] 读书笔记征集【云享读书会-猎豹行动:硝烟中的敏捷转型之旅】
    感谢关注华为云 · 云享读书会系列活动~本期活动已结束~查看本期读书会领读视频   请戳:云享读书会《猎豹行动:敏捷转型之旅》获取近期读书会活动安排,请私信小助手咨询哈~开发者,你好哟~华为云 · 云享读书会 2020年首期活动上线!本期为系列活动的第五期,领读书籍为《猎豹行动:硝烟中的敏捷转型之旅》邀请书籍原作者-敏捷圈内大咖——刘华 现身领读,带你了解敏捷转型的高效实施策略!!!经过作者的视频领读,如果你有些敏捷相关知识收获,欢迎在此帖留下你的读书笔记~01. 征集时间2020.03.09 - 2020.03.1502. 读书笔记要求1. 每篇读书笔记字数要求≥300字;2. 内容要求与每日领读视频、《猎豹行动:硝烟中的敏捷转型之旅》书籍或是华为云DevCloud产品优化意见相关;3. 内容原创不可抄袭;4. 回帖时请务必留下你的微信昵称和华为云账号。03. 注意事项1. 读书笔记提交后,小助手会在3个工作日内按续完成审核,并增加活动积分100分/篇;2. 本次活动通过提交读书笔记,可获得的积分上限为500分;3. 请务必按照上述要求提交内容,以免影响积分增加;4. 若积分值相同则以完成学习任务的时间先后排序,其中任务完成时间的判定优先级为:结业实践>读书笔记>自测题>其他;5. 其他积分获取方式请查看活动社群公告;6. 其他未说明事项请参照 云享读书会《猎豹行动:硝烟中的敏捷转型之旅》04. 最佳读书笔记奖励领读专家将在活动时间内提交的有效读书笔记中,评选出3篇最佳读书笔记05. 活动排行奖励06. 关于云享读书会每期云享读书会活动,会选取一本技术相关的畅销书籍,由原作者提炼书籍精华,在读书会的专属微信社群中,每日输出精华知识的领读视频,帮助大家快速积累专业知识。活动期间会设置每日自测题、结业实践任务、提交读书笔记三种积分获取任务,并根据活动结束后的积分排行发放活动奖励。附录. 每日自测题答案DAY01自测题1.     以下有哪些是瀑布模型对于业务方的痛点?(多选,正确答案:a、c、e、f)    a)      超支    b)      惧怕需求变更    c)      缺乏透明度,不知道具体进度    d)      过度承诺    e)      逾期交付    f)       贻误战机,丢失市场机会2.     项目开始的时候,有哪些要素是完全确定的?(多选,正确答案:b、d)    a)      范围与具体需求    b)      交付日期    c)      对现有系统的影响    d)      预算3.     敏捷与瀑布最大的不同点是什么?(单选,正确答案:b)    a)      全量开发    b)      增量开发4.     以下有哪些是Product Owner应该做的业务决策?(多选,正确答案:b、d)    a)      解决方案    b)      需求    c)      开发周期    d)      优先级5.     DevOps要打破的最后哪堵“墙”?(单选,正确答案:d)    a)      业务与开发之间    b)      开发与测试之间    c)      测试与运维之间    d)      开发与运维之间 DAY02自测题1.     JIRA和Confluence可以结合使用吗?(是非,正确答案:可以)    a) 可以       b) 不可以2.     下面哪个工具可以实现自动化部署?(单选,正确答案:d)    a)      Github    b)      Jenkins    c)      SonarQube    d)      Ansible3.     Github可以增强代码评审流程吗?(是非,正确答案:可以)    a) 可以       b) 不可以4.     JIRA可以用来做测试管理吗?(是非,正确答案:可以)    a) 可以       b) 不可以5.     JIRA和Confluence的产品设计体现哪些原则?(多选,正确答案:b、e、f)    a)      独占性    b)      去中心化    c)      中心化    d)      保密性    e)      信息共享    f)       灵活 DAY03自测题1.     把需求文档里面的功能点分出来,就是用户故事了吗?(是非,正确答案:不是)    a) 是          b) 不是2.     用户故事可以独立交付上线运行吗?(是非,正确答案:可以)    a) 可以       b) 不可以3.     运用极限编程,需要做长期的计划吗?(是非,正确答案:不用)    a) 用          b) 不用4.     没有限制在制品的可视板是看板吗?(是非,正确答案:不是)    a) 是          b) 不是5.     下面哪些实践是极限编程提出的?(多选,正确答案:a、c)    a)      测试驱动编程    b)      大爆炸式上线    c)      持续集成    d)      回顾会议 DAY04自测题 1.     实例化需求是为了解决什么问题?(多,正确答案:b、c、d)    a)      需求太大太复杂    b)      需求理解不一致    c)      通过具体例子描述验收条件    d)      形成交付闭环2.     微服务架构就是把前端、后端拆成两个独立的应用吗?(是非,正确答案:不是)    a) 是          b) 不是3.     特性团队里每个人都要是通才,需求分析、开发、测试、运维、前端、后端样样精通吗?(是非,正确答案:不是)    a) 是          b) 不是4.     契约测试是通过文档来约定API提供者和消费者之间的接口吗?(是非,正确答案:不是)    a) 是          b) 不是5.     契约测试里的契约是由哪方提出的?(单选,正确答案:b)    a)      API提供者    b)      API消费者 DAY05自测题1.     故事点就是人/日的另一种表达方式吗?(是非,正确答案:不是)    a) 是          b) 不是2.     敏捷计划是在开发开始前就知道多少个迭代可以交付所有的用户故事吗?(是非,正确答案:不是)    a) 是          b) 不是3.     好的累积流图应该是怎样的?(单选,正确答案:c)    a)      待开发的面积最大    b)      待测试的面积最大    c)      已完成的面积最大4.     在服务等级中,加急类别的请求可以违反限制在制品的要求吗?(是非,正确答案:可以)    a) 可以       b) 不可以5.     在估算扑克游戏中,参与的人员是各人按座位的顺序依次亮出自己的牌吗?(是非,正确答案:不是)    a) 是          b) 不是
  • [案例分享] 【DevCloud•高校名师课】敏捷需求管理-大连理工大学马瑞新教授
    本次课堂为大连理工马瑞新老师《系统分析与设计》里面的一节,本课程自2004年开课以来,先后进行了几次大的变革。在2016年申请了教育部产学协同育人项目和华为签署了战略合作协议引入了华为软件开发云,将华为ICT技术与产品知识融入到实际教学中,让企业教师走进课堂。教学中采取基础知识和新应用综合案例,企业实践的结构和由浅入深由深到精的学习方式,把企业中的规范和流程融入到学生的学习中。本课有四部分。第一个部分介绍了传统与敏捷的比较。第二个部分通过通过传统和敏捷的比较,用一个棉花糖挑战来体验一下敏捷的精髓。第三部分是去讲敏捷中的一个重要环节——用户故事。最后通过Devcloud软件开发云课堂实训平台能完成一个当堂的在线实践。
  • [案例分享] 大连交通大学“敏捷桃花岛”项目实训总结
    大连交通大学“敏捷桃花岛”项目实训总结背景:大连交通大学是东北地区唯一一所以轨道交通为特色的高等学校,是教育部第二批实施卓越工程师教育培养计划高校、国家软件人才国际培训(大连)基地、国家级人才培养模式创新实验区、全国建设高水平运动队院校和体育文化研究基地、辽宁省车辆工程紧缺本科人才培养基地、辽宁省对日服务外包人才培养基地和大连东北亚国际航运人才培训基地,是国家产学研合作先进单位,是辽宁省产学研合作创新基地。学校以**新时代中国特色社会主义思想为指引,紧紧围绕辽宁老工业基地全面振兴和现代轨道交通装备制造业发展,抓牢“一带一路”“交通强国”“高铁走出去”等国家战略实施的发展机遇,全面深化改革,深入推进“双一流”建设。在成绩获得了充分肯定的同时,大连交通大学也认识到,人才培养、科技创新与社会服务等方面的发展水平与区域经济社会发展的需求仍然有较大差距,一些发展瓶颈问题还有待破解,为了加强学科内涵建设,大力推动特色学科发展,大连交通大学希望根据中华人民共和国教育部‘合理提升学业挑战度、增加课程难度、拓展课程深度,切实提高课程教学质量’的文件精神,结合大连交通大学计算机科学与技术专业本学期的课程安排,校企结合,通过企业对教学课程赋能,提升学生的实践动手能力和项目开发能力。与此同时,华为云DevCloud教育解决方案内容建设团队正好在大连基地,大连交通大学与华为双方一拍即合,通过将华为的企业实践项目引入到教学场景中,充分发挥企业实践优势,让同学们将所学软件工程及编程语言与实际相结合,在学校期间提前了解企业真正的软件开发过程,提升同学们的编码、项目敏捷开发等实践动手能力。 挑战:1、基础设施:学校服务器数量有限,机房网络带宽小,影响上机实践,同时目前还缺少一套可供学生课上课下操作练习的环境。2、教学方案:学校比较缺乏企业实践项目教学案例,教学过程中,大多数时候教的是基础知识,相应的实践项目供学生参考使用,无法让学生了解企业软件开发的整个流程。3、学生方面:学生水平参差不齐,大多数学生还停留在编写代码,熟悉语法的基础上,对软件开发流程、开发模式、团队协同、自动化、流水线、CI、CD以及DevOps等开发模式,接触得非常好,甚至没从来没听过这些名词。 解决方案:    与大连交通大学王老师、田老师等多名老师,多次交流讨论,以客户为中心,解决客户痛点,我们华为云DevCloud教育解决方案EduCloud给出如下方案。1、  使用EduCloud进行教学。理由:EduCloud是华为云DevCloud教育解决方案的一站式教学平台,为老师和学生提供统一的平台。 老师通过EduCloud可以轻松的进行备课、下发作业、统计学生作业完成情况、分析学生对知识的掌握情况等。一方面,EduCloud提供了丰富的内容资源,包括基础编程课如:java、c、c++、Python等,也包括项目开发课程,如:敏捷江湖桃花岛、黑白棋等,还包括前沿技术方面的课程,如AI、自然语言分析等。 另一方面,EduCloud还提供了大量的习题资源,所有习题均可以通过EduCloud在线判题能力,进行自动判题。 这样一来,可以大大的减轻老师备课、出题、判题所消耗的精力,可以更聚焦到教学上面。 学生也可以通过EduCloud平台,在下课之后,在宿舍利用便携完成老师布置的作业。这就解决了机房服务器问题,解决了网络带宽问题,解决了课上课下随时可以进行写作业的问题。2、  使用华为云DevCloud +《敏捷江湖桃花岛》项目进行实训教学。 理由:该课程结合高校实际教学场景,从棉花糖挑战赛这个游戏,引出对现代软件工程的认识,从而引出敏捷及scrum开发的相关概念。 紧接着通过一个典型项目,分4个阶段分别就项目立项、产品规划、技术准备和Sprint开发进行了详细的介绍。结合实践项目,搭配软件开发云,帮助学生了解整个软件开发的开发过程。 从需求管理,项目管理,到代码开发、测试、代码托管、代码质量检查、编译构建、发布、部署、流水线等方面,了解敏捷开发的整体流程,为学生毕业后进入企业工作,提前做技术储备工作。通过《敏捷江湖桃花岛》项目实践教学,可以解决上述挑战中的问题2、3.图一:项目开发全景图  在大连人才培养也"上云" 华为云EduCloud首发上,对于华为云参与产教融合创新、培养高校人才的积极作用,大连交通大学副校长傅利斌表示,作为第一批通过华为云进行授课的学校,大连交通大学在学科建设、教学信息化、软件工程人才培养和学生就业方面取得积极进展——学生学习热情、教师工作干劲、教育教学质量得到提高,真正做到教师在教中教、学生在学中学,理论与实践结合。华为云助力高校培养信息人才的行动为中国经济转型和升级创造了新动力。图二:华为云DevCloud教育解决方案大连首发上线,大连交通大学副校长致辞 在实际教学过程中,华为方多次派出专家,去大连交通大学,与老师和同学一起,针对《敏捷江湖桃花岛》进行剖析和指导,模拟项目开发,团队组建分组等。带领同学们进行需求分析、Story编写、迭代任务制定、回顾会议召开、项目开发、代码提交和管理、代码检查、编译构建、发布、部署、流水线端到端拉通等等。同学们收益匪浅,通过实践活动,同学们了解了企业软件开发的真实流程,了解了很多在课堂上学不到的但进入企业工作却非常重要的知识。根据以学代练,通过《敏捷桃花岛》项目案例作为参考,同学们积极主动的进行实践,开发了几十个项目出来。图三:华为专家在大连交通大学现场授课  图四:大连交通大学基于《敏捷江湖桃花岛》项目进行项目实践开发情况 总结本次通过这门《敏捷江湖桃花岛》项目实践课程,进行校企合作的开展,将符合中华人民共和国教育部的全新的理念融入到教学当中去,通过课堂、课中、课后对学生进行全方位指导教学,整体上老师结合企业实践教学,效果更好,更满意。 学生通过实践项目进行参考练习,学到了课本上学不到的知识,为今后毕业进入企业工作,提前打好了坚实的铺垫。 校方也因引入产教融合,提升了学校的教学质量,真正做到理论与实践结合而满意,政府因引入华为云DevCloud教育解决方案,提高了本地产业人才能力,为本地产业发展融入新鲜血液,促进产业创新而开心。 当然,要让高校的所有软件类学生使用并提升他们的实际动手能力,我们还需要做很大的努力,今后我们将积极在政府的带领下,与高校老师进行深入合作互动,将更多的企业实践项目开放出来给高校进行教学,与学生进行充分的互动交流,提升教育水平,为培养创新型、复合型、应用型人才而努力奋斗。
  • [技术干货] 【DevCloud · 敏捷智库】估算第二篇:利用核心概念解决估算常见问题(内附下载材料)
    作者:黄隽(Charlie)背景敏捷江湖桃花岛社区下线会议时,敏捷实践者问了很多关于估算的问题。作者在这里把具有共性的问题简单做了梳理。问题主要集中在团队只关心估算结果,也就是数字。再则团队经常在外界压力下过度承诺迭代目标。这两个比较集中的问题描述如下:问题一:团队只关心数字。计划会议大家只关心估算的数字,经常花费大量时间做估算,怎么办?问题二:团队过度承诺。有时候,团队被迫承诺过多的工作,迭代目标完不成,怎么办?团队用于估算时间过多,留给开发的时间会相应减少,大家工作紧张,状态不佳。团队过度承诺直接造成迭代目标不能完成,士气低落。以上弊端直接伤害敏捷团队,是敏捷团队保持稳定健康节奏的阻力。问题分析以上两个问题也是敏捷初始团队经常遇见的问题,现简单分析发生原因如下:问题一:团队只关心数字。团队从瀑布开发方式转为敏捷开发后,学习了敏捷Scrum框架,然后开始使用敏捷开发。他们知道其中有一个事件是迭代计划会议。在会上团队成员经常耗费大量时间做估算。常见对话:“这个估算数字合理吗,我们要不要再好好想想清楚?”因此团队常常陷入无休止的讨论中。团队狭隘的理解为,计划会议中最重要的事情就是估算,而估算最重要的事情就是得到每个用户故事完成所需要花费的精确时间,即数字。也就是说,团队过于追求数字的准确性,忽略了估算的真正核心价值。问题二:团队过度承诺。团队经常在产品上市日期已经确定的情况下过度承诺。因为时间紧迫,领导施压(与资金和绩效挂钩)。比如,领导经常说:“大家加把劲儿,我相信大家的能力,努力一下,这些需求你们是可以做完的,大家的表现会影响绩效评估,年底咱们多发点资金。”所以团队常常了了估算、一言堂(架构师说的算)、猜测工作量,最后造成过度估算,经常完成不了迭代目标。小结“团队只关心数字”和“团队过度承诺”两个问题是敏捷初始团队经常遇见的问题。从以上问题分析中可知,团队成员并没有了解估算的真正核心意义,导致团队狭隘地理解成估算就是要最后的数字,而且在有外部压力的情况下团队也顾不上认真估算,盲目地过度承诺工作内容。其实估算并不只是为了得到估算数字和不靠谱的承诺。我们先一起学习和了解什么是估算的核心内容,这样可以更好地理解估算,然后再针对以上2个问题进行解答。解决措施利用核心概念树立正确认识在这里,我们只考虑不了解核心概念而导致估算活动不理想的情况。还有其它情况可以导致估算活动不理想。比如,不会利用故事点估算、不会估算具体方法等。这两种情况我们在后续的2篇文章中给予解答。通过上一篇《估算第一篇:利用用户故事了解需求》相信了解了如何利用用户故事理解需求。如果对用户故事不太了解的朋友,建议可以花一点时间阅读上篇文章,也会有助于做好估算。现在我们一起了解一下估算的4个核心概念,以便理解估算,树立正确认识,然后才能更好地解答以上2个问题。估算的4个核心概念所对应解决的问题如下表所示:问题估算核心概念问题一:团队只关心数字。利用“区分准确与精确”:估算应该准确,但不必过分精确。利用“估算相对大小”:人们更擅长对大小进行估算,而不是绝对大小。问题二:团队过度承诺。利用“团队一起估算”:在估算活动中,团队成员一起估算,结果更合理。利用“估算不是盲目承诺”:估算不是承诺,重要的是我们不能这样认为。区分准确与精确估算应该准确,但不必过分精确。比如,我们估算某产品是10888人时(是怎么做到这么精确的?)。其实这是很荒唐的,过于精确的估算纯属浪费。我们需要应该投入刚好够用的工作量,得到一个刚好的、大致正确的估值,如做估算时工作量和准确度的对比图所示:做估算时工作量和准确度的对比图在做估算时,有一个收益递减的点,在这个点之外,额外投入任何时间和精力都不会使估算更准确。在这个点之外,就属于浪费时间。团队成员在做一项工作的同时,难免会遇到各种各样的问题,所以为了做到准确估算,在做估算时,任务的拆分一定要适当细,只有细化后,团队成员才清楚每项工作预计会花多少时间。当然细化也是有个度的,如前面提到的做估算时工作量和准确度的对比。当团队成员反馈超过预计工时时,需要了解是不是遇到了什么困难,需不需要帮助解决。超过16小时的任务建议需要再细化。在做估算时,我们经常会填写预计工时和实际工时。预计工时是我们估算的结果,实际工时是对估算结果的检验。我们允许预计工时的不准确,但是一定要填写准确的实际工时,这样才有助于我们在估算不准的问题上有充分的证据做分析,然后改进,进行良性循环。随着团队成熟度的提高和对业务的越来越了解,估算准确度经过几个Sprint会有所提高。估算相对大小建议使用相对大小而不是绝对大小来估算PBI。比较所有条目,然后确定某个条目和其它条目的相对大小。如下图所示,讨论一个杯子相对于另一个有多大比较容易,但对于杯子中可以盛多少绝对数量的液体,我们可能没有概念。相对大小对比图人们更擅长对大小进行估算,而不是绝对大小。让团队成员做估算,建议用大家都擅长的技术。当然,有些较成熟的团队,也可以借鉴历史数据和经验,直接应用工时或理想人天估算也并非不可。更多关于相对大小的内容介绍,可以阅读下一篇《如何估算第三篇:估算故事点》,其中会介绍一个具体实践,即故事点估算。团队一起估算而不是个别人估算在估算活动中,团队成员一起估算,而不是仅仅由项目经理、架构师、主要程序员估算。简单说,是负责完成工作的所有人,也就是指实际动手设计、构建并测试PBI的开发团队来估算。产品负责人和Scrum Master这两个角色都在场,但并不实际参与估算。产品负责人负责阐述PBI,并回答团队要求澄清的有关需求的问题。Scrum Master负责帮助指导和引导估算活动。最终的目的是开发团队能够一起确定每个PBI的大小,当然包括开发和测试的所有工作量。团队成员一起估算也是为了确保工作没有遗漏,不管怎么拆分任务,甚至是不拆分任务以story为最小颗粒度,那就按照story可以上线为标准来估算。如果团队非常关注每个人手头上的task,比如测试和开发人员手头上的task,那就没有统一标准,根据具体task内容估算。 记录工作项工时,可以参考华为云DevCloud,工作项工时显示如下图所示。需要客观估算而不是盲目承诺估算不是承诺,重要的是我们不能这样认为。举一个例子,如果在估算的时候告诉团队成员他们的估算正确性直接影响着他们的奖金和绩效,那么每个人都会给出一个比开始大得多的估值。估算应该是较为实际的估值,应该靠谱,我们不想因为外因而人工放大估算值,变成团队成员往上加和管理层往下减的抛球游戏。所以,团队成员在没有外因干扰情况下,大胆、放心的估算工作量,也就是估算预计工时。预计工时不仅仅是用于安排任务和估算本Sprint PBI在哪个时间点完成的,它还可以用于持续改进。预计工时就是估算需要多少时间可以完成,在Sprint进行中,会让团队成员根据实际情况去更新实际工时。例如,昨天更新4小时,今天又更新4小时,那就把实际工时更新为8小时。当Sprint结束后复盘时,我们会整体看这些预计工时和实际工时的数据,主要是为了提升团队/个人估算水平。如果估算和实际有明显差距,是需要深入分析的。本身也是期望通过估算促进做简单设计。应用正确认知处理问题,做好估算以上是估算的核心内容。现在我们回头看看之前的两个问题。问题一:团队只关心数字。面对这个问题,作者主张团队成员不要只是关心数字,还要关心投入产出比(ROI),避免浪费。另外还可以考虑采用更快、更易于理解的方式来进行估算。从估算的核心概念“准确与精确”中了解到,在做估算时,有一个收益递减的点,在这个点之外,额外投入任何时间和精力都不会使估算更准确。在这个点之外,就属于浪费时间。另外从估算的另一个核心概念“估算相对大小”中了解到,人们更擅长对大小进行估算,而不是绝对大小。让团队成员做估算,建议用大家都擅长的技术。因此,我们在做估算时:首先,要把握一个估算的适度准确原则,不要过度浪费。其次,为了降低难度,团队更好的达成一致意见,可以采用相对大小方式进行估算。问题二:团队过度承诺。面对这个问题,作者主张估算由真正完成工作的成员在安全的环境下大胆、放心地估算,避免过度承诺。从估算的核心概念“团队估算”中了解到,估算活动是负责完成工作的所有人,也就是指实际动手设计、构建并测试PBI的开发团队来完成。也就是说,真正完成工作的人才会对工作需求内容更用心,也更了解团队的速率,他们的承诺更客观。估算另一个核心概念“估算不是承诺”中提到,估算应该是较为实际的估值,应该靠谱,我们不想因为外因而人工放大估算值,变成团队成员往上加和管理层往下减的抛球游戏。团队成员在没有外因干扰情况下(不建议奖金、绩效明显挂钩),大胆、放心的估算工作量。如果能做到以上相信至少在估算的结果上更为客观和靠谱。有些朋友可能会问,如果得到的估算结果是靠谱的,完成需求就是那么多工作量,产品上市日期也已经确认,那么怎么办?如果真的是因为产品上市日期已定,有上线压力,团队一定要承诺过多的工作内容,那么就确保团队把故事拆分得更细,即使他们交付不出设想中的高档理想的全功能版,至少也能每个典型的功能领域多少交付一些内容。说到这里,还是不建议这样做,尽量采用高价值的事情优先做原则,与客户协商,产品经理对需求排好优先级,优先实现高优先级的PBI。了解更多以上是针对不了解估算核心概念而导致估算活动不理想的解决措施。朋友们看到这里,相信对估算的核心有了基本了解。也许对什么是故事点估算以及具体估算方法感兴趣,欢迎阅读接下来的关于估算的另外两篇文章,即《如何估算第三篇:利用故事点做估算》和《如何估算第四篇:利用2种常见方法做估算》。参考附录Kenneth S. Rubin. Scrum精髓[M].北京:清华大学出版社。Mark C. Layton. 敏捷项目管理[M].北京:人民邮电出版社。Rachel Davies. Liz Sedley.敏捷教练[M].北京:清华大学出版社。附件:如何估算第二篇:利用核心概念解决估算常见问题V1.2.pdf**** 本内容被作者隐藏 ****
  • [技术干货] 【DevCloud · 敏捷智库】读懂敏捷需求管理的4个关键词
    我们常见到Epic、Feature、Story和Task这些和敏捷相关的概念,它们之间的关系是什么?我们如何灵活使用这些概念,从而让敏捷的需求管理更为高效?本文为你解答,建议收藏。什么是Epic、Feature、Story和TaskEpic、Feature、Story和Task用来划分需求颗粒度的标签,可以看作需求占位符,分别代表需求颗粒度从大到小。每个层级的需求本身又承载着一些意义,在进行需求划分的时候可以进行参考。Epic:史诗,是项目的愿景目标。通过Epic的落地达成,使公司可以获得相应的市场地位和回报,具有战略价值。通常需要数月完成。Feature:可以带来价值的产品功能和特性。相比Epic,Feature更具体,更形象,客户可以感知,具有业务价值。通常需要数周,多个Sprint才能够完成。Story:通常所说的用户故事,是User Story的简称。是从用户角度对产品功能的详细描述,承接Feature,并放入产品Backlog中,持续规划,滚动调整,始终让高优先级Story交付给客户,具有用户价值。Story要符合INVEST原则(Idependent, Negotiable,Valuable,Estimable,Small,Testable),通常需要数天,并在一个Sprint中完成。Task:是团队成员要完成的具体任务。在Sprint计划会议上,将Story分配给成员,然后由成员分解为Task,并预估工时,通常在一天内完成。  将上面的描述简单整理,如下表所示。它们之间关系是什么Epic-Feature-Story-Task是一种将需求进行结构化管理的方法,在使用时是从上到下逐层分解,形成自下而上的依赖。如下图所示。在实际的开发过程中,需求会发生变化,我们要不断的调整,在调整中避免偏离目标方向,每次新建需求的时候都要记得向上对齐到Epic,保证所添加的Story和Task和它们上层是有关联的,这样就可以在一定程度上保证团队在朝着目标前进。更多关于需求结构化管理的内容,请阅读【参考附录】【DevCloud· 敏捷智库】如何进行需求结构化管理?。我们如何灵活使用这些概念,让需求管理更为高效为了帮助大家加深对 Epic、Feature、Story和Task的理解,我们对一个案例进行需求拆分,过程中会结合项目管理平台进行展示,以华为云DevCoud为例。案例:某大型商超受互联网的冲击,营业额大幅下滑。为了减少门店消费者流失,保有市场地位和份额,决定用6个月的时间建立自己的网上商城。第一步: Epic确定和创建根据前面的介绍,在进行需求确认的时候先看颗粒度,然后再考虑其承载意义。※思考:一个产品是一个Epic吗?产品的每个业务模块是Epic还是Feature?产品通常具有战略意义,从这个角度看,产品适合作为一个Epic。但是不是所有的产品都适合,还要看产品是什么,它的颗粒度有多大。在本文的实例中,网上商城周期是6个月,目的是保有市场份额,从颗粒度和战略意义上,网上商城适合作为一个Epic。每个业务模块具体是Epic还是Feature要分情况。比如:构建智慧城市是一个愿景目标,下面包括智慧交通,智慧政务,智慧社区等,这些每个业务模块都很大,用Epic进行需求占位合适一些。我们在DevCoud创建一个Scrum项目,命名为某大型商超网上商城,进入到【需求规划】的界面,在【Epic】下面新建,如下图所示。新建之后,点击进入到详细编辑界面。将描述信息填写完整,可以使用DevCloud提供的模板,如下:作为 <用户角色> ,对于这个Epic来说,用户角色是整个公司。我想要 <结果>,想要的结果就是建造网上商城。以便于 <目的> ,目的是想要减少消费者流失,保有市场地位和份额。同时在基本信息中设定这个Epic的起止时间,优先级,重要程度,预计工时等信息。这些信息对于团队理解产品、理解项目起到至关重要的作用,所以要填写详细。编辑界面如下图所示。第二步:将Epic分解为Feature客户要求在6个月内交付5个功能模块:促销管理、会员管理、订单管理、配送管理和客户端。团队的一个Sprint是2个星期,每个模块大概需要2-3个Sprint完成,从颗粒度和承载的意义,这5个模块适合作为Feature。创建如下。创建之后,如需要填写详细信息,可以在详细页面进行编辑。界面信息项和前面Epic的相同,此处不再赘述。第三步:Feature分解为Story敏捷开发是渐进明细的,不要求所有需求在相同时间做到同样详细,只要求当前Sprint和未来的一个或两个Sprint的Story是详细的。将来Sprint的Story可以是一个大概的情况。进入到当前Sprint的Story要符合INVEST原则。开发团队要在Sprint结束时完成交付。客户优先级中,会员管理Feature优先级高,会员管理这个Feature就要在需求梳理会议上详细分解为Story放入到产品Backlog中。经过分解后,需要包含和管理员相关的以下功能: 积分管理、会员级别管理、用户分析、用户管理。这些具体的功能就可以作为Story。需要注意的是,我们分解出的Story要尽量在一个迭代内完成交付,如果无法完成就尝试继续分解。因为只有交付的Story才是有价值的,无法交付的Story对于当前Sprint来说就是浪费。分解后的Story如下图所示。第四步:将Story划分为Task在Sprint计划会议上,团队和PO要共同从产品Backlog中按照优先级顺序选择本次Sprint需要完成的Story,进入到冲刺Backlog中。团队成员认领后,将Story分解为Task,并进行估算。※思考:Story和Task如何区分?Story聚焦价值,需要在Sprint中完成,要用数天的时间,要符合INVEST原则。Story的描述是一个名词,如积分管理这个Story的完整描述是:作为管理员,我能够进行会员的积分管理,以此来划分消费等级提供不同增值服务。Task聚焦实现价值,通过过程性的任务来实现Story的功能。通常是1-8个小时。Task的描述是一个动作。如积分管理这个Story,功能的实现需要通过业务逻辑开发,积分规则设计和积分数据库设计这几个过程来完成。这些就是Task。如下所示。这样,从Epic开始,到Task结束,我们完成了网上商城的需求拆分。总结:使用Epic、Feature、Story、Task管理需求时,需要注意以下几个方面。1.敏捷开发中需求是逐步细化的,遵循自上而下的方式去分解需求。2.Epic和Feature都是颗粒度比较大的需求,是用户对于产品的期望和功能特性的描述。3.分解为Story的时候,目前正在进行的Sprint需要分的更小更细,将来的Sprint需求(可能是3个及以上)就不需要那样细分。当进行到某个Sprint时,再进行分解,细分成一组更小、更细的条目。4.只有当前Sprint的Story进行Task分解。5.所有这些粗略和详细的Story都放在产品Backlog中,整个列表要遵循DEEP( Detailed appropriately, Emergent , Estimated , Prioritized )原则,定期梳理和排序优化,保证高优先级的需求优先实现和交付。6.在整个过程中需要和客户一直保持沟通合作,这样才能保证我们实现的功能是客户真正想要的。写在最后本文通过一个用户场景来帮助大家理解Epic、Feature、Story、Task的含义以及如何使用。因为没有相同的项目,所以在开发过程中还要结合产品和业务本身的特点,进行具体问题具体分析。为了更好的分析问题,我们需要扎实的掌握Epic、Feature、Story、Task的含义并理解他们之间的关系。相信随着大家深度使用,一定能运用的得心应手。敏捷路上,你我同行!参考附录1、Kenneth S. Rubin. Scrum精髓[M].北京:清华大学出版社。2、Mike Cohn.用户故事与敏捷方法[M].北京:清华大学出版社。3、【DevCloud· 敏捷智库】如何进行需求结构化管理?4、文章博客地址:https://bbs.huaweicloud.com/blogs/142259附件:【DevCloud•敏捷智库】读懂敏捷需求管理的4个关键词.pdf **** 本内容被作者隐藏 ****
总条数:272 到第
上滑加载中