アジャイルと大きめプロジェクトと、「スクラム」という新しい単語【与太】

スクラムという開発スタイルがあるらしい。

スクラムとは、チームとそのサイクルを意味するもので、次の5つのプラクティスからなるスタイルだそうだ。

http://www.tech-arts.co.jp/agile/agile8.html

  1. 【スプリント】 30日ごとに課題を決める
  2. 【スプリント・レビュー】 30日終了後に、関係者全員でレビュー&次を決める。
  3. バックログ】 残り課題リスト。
  4. スクラム・ミーティング】 毎日ミーティング。
  5. スクラム・マスタ】 チームを前進させ、守り、責任を持つ。

なるほど。

おれの勤務先での開発スタイルは

  • 基本的には週単位でリリース
  • 週に1時間、社内全関係者で次の週の課題(機能、バグ)を決める
  • 開発タスク(や要望、不具合)は全部BTS(影舞)管理
    • 週の課題として決まったら「受付」ステータス
  • 毎朝、技術スタッフは、下記についてスタンドアップミーティング
    • 昨日やったこと
    • きょうやること
    • 思ったこと
  • 開発チームは、リーダーが責任を持ち、守り、進める

なので、単位の長さ以外はわりと近い感じかなぁ、という印象を受けた。

それと意識してやってるわけではないので、「自己組織化」というスクラムの精神みたいなところは、特にとりくめてるわけじゃないけれども。


が。きょうひとつ問題にぶつかった。

通常の機能強化や不具合対応以外の、大き目の事業提携みたいな案件のスケジューリングを、いつものような感じでやろうとしたら、なんかしっくりこない。というかタスクが目に見えない。

そして営業サイドが不安な顔になった。おもわずおれも「MSProjectとかでざっくり絵かけませんか?」って言っちゃったよ。つーかおれが不安になったのか。

そりゃそうだよな。1週以降のスケジュールが全然見えないんだもの。「とりあえずどれに取り組みますか?」って聞かれても、規模がすこし大きいと「おいおい決めることそんだけでいいのかよ。不安だよそれじゃ、、。」みたいな気持ちになる。

現状のスタイルでやれるのは

  • タスク間の依存関係が単純
  • タスクの粒度が揃っている(小さめ)

だからなんだなとあらためて理解した。

で、ちょっとぐぐってみたら。

アークランプさんによい記事が。

スクラムを通常の企業アプリケーション開発プロジェクトで採用するには大きな壁がある。1つ目は最終リリース日へのコミットメント、、

スクラムは1ヶ月間のことしか約束をしないため、1年先の事なんかわかるわけがない。しかし、そんな立場では案件は取れないだとろう(これが許されるのはインハウスの開発チームであり、スクラムの多くの事例がこれに当たる)。

〜中略〜

僕の経験では「毎週・毎月リスケする」というのが一番分かりやすい説明なようだ。リスケというとネガティブな印象が強いが、スクラムの場合は織り込み済みなわけで、むしろポジティブに行う作業になる。そうなると現場担当のクライアントは妙に納得してくれて、逆にスケジュール組み変えるPMの方が不安がる場合もあったりする。

なるほどー。やっぱそこは壁なのね。よくまとまっちょる。

アジャイルでは管理できない」という発言を聞くことがある。しかし、考えて欲しい、あなたが管理しているものは何なのか。アジャイルは遠大な定義済みプロセスを進めるには向かない。しかし、プロジェクトをクライアントが満足するようにコントロールすることが出来る。

現実をこの境地まで進めるのはたいへんなことだけれども、実際に取り組んでいる人がいるというのはなんかわくわくさせるものがある。

まぁそこまでいきなりできなくても、規模感あるプロジェクトは、とりあえずは普通にプロマネ的作業いれて、いまのスタイルとの妥協点探るしかないよな。すっかり気持ちいい毎週の社内開発スタイルに慣れて、それ以外の性質のは久しぶりだから忘れてたよ。