「第19回すくすくスクラム 〜Scrum＆Kanban〜」( #suc3rum )参加メモ

イベント

第19回すくすくスクラムに参加してきました．
今回はそのことに関してメモを．

http://kokucheese.com/event/index/4912/

今回は，Agile2010で，Henrik Kniberg 氏が講演した
"KANBAN AND SCRUM - MAKING THE MOST OF BOTH" の再
演でした．再演講師は，@ebacky 氏でした．@ebacky 氏
の資料は許可等の問題から公開されていないのですが，
元々のHenrik Kniberg 氏の資料を原田騎郎氏が訳した
ものが下記に公開されています．

http://www.slideshare.net/kiroh/scrum-kanban


再演の流れは，@ebacky 氏が Kniberg 氏と相談しなが
ら，Kniberg 氏の資料に日本向け変更を加えた資料を元
に，ScrumとKanbanの説明・比較を行う説明がベースで
した．加えて，その流れの途中で，

  • リードタイムの異なるチームの善し悪しとその改善方法に関してテーブルでの議論
  • 並行作業ゲームおよびおこなったことを通した議論
  • 並行作業ゲームに関して他テーブルの意見ヒアリング

をおこないました．

今回のテーマは
「KanbanとScrumを比較し，両者の理解を深める」
というものでありました．
特に印象に残ったこととしては，Kniberg 氏 のメッセ
ージおよび @ebacky 氏がしきりにいっていた，
「これが正解というものではなく，1つの考え/方法である」
ということでした．
最近，アジャイル系のプロセス・開発技法に関して勉強
を進めていると，ウォーターフォールを全否定するよう
な発言を聞くことがあるのですが，ウォーターフォール
も含めた適材適所なんじゃないかと思うことがあるので，
この言葉はしっくりきて，印象に残りました．

それ以外に，議論や他テーブルの意見より，下記のよう
疑問が残りました．何かの機会に確かめようと思います．

  • Kanban方式とは何を持って，Kanban方式と呼ぶのか．
  • 見積もりは大・中・小のみの見積もりで十分なのか．


以下では，まとまっていないままですが，メモを残して
おきます．

  • ここでとりあげるKanbanはソフトウェア開発に適用したものであり，トヨタのカンバンとは異なる．
  • 知識レベルは経験の差
  • Scrumの特徴：小さいものを短時間で小さいチームで作ること
  • Scrum checklist公開(非公認)
  • Kanbanの海外での例としては，信号システム・可視化・制限量．
  • トヨタ自動車におけるカンバンは現品表．
  • ソフトウェア開発におけるKanbanの特徴：仕掛品に制限をつける．
  • ボードを，Scrumでは1チームごとに利用するが，Kanbanでは複数チームで利用する．
    • 出荷まで長く使うため
  • ボードを，Scrumでは1スプリントごとに更新するが，Kanbanでは長く保たれる．
  • ソフトウェア開発プロセスを記述的・適応的という軸で比較すると，Kanbanは3つルールとルールなしの次に適応的．
    • 記述的からならべると，RUP(120over)，XP(13)，Scrum(9)，Kanban(3)，ルールなし(0)
  • Kniberg 氏の意見としては，ツールや方法によらない．それらは悪い使い方もできる．
    • @ebacky 氏曰く，職人として道具にこだわる考え方もあるが，Kniberg 氏はこだわらない派．
  • 並行作業ゲーム
    • 開発者1名が，テーブルの複数人(顧客)のネームカードを作成する．
    • 顧客は開発者にネームカードを見せるだけ．
    • 作成時間を計測する．
    • ゲーム1
      • 1顧客1文字ずつ記入する．1文字書いたら次の顧客の1文字を記入する．これの繰り返し．
    • ゲーム2
      • 1顧客ごとに1ネームカードを作っていく．1顧客のネームカードが完成したら次の顧客へ．
  • 並行作業ゲームを通したテーブルので意見
    • ゲーム1のほうが時間がかかったのは，切り替えのオーバーヘッドが大きかったことと，ゲーム2では記入するものの予測がつき高速に記入ができたためではないか．
    • ゲーム1のネームカードの方が誤りが少ないが，ゲーム2の方が全員のカードの完成が圧倒的に早い．
    • ゲーム2は最初に完了した人と最後に完了した人との間にそこそこの時間がある．
    • ゲーム1は1回の仕事量が固定のため，1回分が簡単．
  • 不必要な並行作業の要因
    • 開始を意識して，終了を意識していない．
    • 仕掛品を制限しない．
    • 人を忙しくさせることに集中する．
    • 症状を改善することと"理由"を許容し，問題を気にしない．
  • Kanbanでは，(付加価値作業)/(サイクルタイム)の値の向上をねらう．
  • "仕掛品を制限"はコンテキストに寄る．
  • 仕掛品を制御することで改善できるのはないか．
    • 人を増やすより，プロセスを改良した方がよいことが多い．
  • Scrum+Kanbanは透明性を高めるため．改善の良いアプローチ
    • ただし，開発者だけというような部分的に良くなるのは良くない．
  • 仕掛品の制限を流動的に変更することは適切ではない．
    • 制限の意味がなくなる．
  • 経験を元に仕掛品の制限を決める．
    • 制限が低い：怠け者が増える．
    • 制限が適切：時々ゆとりができる．
    • 制限が高い：余裕がなく，状態の計測などもできない．
  • 選択肢の大小は善し悪しでなく，意識の違い．
    • それらを許容した上で，問題の背景を聞いて，方針・方法を決める．
  • Kanbanボードは自ら進化させる．
  • Kanbanは自分流で．
    • Kanban:タイムボックス固定イテレーションの選択は任意
    • Kanban:コミットメントは任意
    • Kanban:計画やプロセス改善に使う基本の指標は、リードタイム
      • Scrum:計画やプロセス改善に使う基本の指標は、ベロシティ
    • Kanban:機能横断チームは任意．専門家チームも可能
      • Scrum:機能横断チームが指定
    • Kanban:特に指定のダイアグラムはない
      • Scrum:1スプリント内で完了するように、項目は分割される
    • Kanban:項目のサイズに制限はない
      • Scrum:バーンダウンチャートが指定
    • Kanban:直接的にWIPを制限(ワークフローの状態ごとに)
      • Scrum:間接的にWIPを制限(スプリントあたり)
    • Kanban:見積もりは任意
      • Scrum:見積もりは必須
    • Kanban:容量があるならいつでも項目を足せる
    • Kanban:Kanbanボードは、複数のチームや個人で共有することもできる
    • Kanban:役割を指定していない
      • Scrum:役割を３つ指定(PO/SM/Team)
    • Kanban:Kanbanボードはずっと使われる
      • Scrum:Scrum ボードは、スプリントごとにリセットされる
    • Kanban:優先度付けは任意
  • ゴールを把握する．
  • ツールを非難しない．
  • 1つのツールにこだわらない．
  • 経験を楽しんでください．