感想文:アート・オブ・アジャイル・デベロップメント(協力すること)の続きです。
自分の現場に導入可能な度合いを評価してみました。
各項目は章立てをそのまま抜き出したもの。
それぞれについて自分の考えをまとめました。
内容を覚えていないところは評価を付けていません。
それだけ印象がなかったっていうことで。。。
・考えること
×ペアプログラミング
○活き活きとした仕事
○情報満載の仕事場
○根本原因分析
○ふりかえり
ペアプロの導入は難しい。今までとやり方が違いすぎる。
2人でコーディングして、生産性が2倍以上になる自信がない。
ペアプロにより、障害などの手戻りがなくなり、
作業量が減ることで、納期に間に合わせることが出来るのだと思うが。。。
ペアプロ導入以外にリスクが少ないプロジェクトでなら
実験的導入ができるだろうか。
その他はアジャイルに限らず、どの現場でも求められるもの。
特に、「ふりかえり」は後回しにして、結局、やらないことが多いので
本書で提案しているような、短い間隔でのイテレーションで
その都度、実施していくことが重要だ。
・協力すること
○信頼
△全員同席
×真の顧客の参加
○ユビキタス言語
×スタンドアップミーティング
○コーディング標準
○イテレーションデモ
◎報告
この中で一番重要なものは「信頼」だ。
これは開発に限らず、すべての場面で必要なもの。
特に顧客との信頼は重要だ。
本書では顧客などのステークホルダーから信頼を得ることに重点を置いている。
「信頼」があれば、仕事は任せてもらえる。
・リリースすること
△完全Done
バグなし
◎バージョン管理
△10分ビルド
△継続的インテグレーション
◎コードの共同所有
○ドキュメント
「完全Done」、「バグなし」はイマイチ理解できなかった。
小さなストーリーとテスト駆動で実現できるのだと思うが、
実際に適用しようとした場合にイメージが沸かなかった。
まだ、それは理想なんじゃ?という想いの方が強い。
バージョン管理、コードの共同所有は必須。
Subversion、TortoiseSVNがオススメです。
MSのVSSから移行できるなら、した方がいいです。
・計画すること
○ビジョン
○リリース計画
○計画ゲーム
○リスク管理
△イテレーション計画
○ゆとり
×ストーリー
○見積り
ビジョン、リリース計画、リスク管理、ゆとり、見積りは
プロジェクト計画当初、意識するのは一般的だと思います。
ここは特に印象的ではなかった。
しっかりやらなければいけないところではあるけれど。
・開発すること
インクリメンタルな開発
顧客テスト
○テスト駆動開発
○リファクタリング
○シンプルな設計
インクリメンタルな設計とアーキテクチャ
○スパイクソリューション
○パフォーマンスの最適化
○探索的テスト
アジャイルの特徴として、テスト駆動開発があります。
本書ではリファクタリング、シンプルな設計、パフォーマンスの最適化において、
「必要な時に実施する」というポリシーが取られています。
「汎用的にプログラミングするべきだ」という考えがあると思いますが、
本書では、「今、要求されている要件を実現できれば、それでいい」という考えで
プログラミングしていきます。
GoF本のデザイン・パターンの著者の話で
「汎用的にプログラミングすることを推奨していたが、あれは間違っていた」
というような引用をしています。
将来の要件に対応するべく汎用的にプログラミングすることは
高度な技術力が求められます。
それゆえ、バグが出やすいといえるでしょう。
さらに、将来的に出る要件は、時間が経過するにつれて変化します。
これは自社の問題を解決するにあたって、問題分析、優先度付けをしていきますが、
これは時間がたつと話が変わることがあります。
だから、今の要件に対応する分だけ実装しようというものです。
これには同意しました。
ただし、リファクタリングは必要ですよ。
リファクタリングをしないと、スパゲティソースになって
後で変更することが困難になります。
(テスト駆動開発も必要だと思います)
最後に、本書の冒頭で述べられている以下の項目があります。
私はソフトウェア開発に限らず、すべてのプロジェクトで深く理解すべき内容だと考えます。
・成功を理解する
・納期よりも大事なもの
・組織的な正常の重要性
プロジェクトは問題を解決するために発足されます。
当初、見積もられていた予算、期間を超えると、
失敗プロジェクトと言われるかもしれません。
しかし、「プロジェクトが成功する」とは予算、期間を厳守することではないのです。
CRM,ERP導入プロジェクトが失敗したのは何故ですか?
予算、期間を厳守できたプロジェクトは多かったはずです。
何故、失敗と言われたか。
導入したシステムが実際には使われず、
その企業にとって「価値」が生まれなかったためです。
顧客に対して、価値を生むシステムを作ってナンボだと思います。
ソフトウェアはそれだけでは何の価値もありません。
まとめますと、ソフトウェアを開発する側にとって、
プロジェクトで定められたことを守ることが目的で
それによって利益が出ます。
しかし、顧客にとっては、ソフトウェアの開発が終わった後が本番なのです。
顧客にとって、開発中はまだ目的を実現させるための準備期間にすぎないのです。
ソフトウェア開発は顧客にとってリターンを得るための投資です。
このギャップが、何を重視すべきかというギャップが
相互の理解をうまく得られない場合に問題となっているのではないかと思います。
ITはもはや、社会インフラというべき地位を得ました。
ITは社会に貢献できる、すばらしいものです。
私はそれに携われることを誇りに思います。