-
Notifications
You must be signed in to change notification settings - Fork 0
読書会 1st 2014.10.01 ディスカッション
toshiotm edited this page Oct 2, 2014
·
14 revisions
- 日時: 2014/10/01 (Wed) 19:00-21:00
- 場所: Oinai烏丸
- 告知: http://connpass.com/event/8760/
(疑問点とか、良かったコトとか、ディスカッションネタ)
- **[北村]**そもそも計画駆動（ウォーターフォール）はソフトウェア開発には向かないのか？
-
[北村] 1.5章に出てきたクネビンフレームワークによる分析のように、対象プロジェクトやプロダクトによって適用するアジャイルとウォーターフォールを使い分けたりする事ができるのか？
それともソフトウェア開発はアジャイルが絶対的に優れているのか？ - [前川] 体制が整っていない場合は、どこかで計画を凍結してそこからWF的アプローチに切り替えざるを得ない時はあるかなーという印象。自動テストやらデプロイやら、アジャイルにやるための開発の足回りがないとアジャイルをやることが現実的でない場合も多いかなと。
- [北村] いわゆるスパイラル型開発モデルとアジャイルってどう違うのか？
- [前川] 製造業のメタファだけれど、これはおそらく工場の流れ作業（所謂フォードモデル）を言ってるんだろーな。
- [大友] スパイラル型開発との違いは出荷可能な成果物ができているかどうかかなと理解していました。
-
**[北村]**イテレーティブな開発の発想でスプリントを繰り返すと、回を重ねる毎にフィードバックに対する作業量が増えて、ベロシティが落ちそうな気がするが、この辺りは皆さんどのように対処されていますか？
-
[北村] フィードバックによって発生するそれ以前のインクリメントに対する作業は、別のバックログアイテムとして切り出すとか？
-
[前川] うちで週次デモをやってた時はそんな感じでした。
-
[大友] フィードバックも含めてバックログに積んで相対見積もりを行えば、ベロシティが落ちるという考えにはならない気がします。落ちるということで言えば、当初行う予定だったバックログアイテムの優先度は落ちているかと思います。あと、技術的負債への返済を行うのであればベロシティは落ちるかな。
-
[前川] 用語確認。↓のような感じ？
-
イテレーティブ: タイムボックスを決めた繰り返しによってプロジェクト/プロダクトを改善していくこと
-
インクリメンタル： 出荷可能なプロダクトを少しずつ作っていくこと
-
[前川] なのでイテレーティブにWFすることもできる => スクラムフォール
-
逆にインクリメンタルにWFすると、普通はスクラムになりそうな気もする
- **[北村]**プロダクトのスコープは計画駆動にするが、プロセスは検査とフィードバックを実践するようなやり方は実現可能か？
- **[北村]**これはスクラムの特定のプラクティスだけを切り出して運用したら良いのか？
- **[北村]**やはり両輪ないと意味が無い？イテレーティブにする事への負荷が大きいだけで効果は薄いくなる？
- [前川] スコープが計画駆動（固定）なら、適応をどこに反映するんです？チームの作業だけならKPTやっときゃいいのかもしれませんが、、、
- [前川] 自分用用語整理。
- 透明性: フィードバックなどプロダクトに関する情報にだれでもアクセス可能にすること
- 検査: プロダクトに寄せられる情報を元に製品を検証すること
- 適応: 検査結果をプロダクト/プロジェクトに反映すること
- **[大友]**見える化と言っている人ほど、自分のタスクを見える化できていない経験を良くします。そこそこ規模の会社の場合透明性や見える化って組織構造に依存してきたりしませんか？
- **[大友]**リモート開発出来るかどうかも、透明性にかかっていると思う。
- **[北村]**手段の不確実性の中にあるテクノロジーの不確実性ってアジャイルな手法で解決できるの？
- **[北村]**そもそも見積ができないよね。相対見積でさえ無理。
- **[北村]**スパイクしろって話になるかもしれないけど、スパイクばっかで先が見通せないとか。
- 検査、適応、透明性を通じて変動性を活用せよ