-
Notifications
You must be signed in to change notification settings - Fork 42
/
Copy path2018.05.14-PM-A-2.html
871 lines (665 loc) · 22.5 KB
/
2018.05.14-PM-A-2.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
<title>葡萄藤PPT</title>
<link rel="stylesheet" href="./css/reveal/reveal.css">
<!-- PPT主题，可以在/css/reveal/theme/中选择其他主题，目前暂时只能使用该模板 -->
a <link rel="stylesheet" href="./css/reveal/theme/ptt.css">
<!-- syntax highlighting 代码高亮主题 -->
<link rel="stylesheet" href="./lib/reveal/css/zenburn.css">
<!-- 打印和PDF输出样式 -->
<script>
var link = document.createElement( 'link' );
link.rel = 'stylesheet';
link.type = 'text/css';
link.href = window.location.search.match( /print-pdf/gi ) ? './css/reveal/print/pdf.css' : './css/reveal/print/paper.css';
document.getElementsByTagName( 'head' )[0].appendChild( link );
</script>
</head>
<body>
<img src="./img/demo/logo.png" alt="" usemap="#pttmap" class="base-logo">
<map name="pttmap">
<area shape="rect" coords="0,0,276,58" href="http://www.jnshu.com" alt="" target="_blank"/>
</map>
<div class="reveal">
<div class="slides">
<section>
<h3>谈谈用户故事</h3>
</section>
<section>
<p>目录</p>
<p>1.背景介绍</p>
<p>2.知识剖析</p>
<p>3.参考文献</p>
<p>4.更多讨论</p>
</section>
<section>
<h3>1.背景介绍</h3>
</section>
<section>
<p>
产品开发、测试的需求源头都是用户故事
</p>
<p>
PM必须好好掌握用户故事
</p>
</section>
<section>
<h3>
2.知识剖析
</h3>
</section>
<section>
<p>
<h4>
一、用户故事的概念
</h4>
</p>
<p>
</p>
<div align="left">
<p>
</p>
</div>
<p>
用户故事，描述了对用户、系统或软件购买者有价值的功能。
</p>
<p>
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
<h4>
二、用户故事的三要素
</h4>
</p>
<p>
角色、功能、价值
</p>
<p>
</p>
<p>
</p>
<p>
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
<h4>
三、用户故事的独特价值
</h4>
</p>
<p>
</p>
<p>
</p>
<p>
</p>
<p>
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
<h4>
</h4>
</p>
<p>
</p>
<p>
独特价值之一在于它的出现使敏捷开发方法覆盖了软件研发中的“需求”环节
</p>
<p>
</p>
<p>
用户故事的诞生，就是为了实现需求的敏捷化，是需求敏捷化的基石之一
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
<h4>
</h4>
</p>
<p>
独特价值之二在于它不仅实现了需求敏捷化的表述，还有效的将软件研发过程中的需求环节、开发环节和测试环节有效的连接起来。
</p>
<p>
通过经典的“三段论“描述和渐进的细节探索，用户故事实现了需求描述的敏捷化
</p>
<p>
通过优先级排序和故事点的有效应用，用户故事实现了需求到开发的连接
</p>
<p>
通过验收标准的渐进明确，用户故事实现了需求与测试的连接
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
<h4>
</h4>
</p>
<p>
独特价值之三在于它的特有的度量概念：故事点
</p>
<p>
</p>
<p>
故事点巧妙地将需求与研发计划有效地融合起来，并且很好地支撑了团队的持续改进
</p>
<p>
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
<h4>
</h4>
</p>
<p>
补充一下：
</p>
<p>
</p>
<p>
故事点：在项目开始的阶段，试着找出所有的用户故事，然后找出里面最简单的用户故事（这里的“简单”，意思是说实现周期最短），不一定非常精准的判断哪个最简单。只要挑出你觉得最简单的就行了。
</p>
<p>
然后我们判断说，这个用户故事算1个“故事点（story point）”。
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
<h4>
</h4>
</p>
<p>
关于独特价值的第三点：
</p>
<p>
</p>
<p>
计划会议里面一个很重要的环节，那就是故事点的估计
</p>
<p>
实际上就是对在sprint里面要开发的user story进行一个粗量级的估算，以便于团队能够知道这个user story的复杂度（工作量）
</p>
<p>
重点放在当前迭代里能否按照该用户故事的接收条件和团队定义的DoD(完成标准)来完成这个用户故事，如果不能完成，给出理由，由PO来决定是否拆分或者重新设计用户故事
</p>
<p>
</p>
</section>
<section>
<h4>
四、用户故事的原则
</h4>
<p>
INVEST
</p>
</section>
<section>
<h4>
</h4>
<p>
用户故事应该具有六大特点：Idependent（独立的）；Negotiable（可协商的）；Valuable to users or customers（对用户或者客户是有价值的）；Estimatable（可估算的）；Small（小的）；Testable（可测试的）
</p>
<p>
</p>
<p>
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
</p>
<p>
</p>
<p>
Idependent（独立的）
</p>
<p>
是指用户故事和用户故事之间应该尽量避免相互依赖。
</p>
</section>
<section>
<p>
Negotiable（可协商的）
</p>
<p>
</p>
<p>
在进入开发前，需求、开发、测试大家对用户故事的描述和验收标准已经达成了一致。但是不管在开发前达成怎样的一致，在开发过程中必然会发生需求细节的进一步细化，这是因为随着软件开发的进展，系统的未知性由模糊而渐进清晰必然导致的结果，这是自然规律，任何人都无法避免。而我们能做的，就是运用敏捷方法适应各种变化。用户故事的“可协商性”就是指大家对所有之前达成的一致在新的变化发生情况下，协商后达成新的一致，从而推动系统的研发进展。
</p>
</section>
<section>
<p>
Valuable to users or customers（对用户或者客户是有价值的）
</p>
<p>
用户故事的经典三段论描述把故事的价值可视化的描述出来，这个特点促进团队的开发和测试成员由传统的指令式工作方式向自驱动的价值导向工作方式转变，使团队中的每个人知道自己每天做的工作价值。
</p>
<p>
</p>
</section>
<section>
<p>
Estimatable（可估算的）
</p>
<p>
上文中描述的独特价值之三
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<h4>
</h4>
<p>
Small（小的）
</p>
<p>
因为用户故事是敏捷实践，而敏捷方法追求的是快速交付，那么作为源头，我们输入的需求也应该是面向交付的，所以，好的用户故事必须足够小。
</p>
</section>
<section>
<p>
Testable（可测试的）
</p>
<p>
</p>
<p>
所有合格的需求必须是可测试的，用户故事也不例外。用户故事的验收标准正是体现了这一点。
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<h4>
五、好的用户故事的准则
</h4>
<p>
好的用户故事当然应该遵守上述几个原则
</p>
<p>
下面谈谈好的用户故事的几个标准
</p>
<p>
针对性、封闭性、独立性
</p>
</section>
<section>
<p>
针对性：只包含一个用户，因为多个用户常常有细微的差别
</p>
<p>
</p>
<p>
一般是典型的用户，常常有共同的某类需求。
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
封闭性：完整地交付一个客户价值
</p>
<p>
一个封闭式的用户故事意味着这个故事完成后，用户可以达成一个明确的、有意义的目标
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
下面给一个不是封闭式的用户故事的示例：
</p>
<p>
以一个在线求职网站为例：“作为一个招聘人员，我可以管理我发布的工作。”
</p>
<p>
</p>
</section>
<section>
<p>
这个故事太大了，以至于没有太多意义。“管理”这个活动很难被完成。比如，你们公司有一个经理，他肯定不会说，“OK，我的管理完成了，是时候干点儿实事儿了”。
</p>
<p>
“管理”这个词很明确的提示我们，这个故事不是一个封闭式的故事，类似的词比如“维护”、“优化”、“改进”等等。
</p>
<p>
</p>
</section>
<section>
<p>
那我们一起来看看，如何写封闭式的用户故事。
</p>
<p>
首先要考虑的是，“管理”在这个上下文里面具体意味着哪些事情要做。在一个在线求职网站，管理发布的工作，意味着我浏览这些工作广告对应的求职申请，检查发布的工作是否过期了，删除不太适合的求职申请，更新或修正工作描述等。
</p>
<p>
所以，写用户故事就是要把这些想法具体化。
</p>
</section>
<section>
<p>
上面的最初的那个用户故事，我们可以写成下面这样:
</p>
<p>
作为招聘人员，我期望能够浏览所有我发布工作对应的求职申请，我需要将符合要求的找出来发给招聘经理。
</p>
<p>
作为招聘人员，我可以调整我发布的工作的截至日期，这样我可以延长时间获得更多申请，或者提前结束该职位的招聘。
</p>
<p>
作为招聘人员，我可以删除不太合适的求职申请，这样我可以避免浪费时间在这些没有价值的信息上。
</p>
<p>
作为招聘人员，我可以修改我发布的工作的描述，以便于吸引更好的求职者关注这个职位。
</p>
</section>
<section>
<p>
独立性：故事间没有依赖
</p>
<p>
三种依赖性的类型：重叠（Overlap）、顺序（Order）和包含（Containment）
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
1.重叠依赖
</p>
<p>
重叠依赖是带来最多困扰的依赖形式，特别是多个用户故事包含多个不同的重叠部分时，很难找到一组用户故事可以代表该最小可行产品的功能集合，该集合应该包含且仅包含一次需要的功能。
</p>
<p>
用户故事功能重叠是没有很好进行拆分的指示器，错误地使用端到端的概念，在非特性团队的情况下按照部件或架构层次拆分用户故事
</p>
<p>
</p>
</section>
<section>
<p>
解决方式：
</p>
<p>
将重叠部分单独剥离出来做为独立的用户故事
</p>
<p>
合理拆分用户故事，并且将重叠部分只保留在一个最有内聚性的用户故事中
</p>
<p>
组建特性团队以及合理界定端到端
</p>
</section>
<section>
<p>
补充：
</p>
<p>
端到端的流程：
</p>
<p>
端到端流程的定义是从客户的需求开始到客户的需求满足为结束。
</p>
<p>
为满足并能解决客户同一个相对独立需求的一系列相关子流程的组合。
</p>
</section>
<section>
<p>
特性团队：
</p>
<p>
特性团队是一个跨职能、跨组件的团队，能够从产品待办列表中抽取并完成最终客户想要的特性。
</p>
</section>
<section>
<p>
首先，应该准确理解“特性”。这个特性指从产品的最终用户的角度看，对最终用户有价值，最终用户能够感知到的东西。
</p>
<p>
第二、职能。比如UI设计、编程、测试，就是三种不同的职能。最终用户想要的某个特性往往需要多个职能协作，“跨职能”就是要求一个开发团队具备所有必备职能，而不需要依赖团队外部的职能部门。
</p>
<p>
第三、组件。当软件系统庞大、复杂时，通常把一个系统分解为多个组件。
</p>
<p>
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
传统的组件团队看起来像这个样子：
</p>
<p>
<image src="./img/pm-maxutao/002/001.png">
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
特性团队看起来像这个样子：
</p>
<p>
<image src="./img/pm-maxutao/002/002.png">
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
组件团队有如下一些限制：
</p>
<p>
第一：按照组件来组织团队，很难避免团队之间的依赖，跨团队的协调和依赖管理更加复杂，不利于跨组件或者各个层之间的沟通。
</p>
<p>
第二：每个团队专注在自己的模块，由于各模块、或分层需求工作量的不同，很容易产生等待，并且容易产生低价值的交付。
</p>
<p>
第三：由于职责单一，限制了学习，使得专业更加单一化
</p>
<p>
第四：Sprint结束的时候无法提交可交付的增量产品功能，延迟价值交付
</p>
</section>
<section>
<p>
特性团队的好处：
</p>
<p>
团队内可以做到端到端，所以减少了等待，周期加快
</p>
<p>
比较容易在一个Sprint中交付可用的产品增量
</p>
<p>
减少了团队之间依赖，计划会更容易
</p>
<p>
责任范围的扩大，各种不同领域的专家在一个团队，增加了个人学习和团队学习的机会
</p>
</section>
<section>
<p>
以特性团队为主的组织在实现“迭代开发、增量交付”方面有天然的优势，成功的Scrum组织应以特性团队为主。
</p>
<p>
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
2.顺序依赖
</p>
<p>
顺序依赖是指要使某用户故事完成，另外的一个或多个用户故事必须在它之前完成。顺序依赖通常是无害的，而且有一些方式可以减轻这种依赖。
</p>
<p>
从敏捷开发的角度，整个系统是从初始的最小可行产品逐步演化为强大的产品，后面的每一步是建立在前面的基础之上的
</p>
<p>
但从另外的角度，不必要的顺序依赖使得排列和调整优先级变的比较困难，进而影响制定发布和迭代计划，也使得用户故事的大小估算更难以把握。
</p>
</section>
<section>
<p>
解决方式：
</p>
<p>
要求一个迭代内的用户故事尽量做到没有内在依赖，保持每一个用户故事的独立性。在同一迭代内，同一团队之内以及多团队之间的故事最佳情况都是做到无依赖。
</p>
<p>
保持迭代之间只有单向依赖。
</p>
<p>
如果一个迭代内用户故事有依赖，而用户故事的拆分满足其他良好的用户故事拆分规则，说明用户故事可能拆分的太细，或者迭代期太长，首先保持单向依赖，可以尝试缩短迭代期
</p>
<p>
任何情况下，不要有循环依赖。
</p>
<p>
剥离出核心依赖作为独立的故事，不要把有依赖和无依赖的需求混在一个故事里。
</p>
</section>
<section>
<p>
3.包含依赖
</p>
<p>
包含依赖是指在组织用户故事时使用有层级的管理，比如常见的特性－故事两级管理，一个特性包含多个用户故事，这样就构成了特性对其属下故事的包含依赖。
</p>
<p>
</p>
<p>
</p>
</section>
<section>
<p>
解决方式：
</p>
<p>
特性一级用来做发布计划
</p>
<p>
用户故事一级用来做迭代计划，避免用特性一级做粗粒度迭代计划
</p>
<p>
特性一级同样可以进行拆分，直至拆分到最小市场化特性的程度，并将其包含的用户故事分别归到新拆分出的特性中去
</p>
<p>
遵从最小可行产品的理念，组合多个最小市场化特性而构成最小可发布的产品，并逐个迭代增强系统，一个最小市场特性可以多个迭代实现，每个迭代实现一些用户故事。一个特性分多个用户故事多个迭代实现，每一个迭代可形成潜在可交付或者提供内部或外部反馈。极端情况下一个市场化特性可以是一个用户故事，消除了包含依赖
</p>
</section>
<section>
<h3>3.参考文献</h3>
</section>
<section>
<p>参考一：<a href="https://blog.csdn.net/mebusw/article/details/9253259">如何理解用户故事INVEST规则中的独立性？</a></p>
<p>参考二：<a href="https://blog.csdn.net/lihewang1023/article/details/44749263">何谓端到端流程，我的理解是这样的</a></p>
<p>参考三：<a href="https://blog.csdn.net/baby9900/article/details/79539343">成功的Scrum组织以特性团队为主</a></p>
<p>参考四：<a href="https://www.cnblogs.com/sophia194910/p/8352576.html">特性团队</a></p>
<p>参考五：<a href="http://www.cnblogs.com/sophia194910/p/8405729.html">要写封闭式的用户故事</a></p>
</section>
<section>
<h3>
4.更多讨论
</h3>
</section>
<section>
<h4>鸣谢</h4>
<p>感谢大家观看</p>
</section>
</div>
</div>
<script src="./lib/reveal/js/head.min.js"></script>
<script src="./lib/reveal/reveal.js"></script>
<script>
// 以下为常见配置属性的默认值
// {
// controls: true, // 是否在右下角展示控制条
// progress: true, // 是否显示演示的进度条
// slideNumber: false, // 是否显示当前幻灯片的页数编号，也可以使用代码slideNumber: 'c / t' ，表示当前页/总页数。
// history: false, // 是否将每个幻灯片改变加入到浏览器的历史记录中去
// keyboard: true, // 是否启用键盘快捷键来导航
// overview: true, // 是否启用幻灯片的概览模式，可使用"Esc"或"o"键来切换概览模式
// center: true, // 是否将幻灯片垂直居中
// touch: true, // 是否在触屏设备上启用触摸滑动切换
// loop: false, // 是否循环演示
// rtl: false, // 是否将演示的方向变成RTL，即从右往左
// fragments: true, // 全局开启和关闭碎片。
// autoSlide: 0, // 两个幻灯片之间自动切换的时间间隔（毫秒），当设置成 0 的时候则禁止自动切换，该值可以被幻灯片上的 ` data-autoslide` 属性覆盖
// transition: 'default', // 切换过渡效果，有none/fade/slide/convex/concave/zoom
// transitionSpeed: 'default', // 过渡速度，default/fast/slow
// mouseWheel: true, //是否启用通过鼠标滚轮来切换幻灯片
// }
// 初始化幻灯片
Reveal.initialize({
history: true,
dependencies: [
{ src: './plugin/markdown/marked.js' },
{ src: './plugin/markdown/markdown.js' },
{ src: './plugin/notes/notes.js', async: true },
{ src: './plugin/highlight/highlight.js', async: true, callback: function() { hljs.initHighlightingOnLoad(); } }
]
});
</script>
</body>
</html>
Contact GitHub API Training Shop Blog About
© 2016 GitHub, Inc. Terms Privacy Security Status He