すくすくに久しぶりに参加。

気になってた点が少しすっきりした。
詳細は、別途出るであろう資料を参照

自身のメモ.記憶が改ざんされている可能性もあります。

ScrumのボードとKanbanの差異から、Kanbanを理解

差異のポイント	Scrum	Kanban
ボードの見た目	イテレーションの終わりに近づくにつれて、TODOの数が減り、DONEの数が増える。イテレーションの終わりに全てDONE となる。次イテレーションでまたTODOが増える。バーンダウンチャートが似合う	常に、各工程で仕掛かり制限の数のものを実行している（参照する時間で実施しているタスクの内容は異なる）。フローの流れを保つ。バーンダウンチャートが似合わない
タスクボードの発展度合い	そこそこ	ガチに改善させていく対象
役割	プロダクトオーナー、スクラムマスター、プロダクトオーナー	定義なし
チーム形態	機能横断チームを好む	機能横断チーム、専門家チームどちらでも。マーケティング、分析、設計、実装、テストで工程を区切って進める事もサポート
見積り	フィーチャー単位（ストーリーポイント or 理想日）、タスク単位（時間）で見積る	粗粒度の見積り。フィーチャーをSMLなどざっくり。タスク見積りは特にせず。タスク数を数えるぐらい
イテレーション途中での機能追加	原則次のイテレーション	仕掛かりの制限の範囲内であればいつでも
タイムボックス	遵守重要。サイズに合わせて、フィーチャー、タスクを分割	遵守することを求められていない。イテレーションをまたいだタスクの実行もOK
リリースタイミング	イテレーション末（１−４週間サイクルは固定）	リリースが必要であれば、一つのフィーチャーが終了したタイミングで。流動的

カンバンの基本特徴として、信号、可視化、流量制限。3番目を上げている点で好感を持った。よくポイントを押さえている。運用のキーは、工程設定、仕掛り数の制限の設定、流すカードの分割の単位や粒度、クリティカルタスクの星印、そしてシームレスにカードを流せるように全体で協力体制をつくれるかどうかにありそうだ。

途中で何度か、「ツールの優劣を上げたいわけではない、現場のコンテキストに合わせて、ツールを適切に選択し、カスタマイズしてほしい」との断りの言葉が出てきた。確かに、Scrum出身だと、防衛的反応を引き起こしやすそうなアイデアがいくつかある。タイムボックスがMustでないとか、バウンダウンチャートが似合わないプロジェクト運営とか。

ウォーターフォールが好きな人がXPに過剰に防衛反応を引き起こすように、XPが好きな人がScrumに過剰に防衛反応を引き起こすように、Scrumが好きな人がKanbanに過剰に防衛反応を引き起こす構図には気をつけたい
Scrumにとっての necessityによって引き起こされるであろう、防衛的反応に引きずられず、落ち着いて再考する必要がありそうだ。

お金軸の話はなかったなぁ。