読者です 読者をやめる 読者になる 読者になる

愛と幻想のアジャイル

アジャイルを中心とした日々の技術メモ

アジャイルって何?3包括的なドキュメントよりも動くソフトウェアを

アジャイル
どうも。
一介のソフトウェアエンジニア、竹田剣介です。
アジャイル開発に日々奮闘中!

さて前回の続きです。
アジャイルソフトウェア開発宣言を再掲します。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

今回は、「包括的なドキュメントよりも動くソフトウェアを」
という部分にフォーカスしてみましょう。

ウォーターフォールでは、要求を聞いてから、お客さんが実際のソフトウェアを見るまで、全てが完了後です。
その結果どうなるか。


f:id:k1take:20160212141802j:image

右下がお客さんの本当にほしかったものです。
しかし、大抵それ以外の9個の例のようなものが出来上がり、お客さんから「欲しいものと違うじゃないか」となりがちです。

何故か?
意思疏通というのは100%伝わることが無理だからです。最初に打合せして、設計書というドキュメントを書いてその通り作る。でもそもそも打合せで認識に実はズレが有ったとき、方針変更することをしないからです。

アジャイルの場合、細かく1、2週間でプロトタイプという小さな動くソフトウェアを作ってお客さんに見せます。
そこで「ここがちょっと違う」などのフィードバックをお客さんから貰います。早めに確認すれば、手戻りは最小限で押さえられますし、お客さんの本当に欲しいものを届けることが出来ます。


ドキュメントより動くソフトウェアとは、そういう意味なのです。




アジャイルって何?その2 プロセスやツールよりも個人と対話を

アジャイル
どうも。
一介のソフトウェアエンジニア、竹田剣介です。
アジャイル開発に日々奮闘中!

さて先日の続きです。
アジャイルソフトウェア開発宣言を再掲します。

  • プロセスやツールよりも個人と対話を、
  • 包括的なドキュメントよりも動くソフトウェアを、
  • 契約交渉よりも顧客との協調を、
  • 計画に従うことよりも変化への対応を、

今回は、「プロセスやツールよりも個人と対話を」
という部分にフォーカスしてみましょう。

ウォーターフォールでは、お客さんとの仕事の進め方のルールから、開発では詳細設計をとことんやって、誰が見てもド素人でもプログラミング出来るところまで作るなど、厳密なルールがあります。ルールは絶対的で逸脱は許されません。

アジャイルでは、ルール厳密化を避けます。
設計フェーズに入ったので、お客さんの要求は聞けませんよというルールでは、本当にお客さんの欲しいものを届けるのは不可能です。
そこで個人の対話を重視し、できるだけ要求を飲めるよう動きます。例えば、設計してるけど、要求飲むためには、要求のお金頂きますが可能ですよ、というような動きです。
開発では、メンバー同士やリーダーとメンバーのコミュニケーションを推奨します。よりよいアイディアがあればそちらを取り込みます。「ルールにないから」はありません。詳細設計しなくても、プログラミングが先にやっても大丈夫ならそうします。詳細設計で浮いた時間で、そっちの方が早く出来上がったり、品質向上のブラッシュアップが出来るんです。

お客さんの価値を本当に届けられるのはアジャイルではないでしょうか?


アジャイルって何?

アジャイル
どうも。
一介のソフトウェアエンジニア、竹田剣介です。
アジャイル開発に日々奮闘中!

さて、そもそもアジャイルって何?って話をしようと思います。

アジャイルを定義した有名な文書に
アジャイルソフトウェア開発宣言」
ってのがありまして、それを読むと概要が掴めると思います。

アジャイルソフトウェア開発宣言の内容は下記です。

「私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
  • プロセスやツールよりも個人と対話を、
  • 包括的なドキュメントよりも動くソフトウェアを、
  • 契約交渉よりも顧客との協調を、
  • 計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく」

要は、それまでのシステム開発は、
プロセスツールを重視してて、
ドキュメントを沢山作って、
契約交渉をガッチリやって、
計画は絶対で計画変更なんてもってのほか
だということです。

このようなシステム開発手法を「ウォーターフォール」と呼びます。

滝って意味ですが、滝は上から下へ落ちていきます。下から上へ戻りません。

  1. まずお客さんの要求を聞く
  2. 仕様を決める
  3. 設計する
  4. プログラミングする
  5. テストする
  6. 納品する
という厳密なプロセスシステム開発します。1から6まで順番に一つ一つ終わってから、次へいきます。基本的に2をやってるとき、1に戻ることはありません。
例えば、設計中にお客さんが「こんな機能も欲しくなった」と言われても「もう要求を聞くフェーズは終わってるので無理」となります。

こんな時、ものを言うのはドキュメント
システム会社は「ドキュメントにそんな要求書いてないじゃないですかー」と突っぱねる証拠になります。
なのでお客さんも勢いドキュメントに要求をこれでもか、と書きます。
「いらない機能っぽいけど、後で必要になるかも知れないからドキュメントに書いておこう」となります。
こうなるとドキュメントが無駄に肥大化するのは想像に難くないですよね。

という訳で契約交渉をしっかりやらないと、痛い目に遭います。

でみごと契約成立となれば、ウォーターフォールのプロセスの計画を立てるわけですが、これがなかなか上手く行かない(苦笑)

長くなったので今回はここまで(^^;