オライリー君のシリーズで、つい手を出してしまうヤツがある。アート・シリーズがそれだ。技術に芸術を見、取り組みは泥臭くても成果物は美しくありたい。そんなことを、ぼんやりと考えながら...
しかし、芸術の道は険しい。芸術的に生きることは、さらに難しい...
さて、ソフトウェア開発でよく耳にする「アジャイル」という言葉。おいらは、こいつをマネジメント用語と解している。ソフトウェアに特化したものではなく、あらゆる開発現場で参考にできると。ちなみに、おいらはプログラマでもなければ、ソフトウェア業界の人間でもない。
アジャイルを実践する！と声高にアピールする人を見かけるが、本当に実践している人たちは、そのような用語をあまり使っていないように見える。自然体でいるような。オブジェクト指向という用語にも、似たような感覚が見て取れる。無意識に実践しているような。アジャイルチームの特徴は、自己組織性にあるという。自主的で自立的であれば、用語に振り回されることはないだろう。ましてや流行語に...
「『アジャイルになる』というのは何を意味するのか？この質問の答えは、思った以上に複雑だ。アジャイル開発は特定のプロセスに従えばよいというものではない。アジャイル手法を実践しているチームというものはない。そういうものじゃないんだ。アジャイル開発とは理念だ。ソフトウェア開発についての考え方なんだ。」
副題には、「組織を成功に導くエクストリームプログラミング」とある。ここでは、アジャイル開発における手法の一つとして、XP(エクストリームプログラミング)を中心の据えている。それは、短期間で頻繁にリリースすることを推奨するもので、具体的には、リファクタリング、コードレビュー、ペアプログラミングといった手法が紹介される。
ただ、新しい文化を取り入れるには時間がかかる。数ヶ月ぐらいの覚悟がいる。それでも取り入れる価値があるかどうか。プロマネは、いつもそんなことを考えながら仕事をしている。改善においては、貪欲でありたいと。その道のメンターがいるとありがたいが、現実には難しいので、自らメンターを演じようと...
そして、アジャイル文化は、極めて民主主義的で、自由精神の体現にも見えてくる。ファシズムの時代には、民主主義を統一を欠いた社会、自由精神を道徳の退廃と吹聴されたが、現在では民主主義が連呼される。価値観なんてものは、何を転機に逆転するか分からない。
チームの運営では、個性は統一を欠く要因とされがちだが、個性がチームとなった時の能力は計り知れない。なにより仕事をやっている連中が楽しんでやがる。マネジメントで深刻なのは、技術の問題よりも人間の問題だ。そのための第一目標は、やりがいのある仕事を提供すること、そしてプロマネ自身が楽しむこと、顧客も巻き込んで...
「変化が人を不快にするというのはまぎれもない事実だ。XP はチームにとって大きな変化だろう。もしこれまで融通の利かないドキュメント中心のプロセスを使っているなら、XP は形式的でなく、だらしなく見えるだろう。」
1. アジャイルマニフェスト... 価値と原則
アジャイルの価値は、4つ...
- プロセスやツールよりも、人と人との交流を。
- 包括的なドキュメントよりも、動作するソフトウェアを。
- 契約上の交渉よりも、顧客との協調を。
- 計画に従うよりも、変化への適応を。
これを支える原則は、ざっとこんな感じ...
- 最優先事項は顧客を満足させること。
- 実働可能なソフトウェアの納品を頻繁に行う。実働するソフトウェアこそが進捗状況の尺度。
- 持続できるペースで開発する。
- 高度な技術と優れた設計への配慮は、アジャイル性を高める。
- シンプルさが肝心、やらなくていいことはしない。
- 最高のアーキテクチャ、仕様要求、設計は自己管理能力のあるチームから生まれる。
マネジメント論で耳にタコができるほど聞かされるのが、最優先すべきは顧客の満足度！ここで言う顧客とは、依頼元である。つまり、スポンサー。
しかし、おいらは、顧客という言葉にしばしば疑問を抱く。顧客であるはずの依頼元が、本当の意味で要求を理解していないことがよくある。ユーザの立場になって逆提案をすれば、要求仕様は自分で書くことに。結局、顧客とは、エンドユーザか。それで依頼元を満足させられれば、同じことだけど。
そして、開発途上で状況が変われば、気も変わる。おいらは、仕様変更の生じない開発プロジェクトに出会ったことがない。アジャイルプロセスでは、変化に対応することで顧客の競争上の優位性を確保するという。
また、実働するソフトウェアを頻繁に提供するということは、必然的にテスト駆動開発(TDD)が重視される。そして、開発メンバーの意欲にも配慮したい。品質を落とすような命令は技術屋の気分を萎えさせる。技術的卓越は重要な動機だ。たゆまぬ鍛錬こそが、道を極めるということを...
2. ドキュメント主義からの脱皮
ドキュメントが重要であるという価値観は、今も変わらない。おいらはネアンデルタール人なのだ。
しかし、だ。ドキュメントは、常に最新版に保守されていなければ使い物にならない。それには手間もかかる。それでも、必要ならやるべき。そこで、本当に必要なドキュメントとは何か？これをずっと問い続けてきた。ドキュメント化することで効率化を図れる部分もあれば、無駄を助長する部分もある。
近年のプログラミング言語は、アセンブラ言語の時代とは違い、コードを見れば何をやっているか、何をやるべきかが分かる。うまく構造化され、綺麗なコードであれば。コードの変更にドキュメントの変更が引きずられるなら、何をやっているのやら。一対一で完全に対応している保証は、どこにもない。ドキュメントが仕様の神様にならなければ、悪魔になるだけのこと...
「ドキュメントという言葉にはいろいろな意味がある。エンドユーザ向けに書かれたマニュアルや、詳細な仕様書、APIとその使い方の説明書を意味することもある。いずれによせ、これらはすべて、コミュニケーションの一つの形だ。それが共通点だ... ドキュメントの量を減らすのにリスクは、もちろんある。ドキュメントを減らすためには、別の形のコミュニケーションに置き換える必要がある。それこそ XP がやっているこなんだ。」
0 コメント:
コメントを投稿