敏捷落地实践
2019-02-22 14:20:37 1 举报AI智能生成
为你推荐
查看更多
ThoughtWorks敏捷落地实践
作者其他创作
大纲/内容
敏捷落地实践
敏捷概念阐述
什么是敏捷
以人为本
团队合作
快速响应变化
可工作的软件
敏捷宣言回顾
个体与交互 优于 流程与工具
客户协作 优于 合同谈判
响应变化 优于 遵循计划
可工作的软件 优于 面面俱到的文档
敏捷思想的核心
高度协作
不间断的及时反馈
自我调整与完善
敏捷宗旨
减少浪费
敏捷最佳实践
围绕迭代
Iteration通常始于IPM ，止于Showcase
每天都会发生事件有Standup
Pair、TDD、Code Review穿插在日常Coding中
Story kick-off之后，该Story就进入了开发环节
CI属于基础设施，通常在一个名为Iteration0的迭代完成，也就是正是开发开始之前就应该完成CI的搭建
Retro较长一段时间才进行的活动，根据实际情况，1个月或两个月举行一次
Regular catch up with client也会因项目而异，Daily或者Weekly，甚至某些项目可以省略该项活动
迭代周期图
敏捷落地
角色
PM，项目经理
BA， 或产品负责人
TL， 技术负责人
QA，测试人员
DEV， 开发人员
UX，用户体验设计师
敏捷实施阶段
IPM：Iteration Plan Meeting，迭代计划会议
参与人员
PM，BA，TL或其他成员
内容
跟客户保持沟通
周期
依照敏捷迭代周期
沟通内容
下一个迭代的Story
对下一个迭代的期望
团队的人员可用性
风险的评估总结
目的
让客户对团队状况有一个清晰的了解
使客户对我们下一个迭代要做的功能有整体的把控
与客户一起设定好期望， 大大降低风险
主要产出
明确下一个迭代的Story
可通过看板（白板）工具来管理
项目进度信息更新
Regular catch up with client，与客户定期沟通
主要参与人员
BA（PM），TL
团队昨天的更新
客户昨天的更新
确认Story，如果有变更，能及时作出调整
提醒客户使用我们开发出来的功能，以便我们尽早得到反馈
一些节日的问候，嘘寒问暖，表达我们团队的关怀
方式
面对面
线上电话
时长
短会
产生价值
使客户有非常强烈的参与感
让他们对项目整体进展有把控
增强客户的信心
增强客户对我们团队的信任
让客自己决定功能实现，并能及时验收功能，降低需求变更和打回的风险
在客户良好信任基础上，保持合作关系的轻松愉快，为项目成功交付起到润滑的作用
Standup，每日站会
全体人员
建议5~15分钟
昨天完成的工作
今天计划做什么
面临什么阻碍
自己手头Story的进展
是否存在技术风险
产生的价值
让大家进入一天的工作状态
清楚自己的Story的进展，提醒自己把握好时间，或者激励其他成员的开发进度
让团队成员知道项目其他地方的进展
如果谁遇到不好解决的问题，可以将问题抛出来，大家一起积极讨论解决方案，也能寻求其他人员的技术支持
避免在重复造轮子而耗费时间，让大家知道目前团队中可供复用的解决方案
帮助Team Leader了解哪些领域需要更多的帮助，从而更好地分配资源
Story Kick Off
BA，QA，DEV
会议内容
启动Story
让BA、QA及DEV对Story的理解一致，并严格按照AC来验收
Story由BA或产品预先写好
通过专业的敏捷管理工具进行管理
BA向DEV这个Story要完成的内容，以及其AC
DEV如果对Story有任何疑问，可以当场提出
DEV在后续开发中，如果有任何疑问，及时想BA或QA了解清楚， 切不可猜测
核心目的
确保DEV开发的内容符合客户期望
有效的避免Dev自行臆测业务需求而产生的浪费
能够弥补BA在编写Story的时候技术视角的一些遗漏
如何实践
DEV自己先完整的过一遍Story的描述
DEV给BA和QA去讲这个Story的功能以及AC
要能够清晰的讲出来，并且三者达成一致，如果有疑惑，需要当场得到解决
DEV将Story惨遭AC拆解成一系列的任务列表，并且逐一干掉他们
常用工具
trello
teambition
mingle
Pair，结对编程
概述
两个人同时工作在同一个Story上
两个人一起讨论Story的解决方案
两个人共同完成代码的编写
本质
在开发过程中不断的code review
价值
最大化知识共享
业务知识
技术方案
解决问题思路
快速带领团队新人成长，提升团队整体战斗力
提升代码质量
结对人的思维碰撞能够避免很多代码小聪明和不好的编码习惯
良好实践
可以选择技能和经验相当的搭档
有新人加入时， 可以选择比较有经验的老人，老人尽量只提供思路，让新人多思考多动手
定期更换pair
遇到技术障碍时，分头查找解决方案，并一起决定采用何种方案
TDD，测试驱动开发
好处
有效降低缺陷率
从宏观上把握Scope，开发人员不会在开发的过程中扩大或偏离Scope
提高代码设计
确保功能不会被遗漏
门槛
TDD实践存在一定的门槛，TDD更多地考察一个人的设计能力，所以需要有一定经验的开发人员
Code Review，代码审查
时间成本
开发人员聚在一起审查代码，会有一定的时间成本
如何提升review的产出
团队一起拟定一个开始时间和时长，并落实到位，保证团队成员的参与度和Focus
短时间的描述自己的Story业务，主要Focus在代码上
持续跟踪记录，并获取反馈
必要的时候拉长时间，条件允许下建议在一个有大显示器的会议室中进行
遵循原则
规模很小的团队，可以适当减少Code Review的时间和频率
团队经常Switch Pair，可以适当减少Code Review的时间
安排在下班前进行
经过一天的高强度的思考与编码，适当停下来，看看其他人写的代码，同时将自己代码讲解出来，还能意外的获得一些灵感，或许能解决自己面临的阻碍（你所面临的问题可能已经被其他人解决了）
如果这个时候发现代码的坏味道，需要改进的地方，下班后可以花少量时间作出更改
让每一个人提高警惕：自己写的代码并不是只有自己看的，所以要督促自己做好
共同找出代码的坏味道，及时做出改正，提高代码库的质量，有助于后期扩展和维护。
命名规范
代码整洁
API内聚性
让团队成员知道他人在做什么以及怎么做，分享好的编码习惯和技术实现，有助于团队整体进步
Showcase
目标
客户
给客户演示上一个迭代已经完成的功能
及时得到客户的反馈
确认团队的产出是否满足客户的期望
降低需求变更返工的风险
时间间隔
基于迭代周期
涵盖的内容
跟客户确认上一个迭代的Story列表
项目目前的交付状态。是否正常进度，会不会延期
演示上一个迭代完成功能。在线系统演示，需要一个staging环境
客户对功能确认，对达到期望的story签字，反之。我们记录下问题，并修改，再次确认签字
重要性
Showcase在敏捷开发中是一个不容忽视的环节，它契合了敏捷宣言中的拥抱变化优于遵循计划
Showcase能够让团队在每个迭代完成后及时从客户那得到反馈，对变化做出快速的响应，避免了劳动成果的浪费以及方向的偏离，也能最大化让客户的期望得到满足
CI，持续集成
通过自动化对开发人员提交的代码提供快速的反馈
通过自动化来实现高效的部署
大大降低代码集成及项目交付风险
最佳实践
开发人员对自己编写的代码添加足够的测试覆盖率。这是基本，基本最无敌：一来验证代码的正确性，二来防止被误更改
每个人提交代码到代码库之前在自己的机器上保证单元测试都能通过，很耗时集成测试和E2E测试可以更多的交给CI去跑
CI定期检查代码库的更新，只要有更新，就要运行所有的测试。这里有个权衡：不耗时的单元测试每次全部运行，集成测试也要频繁的运行，耗时的E2E测试可以稍微执行少一点（比如设置夜间执行）。我们这个项目，是每次检查到更新就会运行所有的测试（单元测试+集成测试6分钟，E2E测试30分钟）
CI如果没有通过，所有人都应该停止向代码库中提交代码，直到CI被修复，所以如果CI挂了，能够及时通知相关开发人员，要第一时间修复
所有测试通过之后，CI负责自动化部署到不同的环境（Test，开发团队测试环境；Staging，客户ShowCase环境；UAT和Production，用户验收测试环境和生产环境，通常开发团队没有权限），并正常启动所有的服务
Retro，Retrospective，回顾会议
团队专注于交付目标，埋头干活的同时，也要懂得停下来总结过去，并更好地抬头看路。
确保当前会议是人人都可以自由表达，发表意见的会议，在这里没有leader或普通成员之分
建立几项总结指标
well
less well
suggestion
action
使用贴纸写下对应内容，贴到白板的对应指标下（编写时间控制在5分钟）
每一条过对应指标下的贴纸内容
对less well栏中的同一类问题，归总起来，总结出相应的解决措施
将action栏中的贴纸，指派人，并落实
最核心的产出
分配指定人员后，需要落实执行， 并持续跟踪
理念
总结过去，做的好的方面继续保持及加强
做的欠佳的方面一起讨论改进措施，并尽全力落实
回顾会议让团队在实践中摸索出适合团队的最佳实践
引导团队和个人不断自我完善，追求卓越
术语描述
PM：Project Manager，项目经理
BA：Business Analyst，业务分析师
TL：Technical Leader，技术领导
QA：Quality Assurance，测试人员
DEV：Developer，开发人员
UX：User Experience，用户体检设计师
AC：Acceptance Criteria，验收条件
UAT：User Acceptance Test，用户验收测试
Retro：Retrospective，回顾会议
TB：Team building，团队建设
0 条评论
回复 删除
下一页
