敏捷教练(scrum master)
1.敏捷开发概念(对比传统瀑布式开发)
从需求到设计
设计到编码
编码到测试
测试到提交产品
瀑布式缺点: 需求经常改,开发人员做增量交付,迭代式开发,并能够持续发布
以用户需求为核心,进行迭代,循序渐进进行软件开发
敏捷强调适应性而非预见性
项目需求发生变化, 项目团队快速响应交付
软件开发初期会切分成多个子项目,各个子项目的成果都需经过测试,具备可视化,可集成,可发布
主体软件随时可发布,可交付给用户
2.敏捷开发人员架构划分
部门->项目组->小团队
8-10个人的小团队
小团队里有四个角色
PO:product owner 产品或业务负责人(产品经理或项目经理) 确定产品前景原景 定义产品发布内容 交付任务的优先级 交付时间
SM:Scrum Master 敏捷专家 (team leader) 熟悉敏捷开发模式和实施流程
DEV:开发人员
QA:测试人员
3.敏捷开发相关的四个会议
1.敏捷计划会 一个月一次月初 一个迭代开一次 任务明确 需求划分 故事点划分(小的任务点 1-3天完成的)
迭代或冲刺:Sprint 周期 一个月 所以每年12个迭代
2.每天立会 对着任务展板 说 从昨天的立会到现在,我完成了什么.从现在到明天立会,我计划完成什么.有什么阻碍了我的进度,风险和困难抛出 让leader进行抉择
我这边进度正常,没障碍
3.敏捷评审会
向客户和利益关系人展示 团队在本次迭代中完成的工作并获取客户的反馈
4.敏捷回顾会 一个月一次月尾
每个迭代结束时进行,总结工作中的经验和教训 30-60分 整个团队参加
1.定量分析
迭代是否完成目标
收集评审迭代的度量指标 wiki的工具链上做
2.定性分析
主观化的 那些好的保持 不好的停止 改进的,提建议,在下一个迭代改进
4. 平时写代码怎么样的, 任务如何完成
立会上领取故事点(任务点)
跑测试用例,功能测试完全通过才能push
ci流程 代码质量的保证 不通过重复上述流程 跑过了进入team leader那进行代码评审code review 不通过 在循环改代码直到通过 入库 闭环反馈机制操作
合代码宗旨
人与人不影响 最大程度隔离 做任务能全速推进
任务与任务中间不影响
不需要每个人任务做完,主分支才能交给客户,随时随地交付
敏捷是一种科学做事的方式
从人员划分 开会 故事点划分 编码里的守护防护系统 开发和代码评审的方式
circle ci
目前参与过公司的项目，公司专业从事敏捷开发，也比较成熟，可以分享下其中的细节。
1、概念，可以参考敏捷宣言，强调适应变化，四句指导
个体和互动 高于 流程和工具（动员每个人积极交流，相互之间可以 battle，头脑风暴）；
工作的软件 高于 详尽的文档（好的代码是不需要注释和文档的，顶多有一些规范指南一类的在线协作文档）；
客户合作 高于 合同谈判（真心实意为客户创造价值，而不止于眼前的功能交付，这个很难，由此还专门有一个角色去 control 这件事）；
响应变化 高于 遵循计划（计划是赶不上变化的，随时改需求随时变动迭代计划，有迭代的概念）；
基于于右边，而更注重左边的价值，并不是说完全抛弃传统的瀑布式开发。
2、人员架构
因为公司没有所谓的各种领导，这里就说下交付组里，我所见的一些角色，也是每天在一起工作的小伙伴：
PM：项目管理者，这里不是项目经理，负责和客户签合同，各种会议的组织者，没有项目经理那种权利
BA：业务分析师，专门和客户谈需求，超强的交流和控制客户的能力，几乎每天都和客户泡在一起开会过需求，疯狂开会，驱动客户（我们组的BA是御姐型的，气场极强）
QA：测试人员
DEV：开发人员，其中有掌握技术话语权的 TL
PO：比较特殊，是客户某的部门领导人，一般和 PM 单独沟通，几乎没出现过，网友一样的存在
一个团队一般 1 PM、1 BA、1 QA 、6 DEV (三前三后，至少两个TL)
这里没有 MS，所以每个人都是 SM，233333
IPM：迭代会议，每个迭代开始之前开一次，主要是排下个迭代的故事卡，并给每张卡估点，我遇到的是两周一个迭代（一般会有卡墙，有物理的，也有线上的）
Showcase：开发成果展示，每个迭代结束开一次，一般是BA或QA给客户演示上个迭代做的功能，当然也是优化和新改动提得最多的时候
Retro：回顾会议，每个迭代结束开一次，讨论上个迭代团队做得好和做得不好的事（不是针对和人，不含人身攻击），并给出改进方案，在下个迭代中执行
Stand Up：每天早上的站会，大家站成一圈，一般由 PM 主持，轮流阐述自己的昨天工作内容和工作进度，和今天要完成的工作，以及遇到的一些问题，及时反馈出来（我们组有个小龙猫的毛绒玩具，大家挨个传递，挨个阐述）
每天还有 Code Review，动态安排时间，我们团队一直坚持，刚开始是前后端一起过昨天每个人写的代码，后面时间太长，就前后端分开。大家一起来找茬，你的命名和代码逻辑划分，代码风格，都有个能会被挑刺。在相互找茬的过程中，坚持下去，对个人的成长有很大很大的帮助。
4、写代码
DEV 要做开发，就要先领故事卡，俗称开卡，自己选好一张故事卡，拉上BA和QA去过其中的细节，理清细节，然后才能上手开发，开发完后再拉上BA和QA去结卡，检查卡中的功能是不是都完成了，有问题就被打回去改，直到BA和QA觉得完善了，才能关卡。。。
代码质量要求很严格，遵循 TDD，前端有 lint，有单元测试（不能偷懒，而且有覆盖率要求），有 e2e 测试（必须写，和QA一起看），当你的代码走过这三个流程，提交到公共仓库，CI 自动构建会拉你的代码，再走一遍测试（挂了就要修代码），然后自动发布新版本到 Dev 环境。
你以为这就完了？还有代码嗅探器，时刻在扫描代码仓库，有两个重复的函数不行、重复率太高不行、使用了骚代码去做类型转换之类的不行、空间内有命名重叠不行。。。。这一套下来，再加上 code review，菜鸟开发每天一半的时间都在改昨天的代码。
项目还有规定，CI 不能红过夜，当天的问题当天要修好。。。。
以上这些，小公司就别说什么没时间，项目吃紧，然后就没做，自求多福吧
这些都是我所经历的，敏捷实践各不相同，大家看看就好
怪不得看着感觉这么熟悉，是Martin Fowler的书么？
公司的开发一直在改，太菜了，我这个测试非常无奈
先做好运维，再做运维开发。zabbix,elk,ansible，docker,k8s这些工具自带的功能基本够一开始用了。业务驱动
用了这么多PM工具，Atlassian JIRA Confluence + 插件是挺好用的，这个平台就是JAVA开发里的一个很牛产品
ThoughtWorks 了解一下
扫一扫
1720
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
