作者小头像 Lv.3
454 成长值

个人介绍

华为云MVP、云享专家、国际ITIL认证、信息系统项目管理师认证、高级软件开发工程师,主导开发多个企事业单位大型项目

感兴趣或擅长的领域

人工智能、大数据、云计算、DevOps、微服务架构
个人勋章
  • 考证狂人
成长雷达
40
54
175
165
20

个人资料

个人介绍

华为云MVP、云享专家、国际ITIL认证、信息系统项目管理师认证、高级软件开发工程师,主导开发多个企事业单位大型项目

感兴趣或擅长的领域

人工智能、大数据、云计算、DevOps、微服务架构

达成规则

发布时间 2020/12/01 14:39:20 最后回复 蜡笔不辣 2020/12/30 18:51:29 版块 开发者学堂
11512 222 2
发布时间 2020/02/03 14:26:27 最后回复 龙波 2020/03/15 23:07:42 版块 社区活动
41347 239 0
他的回复:
微信昵称:牛头哥华为云账号:yichaooDAY05:彼岸-组织变革 踏入坦途一、敏捷估算敏捷使用的估算单位是故事点,故事点是一个相对数,不是一个绝对数敏捷估算过程有一个叫扑克牌游戏的方法,采用出牌的方式来展示每个人的估算结果,通过讨论团队得出一个大家都认同的估算值每个人估算的差异虽然很大,但是群体智慧往往会超过个体的智慧二、计划与交付速率敏捷是一种迭代的开发,可以通过观察团队在头一两个迭代中可以实际交付出多少故事点,来预测团队的交付速率所有故事点需要多少个迭代,这是scrum里面迭代的周期是固定的,有多少个迭代就有多长时间;通过燃尽图:观察团队的交付速率,再及时作出调整。三、看板方法累计流图:找出那个工序是排队最长,存在瓶颈以外的过程,可以帮助到我们去观察和改善流,从而识别潜在的问题和风险延迟成本:损失折换成金钱,去量化所有请求优先级,延迟成本计算非常复杂服务等级:针对请求的服务等级做出不同的响应,第一类加急类:走加急通道,最高优先级,可不受WIP限制,最多同时只能有一个加急的工作项;第二类是固定交付日期类:处理一些固定日期的请求,在截止日期前必须交付;第三类是标准类:直接按照先进先出的顺序进行处理;最后就是内部技术改进类:无形类;
发布时间 2020/02/03 14:26:27 最后回复 龙波 2020/03/15 23:07:42 版块 社区活动
41347 239 0
他的回复:
华为云账号:yichaoo微信昵称:牛头哥Day4:探路-敏捷深化 迈向常态一、实例化需求可以解决需求理解不一致的问题,并通过具体例子描述验收条件团队将验收条件转换成测试用例,对可交付成果进行提前的验收测试清楚的定义了客户需求和验收标准,提高验收概率二、行为驱动开发以用户行为作为视角来进行测试驱动开发基于和用户约定的验收测试用例去编写自动化测试通过API进行开发和测试,整个交付形成闭环三、微服务架构将复杂的、难以维护的单体系统,拆分成繁杂的、容易维护的微服务每个应用可以采用不同的开发语言,各自独立开发、部署和扩容每个应用的职责单一、松耦合,和其他应用通过远程接口调用,没有代码依赖四、契约测试提供API的一方称为提供者,调用API的一方称为消费者双方约定好API接口,根据契约来开发双方通过运行这份契约来测试彼此是否满足要求五、团队组织形式与特性团队基于主干开发:传统开发模式会拆分很多不同的分支,一旦分支之间差距很大,尽量只维护一个分支,做到每日合并.团队干系人优先级:对团队进行重新整合,使得每个领域和需求有清晰的需求和优先级,组织变化要打破职能的形态,考虑对业务的对接,使得对端到端的交付整体负责.特性团队:负责这个系统的端到端的开发\运维\交付的全流程,开发、测试、运维等他们都包含在内.
发布时间 2020/02/03 14:26:27 最后回复 龙波 2020/03/15 23:07:42 版块 社区活动
41347 239 0
他的回复:
华为云账号:yichaoo微信昵称:牛头哥Day03:触礁-项目试点的各种问题一、项目试点中出现了问题:实际开发过程依然是瀑布方式开发进度比计划要慢需求文档质量不高逾期交付、质量低下客户不满意二、拆分项目到用户故事保障持续交付用户故事对敏捷转型是非常重要的。用户故事必须是具有一定业务价值的、可以单独上线的、最小的需求。把用户故事持续上线就是持续交付的过程。可以项目拆分多个用户故事,把每一个用户故事作为一次发布实现持续交付从左至右按时间顺序罗列用户行为,在每个用户行为从上至下地罗列相应的细节,找出最小可用用户产品MVP三、XP极限编程计划游戏:将整个项目拆成几天到几个星期的多个迭代小型发布:每个迭代都发布给用户,用户可以提出反馈,增加用户故事现场客户:用户跟交付团队始终在一起,参与项目测试驱动开发:编程前根据用户故事需求写好测试。通过测试验证代码是否满足需求持续集成:每天代码提交都做一次集成重构:不改变功能和外部结构,进行代码优化代码集体所有权:所有人都可以重构简单设计:越简单的设计越不容易出错结对编程:解决写代码,单元测试和代码评审的时序问题系统隐喻:用客户和交付团队都能理解的语言编写用户故事需求四、看板方法:进度可视化限制在制品WIP:在每道工序限制并行任务数量。观察和改善流动:观察哪里是瓶颈进行改善,以全局的视角提高交付过程