回答編集履歴
4
a
answer
CHANGED
|
@@ -36,5 +36,9 @@
|
|
|
36
36
|
ルールを決める事を怖がっているような文章にみえますが、ルールが決まることで時間短縮につながることもあります。ルールが曖昧なことで開発チーム内ですら認識の齟齬が発生して無駄に時間が消費されることもあります。
|
|
37
37
|
|
|
38
38
|
細かい話だと表記揺れなどが該当します。
|
|
39
|
+
同じ意味であるにもかかわらず言い方を変える事は避けるべきです。
|
|
40
|
+
言い方を変えるからには何らかの理由が必要です。
|
|
41
|
+
|
|
42
|
+
他にも、以下のような事例が身近にありました。
|
|
39
43
|
Xさんは「機能Aの事をA」と呼び、Yさんは「機能Bの事をA'」と呼ぶ場合、Zさんからみると「AとA'何が違うの？」「Xさんが言っているAと、Yさんが言っているA'は呼び方が似ているが機能は全く別であることを前提に考える」などと無駄に考える必要があります。また、Zさんが確認せずに勝手に解釈した場合は「似た呼び方をしているが、実は同一機能ではなく機能Aと機能Bが存在していた。機能BについてのPBIだったが、機能Aについて実装してしまった」と後から気づくことになり、時間を無駄に消費することもあるでしょう。
|
|
40
44
|
そして、認識の差が「ステークホルダーと開発チーム」だった場合が一番良くないですね。
|
3
a
answer
CHANGED
|
@@ -3,8 +3,10 @@
|
|
|
3
3
|
> 曖昧にすると不安がられる
|
|
4
4
|
|
|
5
5
|
スプリント期間は任意の期間が選択できます。
|
|
6
|
-
|
|
6
|
+
PBIを小さくして、スプリント期間が短ければ決めやすくなるのではないでしょうか。
|
|
7
7
|
|
|
8
|
+
また、スプリント期間が長いことが原因で成果物を見せるまでに時間がかかっているのであれば、スプリント期間を短くしてステークホルダーやプロダクトオーナーに細かく見せてあげる環境ができれば「進んでいるんだな」という実感を与えることができるのではないでしょうか？
|
|
9
|
+
|
|
8
10
|
実際に期間を短くした影響で開発に影響が出てしまう場合はステークホルダーやプロダクトオーナーと交渉するべきでしょう。
|
|
9
11
|
お互いがやりやすい環境を話し合って折り合いをつけるべきです。
|
|
10
12
|
|
2
a
answer
CHANGED
|
@@ -16,14 +16,18 @@
|
|
|
16
16
|
スクラムの前提で個々が自発的に動くという事が必須条件です。
|
|
17
17
|
プランニングやリファインメントの時間に仕様をガチガチに固めるのではなくゴールの認識は必ず一致させ、仕様は簡易的に設定して、実際の細かい仕様は必要に応じて担当者と開発者が会話して決めるべきです。
|
|
18
18
|
|
|
19
|
-
> リファインメントやレトロスペクティブを正しく回そうとすると…
|
|
19
|
+
> リファインメントやレトロスペクティブを正しく回そうとすると、pbiのフォーマット整備、…
|
|
20
20
|
|
|
21
|
+
そもそもスプリントが動き出している状況でPBIのフォーマットを気にしている状態は非常にまずいです。
|
|
22
|
+
フォーマットが決まっている前提で動き出し、スプリントを進めていく中で現在のフォーマットを少しずつ空いた時間で改良していく程度にするべきでしょう。
|
|
23
|
+
|
|
24
|
+
また、「正しく回す」という定義が曖昧ですがあくまで開発効率を良くしたり、よりよいプロダクトを作ることを目的として設ける時間のはずです。
|
|
25
|
+
リファインメントやレトロスペクティブの時間を一定時間必ず設けることが目的ではないです。
|
|
26
|
+
|
|
21
27
|
> 「開発に集中したいのに会議やその準備に時間取られてる」という状態になりかけています。
|
|
22
28
|
|
|
23
29
|
複数開発チームが存在する前提であればスクラムマスターを採用する事で解決すると思います。
|
|
24
30
|
数チーム程度であれば「やり方が良くない」という気がします。
|
|
25
|
-
そもそもスプリントが動き出している状況でPBIのフォーマットを気にしている状態は非常にまずいです。
|
|
26
|
-
フォーマットが決まっている前提で動き出し、スプリントを進めていく中で現在のフォーマットを少しずつ空いた時間で改良していく程度にするべきでしょう。
|
|
27
31
|
|
|
28
32
|
> ルールを決めないと見積もりや振り返りの精度が出なそうで怖い
|
|
29
33
|
|
1
a
answer
CHANGED
|
@@ -31,4 +31,4 @@
|
|
|
31
31
|
|
|
32
32
|
細かい話だと表記揺れなどが該当します。
|
|
33
33
|
Xさんは「機能Aの事をA」と呼び、Yさんは「機能Bの事をA'」と呼ぶ場合、Zさんからみると「AとA'何が違うの？」「Xさんが言っているAと、Yさんが言っているA'は呼び方が似ているが機能は全く別であることを前提に考える」などと無駄に考える必要があります。また、Zさんが確認せずに勝手に解釈した場合は「似た呼び方をしているが、実は同一機能ではなく機能Aと機能Bが存在していた。機能BについてのPBIだったが、機能Aについて実装してしまった」と後から気づくことになり、時間を無駄に消費することもあるでしょう。
|
|
34
|
-
|
|
34
|
+
そして、認識の差が「ステークホルダーと開発チーム」だった場合が一番良くないですね。
|