日思清单|日思清单 0722 敏捷开发日思清单0722敏捷开发

敏捷宣言
个体和交互胜过过程和工具
可以工作的软件胜过面面俱到的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
虽然右项也有价值，但是我们认为左项具有更大的价值。

文章图片
Paste_Image.png
拓展应用
敏捷营销
敏捷组织，透明化扁平化管理
敏捷洋葱圈

文章图片
Paste_Image.png 敏捷关键
用户故事：卡片和对话，验收确认符合用户需求
编写用户故事：
我作为（角色）
想要（功能）
以此实现（价值）
例子

时间视图支持直接创建任务的起止时间
我作为项目经理，希望在时间视图上可以直接创建任务的起止时间，方便我能更快捷地生成项目计划。

文章图片
Paste_Image.png 估算用户故事，故事点是故事复杂度、工作量或工期的相对估算
scrum一个框架，解决复杂难题，同时也能高效并创造性地交付尽可能高价值的产品。为了最后的同一个目标

文章图片
Paste_Image.png
3个角色，3工作，5事件，5价值观

PO（产品负责人） SM （团队的导师和组织者） Team
PB （项目规划） SB（待办事项） Increment（复盘情况和关键节点）
sprint（迭代）planning DS（每日站会） review（评审会议）retrospective（复盘）
目标、合作、勇气、分享、记录

看板方法（看板不仅仅只是一个可视化的系统）

价值流映射
使用看板进行协调
建立交付节奏
设置在制品限额
建立服务水平协议
度量和管理报告

敏捷团队
快速交付商业价值
四个人不同的价值观
生活在一起
经历81难成功IPO
西游记中的团队角色
猪八戒：资深用户、最懂用户、知道用户要什么（产品）
孙悟空：开发和运营
沙和尚：任劳任怨的团队协作者，测试运维和行政
唐僧：风险最大，背黑锅我来，送死你去。不可动摇的信念
集齐了龙珠，我就可以改变世界吗？
误区1 scrum=敏捷，Agile（scrum、kanban、xp、FDD 、Crystal、DSDM 、LSD）
误区2 敏捷是万能的团队干不好不是因为没有敏捷
误区3 关注闲置人员，而非价值输出。举一个接力跑的例子
误区4 追求“大而全”
协作的小技巧
1、团队的成员尽可能坐在一起
2、统一的协作工具（teambition）
3、统一协作规范（就绪的定义、完成的定义等等）
4、说真话，并鼓励团队说真话
5、暴露问题，解决问题。问题无法出现也就无法解决
选用良好的技术实践

测试驱动开发，写代码前写单元测试
重构，安排专门的版本周期进行重构
代码审查
持续集成，一定要有自动化编译、构建、发布、部署的工具
每日发布，以此作为进度依据
实施编码规范
自动化测试

有关理解敏捷背后的原因，这个游戏让我能够深刻的理解到敏捷的好处

文章图片
Paste_Image.png
我所在的组别是绿色的第三组。
每批次12张总共需要分三次传递完，我处于中间的位置，前面等待的时间特别长，我回过头看看后面的团队，想流水线一样快速传递，交付版本1，2，3，4，5非常迅速。到我们组，我才刚刚开始传递，传递过程中也发现许多问题，纸片堆杂在一起，画笔在手上画了几条杠，同时后面人也开始焦急，开始帮我在理清纸片分发到下一个人。后面虽然也用了一些提高效率的方法但依然赶不上，这时候我前面的人已经开始闲置了，我把我手中纸片全部传递出去之后，每批次只传递一张纸片的的小组已经结束了。
总结
1、快速交付版本可以每个人的协作效率提高，等待的时间少
2、老板和项目经理可以最快时间拿到第一版本，只需要几秒，相差了几十倍的效率，如果放到实际的开发场景中相差的时间可能更多
3、实际开发中经常存在一种情况就是，先出原型，然后UI，技术。一条线到底，必须要等原型基本出来了，美工才能开始做，界面出来了技术才开始做。要提高效率一个任务并行，一个是把任务拆分，以功能或单元为单位，向下传递。
4、我们组的情况其实体现了老板焦急等待第一个版本的情况，第一个版本等待太久，同时老板只以结果为论，等的太久就是不行，做不出来加人做行不行，总之一定要在规定时间内完成。但如果是小步反馈反复迭代就不一样了，能看到软件慢慢的变得完善了，同时隔几天就有一点小进展。
5、混乱的等待时间里不知所措的其他人，相比于其他组，我们忙的时间点非常集中并且效率很高，但是放到整体团队就不行了，每个传递个体效率最高的时候其他人是处于闲置状态。
敏捷团队的螺旋式成长