敏捷教练(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
怪不得看着感觉这么熟悉，是Martin Fowler的书么？
公司的开发一直在改，太菜了，我这个测试非常无奈
先做好运维，再做运维开发。zabbix,elk,ansible，docker,k8s这些工具自带的功能基本够一开始用了。业务驱动
用了这么多PM工具，Atlassian JIRA Confluence + 插件是挺好用的，这个平台就是JAVA开发里的一个很牛产品
ThoughtWorks 了解一下
