欧几理得
ACT敏捷教练工具箱
思维发条
Wand的文章和视频集锦
敏捷开发资源大全
搜索文档…
此生只为听天籁,坐拥书城看落花
2022
2021
12
11
10
09
08
07
06
05
04
03
02
01
2020
12
11
10
09
08
07
06
05
04
03
02
01
2019
12
11
10
09
08
07
06
05
04
03
02
01
2018
12
11
10
09
08
07
06
05
04
03
02
01
2017
12
11
10
09
08
07
06
05
04
03
02
01
2016
12
11
成规
敏捷
看板
引导
视觉
故事
游戏
感时
乃有感,乃有形
关于需求端到端的一点思考
Change Canvas
Job Mapping-一种需求工作坊
RADKAR
我
主语和话题对于“用户故事”的用处
乾卦与变革模型
being
欣赏式探寻的原则
给团队一只笼子
整合,关于思考的方向
一种拆解套路
一次核酸检测后的价值流动思考
回顾会议最高指导原则
主动/被动
进球的环节:需求该由谁来写
我所理解的需求澄清
水平线工具
科技、业务进化的维度化管理
敏捷宣言签署者及其流派
时间的波粒二相性
绪事
一小步
散记
隐喻盒子
2021
无他
附着
未明事
0,选择
1, 一些未归类的内容
由
GitBook
提供支持
进球的环节:需求该由谁来写
-0-
之前写过的
我所理解的需求澄清
里,提到了踢球的隐喻。踢球怎么踢?球会流动,从一个人的脚下,传到另一个人的脚下。像极了“工作流”。如果最后一个人进球,那就妥妥是我们期待的价值流啊。软件开发的过程向其他行业学习了不少。比如像踢球的这一套。足球里我们叫后卫、中场、前锋,软件开发里就叫BA、开发、测试。或者分得更细致一些,有前端开发、后端开发。依次传球,期待进球。流程决定一切,角色不停加强。难道没有人注意足球多年以前都不这么玩了吗?
瀑布这么玩,敏捷还是这么玩。以至于我们经常被问到,需求该由哪个角色来写呢?你看,要求得这么复杂。不是听说敏捷不写文档的吗?
-1-
一切进攻的发起都有目的。一切进攻的结果大部分可能是没有进球。倘若从表象上来看,我们需要加强的各个环节人的能力,其实考验球队是配合能力。那有进攻的策划集中在某一个人身上的呢?那别的队伍把他看住不久行了吗?简单的道理其实一说就透。不过还是会有球队没有皇马的命却想做皇马的事,把所有好球员加在一起未必是支成功的球队。
把进球这事变成环节我们可以看看这四个维度:
内
外
个体
I
我是安全的
IT
问题都出在他们身上
群体
WE
我们做的没有问题
ITS
他们不配合
这样与进球何益?
-2-
还是回到需求谁来编写上。进球的套路发起如果是一个流程,那谁应该写?自然涉及到谁就应该谁来驱动产生对应的结果,如果你在场上时间太短,就会来复盘,找个人补充你的内容。这个球员是不是BA,你自己想。
以前
主动/被动
下一个
我所理解的需求澄清
最近更新
1yr ago
复制链接