敏捷开发分享-暂存

前菜：

亲历者说：敏捷？我被洗脑了吗？

https://insights.thoughtworks.cn/brainwashed-by-agile%EF%BC%9F/

敏捷宣言：

http://agilemanifesto.org/iso/zhchs/manifesto.html

wiki：

https://zh.wikipedia.org/wiki/%E6%95%8F%E6%8D%B7%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91

2018年 6月，参与一次DevOps Open Day后的感受：

当我有天对这些流程游刃有余的时候，发现是这样的场景：组织分工合作，各司其职。强调沟通和合作，不仅专注于自己所在的需求，也会去关注同事的，好处是——当你的实现需要了解另外的业务你就能迅速地找到可以帮助的同事，而且你在设计的时候可以站在更整体的角度，考虑得更合理，避免后期出现的不匹配；各种角色互动，有参与感。管理层实时了解当前开发和测试的进度，有着可靠的版本计划，背后就是敏捷流程和工具的支持。并且开发遇到问题可以向管理或测试求助，高效地响应会很帮忙；其实就在工作有那么一段时间，这样很和谐的状态，让我觉得很舒服又有动力去工作，因为喜欢这种状态，凝聚但又各有空间余地。

极限编程关于“工作量预估”的讨论：

Scene：敏捷看板任务领取后，总会因为临时任务耽误、延迟，这个情况怎么应对？
大佬：
不要 估计时间
速度 是 事实
观察时间 就行了

1. 估算只估点数，不估时间
2. 一个迭代做完，做了20点，下一个迭代就继续计划20点
3. 如果20点不够，要30点，团队可以想团队的办法，老板也可以想老板的办法

Q：那点怎么去衡量呢？经验不同，每个人给出的点数，也不一致呢
A：点是个相对量，立个基准参照系就可以
大佬： 任意拿一个卡放地上，
比他大的放他左边，比他小的放他右边
跟他一样大的和他并列
所有卡这样摆好，从右向左，依次是1 2 3 5 8
大于8的拿回去拆分
多简单

ps： 我就不明白为什么这么简单的事大家能纠结这么多
因为没想清楚
一直把 工作量 和 时间 搅在一起

----
估算能提高效率
正如
测试能提高质量

你们想，时间肯定是不准的。从task、story、迭代、release、阶段工期… 粒度越来越大，越来越粗糙和不准，所以即便有时间估算，也仅仅是为了更便于做计划、立个心理预期和安慰线。所以目标只是目标，不是结果。

Q：我理解了，以20个点为例子，
比如第一次迭代团队完成20个点，需要2周时间，算上中间插入的事情，其他事情等
第二次迭代，团队完成20个点，只需要一周半，这个其实就是效率的提升了，优化的是每个迭代的处理的时间，我的理解对吗？
大佬：对
A：估算有个很重要的作用，是为了理解需求，而且是全员都理解并达成一致的理解。不仅仅是为了对工作量进行预期。

彩蛋：

　　被踢出去的用户

　　https://mp.weixin.qq.com/s/7qnMwKgAc3r8Z60acy4XJg

　　关于问题定位 —— 需要逻辑推理思维，需要练习。单讲有点枯燥