今でもアジャイル開発がよくよくわからない。

アジャイルアジャイル・・・アジャイル開発

アジャイルってそもそも何よ・・・と言う疑問から逃げ続けて 無視し続けて
幾年月。
私が参画したプロジェクトの多くが昔ながらのウォーターフォールでの開発も多かったことから
中々に機会がなかったこのアジャイル。
アジャイルソフトウェア開発手法は「機敏なソフトウェア開発」のようです。（直訳）

聞き慣れない言葉も多いことから纏めておこうとペンを取った・・・ではなくキーボードを叩くことにした次第です。

概要

アジャイル開発の概要は以下のようになるようです。

アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。 近年、アジャイルソフトウェア開発手法が数多く考案されている。 ソフトウェア開発で実際に採用される事例も少しずつではあるが増えつつある。 アジャイルソフトウェア開発手法の例としては、エクストリーム・プログラミング (XP) などがある。 非営利組織 Agile Alliance がアジャイルソフトウェア開発手法を推進している。

Wikipedia「アジャイルについての項目」より抜粋。

もうほぼ概要はこの通り、しかし聞き慣れない言葉もちらりちらりと。

開発の流れ

基本的には開発の流れは以下になるようです。

1. 企画
   まず何を作るかの企画ですね。これはどの開発でもそうでしょう。アイデア出しです。
   「こんなシステム面白そう」「これは売れそうだ」「こんなのほしい」って言う「夢みるターンです」
2. スクラム
   聞き慣れない・・・
   ここに「デイリースクラム」なんて言葉もあったり「スプリント」って言葉があったりします。
   と言うか資料ごとに色々と呼び方が変わってたり。
3. リリース

これを細かな単位で１～３を大体２～３週間で完成させていくものになるようです。
プロダクトを最初から作り出す開発には良いかもしれませんが
カッチリカチカチした開発では向かない感じがヒシヒシと。
あと「仕様変更がバリバリ来るな」と言うような開発も、細かな単位になっている「アジャイル開発」のほうに軍配があがるようです。

スクラムとはなんぞ・・・

スクラムってなんですかね？

　スクラムは、Ken Schwaber とJeff Sutherland、Mike Beedle によって考案されたアジャイル開発手法である。スクラムという開発方法論の名称は、ラグビーのスクラムにちなんで名づけられた。スクラムは、野中郁次郎氏らが80年代に日本の製造メーカーの新製品開発において欧米のメーカーを凌駕した要因の研究をまとめた「知識創造企業」*5などに触発され、Schwaber らがいくつかの失敗プロジェクトを立て直す経験を通じて生み出されたものである。

「スクラムによるアジャイル開発の進め方、従来手法とのギャップ」より抜粋

兎にも角にもこのスクラムには以下の人が登場します。

1. プロダクトオーナー（PO)
   文字通りプロダクトのリーダー的な存在
2. スクラムマスター（SM）
   実働部隊のリーダー的な存在。開発リーダ的な。POに助言したりチームをうまく回せるようにする調整をしたり…
   中間管理職っぽい
3. 開発チーム
   少人数の実働部隊。

そしてこの人達は以下のように作業を進めます。

1. スプリントプランニング
   POと開発チームで開発期間中（２～３週間）に実装するプロダクトバックログ（実装機能予定一覧）のなかでどれを作るか？を決定する
   そんな会議です。
   プロダクトバックログは全期間で最終的に実装されるすべての機能が一覧化されていて
   POは、SMとこのプロダクトバックログの優先順位を並び替えたりするのも大事なお仕事です。
2. デイリースクラム
   決まった時間に実施するチームミーティング。問題点などをここで話し合います。
   間に合ってないプログラムがあるなら、余裕のある開発メンバーに割り振ったりしましょう・・・
3. 開発
4. スプリントレビュー
   POにこの一連の開発機関に出来上がったものをレビューしてもらいます。
   POは、その動作を見てフィードバックします。
5. スプリントレトロスペクティブ
   噛みそうな名前・・・
   今回の一連の作業の振り返りをチームメンバーで実施します。
   

この作業をを短期間（２～３週間、一ヶ月もありそう）で次々進めて行くのが基本的なアジャイル開発のようです。

さて、纏めたものの合っているんでしょうか？

不安です。

ちなみによく言われるのですが
アジャイル開発は以下を重視するようなんですが

「コミュニケーション」

「シンプル」

「フィードバック」

「勇気」

勇気！？
この勇気は、「仕様変更を恐れない、リファクタリングを恐れない」勇気だそうです。
勇気・・・大事ですね・・・
勇気が出ない出てこないレベルのプロジェクトもありますけど。

さて、結局
「コミュニケーション」「フィードバック」に非協力的なチームメンバーや顧客相手ですと
アジャイル開発は、形だけの「スパラルモデル」しかも「だめな方のスパイラル」が発生することになるわけですね・・・

じつはアジャイル開発成功しているところをあまり見たことがないのでした。