節度をもって変化を抱擁する - アラン・デービス「成功する要求仕様 失敗する要求仕様」

今の職場に入ったとき、初めてアサインされた仕事が要件仕様の定義でした。そのときに何冊か買った本のうちの、ひとつが、アラン・デービスの「成功する要求仕様 失敗する要求仕様」です。原題が「Just Enough Requirements Management - Where Software Development Meets Marketing」であるということに、今、気づきました。

ケビン・フォースバーグとハロルド・ムーズによるNASAプロジェクト の研究によれば、NASA(米航空宇宙局)が要求活動を含む計画活動に開発予算の5パーセント以下しか充てなかったプロジェクトでは、総コストは40~170パーセント超過した(図1-11)。一方、NASAが全開発予算の10~20パーセントを計画活動に充てたプロジェクトでは、コスト超過は30パーセント未満だった。 (p.21)

計画活動に時間をかけると、コスト超過が起こりにくい。デービスは他のところでも、この例を挙げて、計画に時間をかけるように勧めています。その最初の段階での成果物が、要件仕様、というわけです。

私は、スケジュールが要求を決めるべきだと強く感じている。 (p.23)

最大の不足するリソースは時間だということを考えれば、必然的にこういう方針になりますね。時間は貯めたり、借りたり、増やしたりといったことができない、とドラッカーが指摘していたと思います。もちろん、時間を節約するために、ヒト、モノ、カネを調達することはできるでしょうけれど、時間自体を増やすことはできません。

どれだけ徹底的に導き出しを行っても、要求は変わっていくものだ。問題は変化していく。そして、問題に対する ステークホルダーの認識も変わっていく。要求を洗練させ、議論するうち、ステークホルダーは新しい要求をさらに思いつくはずだ。それでいいのである。ただ、変化に対する備えはしておこう。決してステークホルダーに「それで、これが最終的な要求なんですね?」などと言ってはならない。  (p.55)

耳が痛いです。最後の要求なのか、とつい聞いてしまいます。

一方で、要求を決めないと、設計や実装ができません。だから、多くのアジャイルなプロセスでは、タイムボックスを区切って、その間は仕様変更をしないというプラクティスがあるわけです。

しかし、約束してもいい。スピードと品質は両立できないものなのだ。  (p.67)

これは心しておかないと。そして、それを痛感するような経験もあります。

• 要求への変更は、善であり、悪ではない。 
• 要求変更の流れを阻止しようとしてはならない。 
• 要求変更の流れを管理できるようにならなくてはいけない。 
• どの要求を次のリリースに含め、どの要求を含めないかを決定するために、定期的にミーティングを開く。 
• 10パーセント以上の要求変更を受け入れれば、プロジェクトは失敗するだろう。 

(p.209)

「変化を抱擁せよ。ただし、抱擁できる範囲で。」ということです。その手段として、さまざまなやり方があり、アジャイルな手法はこの前提をもっているように見えます。ですが、デービスはアジャイルがいい悪い、という見方ではなくて、要求のトリアージができるプロセスに、という立場をとっているようです。

構成管理をちまちま始めるヒント集 - 「パターンによるソフトウェア構成管理」バーチャック、アップルトン

構成管理というは、開発プロセス全域に影響があるので、変化を起こすときに大変な思いをすることがあるんじゃなかな、と思います。プロジェクトの途中で、しかも、自分が下っ端だったり、いろんな事情で発言力が弱いときだってあると思います。どっかのこわい話とか、バージョン管理システムについて  の話題とか。

そんなときに、この本のプラクティスをちょっとずつ実践することで、ちょっとずつプロセスに変化ができて、その変化に慣性がついてくれば、大きな変化になるのかも知れません。幸か不幸か、私の職場は mercurial + trac 、最近は　redmine ですし、多少ラディカルな変化も受け入れやすい体質なので、よく分かりませんが。

すべての変更（とその依存関係）が、集約化された統合ビルドプロセス によってビルドされるかどうかを確認して下さい。 p.114

Python のウェブアプリの場合は、本番環境へのデプロイも含まないといけませんね。実行時まで分からないことが多いというのは、こういうとき割と不便です。

新しいメジャーリリース用にコードラインを分岐する時が来たら、前回のリリースラインから新しいリリースラインを分岐する代わりに、まず前回のリ リースラインを本流にマージして下さい。そこから新しいリリースラインを分岐してドさい。 p.62

まず、現行最新版の変更を、メインの開発作業に取り込め、ということですね。

バージョン管理システムを使って、ベンダから受け取ったソフトウェアのバージョンと、顧客に配布したソフトウェアの両方を管理して下さい。 p.123

どっかから拾ってきたライブラリを使用するときには、(1) 本家から引っ張ってきたコードを保持するブランチ/リポジトリ、と (2) そのコードを自分で変更したコードを保持するブランチ/リポジトリで管理せよ、ということです。本家でバージョンアップがあったら(1) に取り込み、つづいて、(1) を (2) に取り込む、ということです。

フレームワークが大きくバージョンアップするような場合には、そうはいきませんが、それはまあアプリケーションからみたら、プラットフォームが変更されるということなので、ここでの議論の対象外です。

それぞれのビルドをすべてスモークテストの対象とし、アプリケーショ ンがあまりにも明らかな形で動かなくなることがないように検証しましょう。 p.145

スモークテストというのは、機械の箱を開けて修理したあとに、電源を入れたときに煙が出ないか確認する、というのが語源です。つまり、よっぽどひどいコード変更をしていないのか、というののテスト。

API を提供するサーバ開発と、JavaScript や Flash で書かれたクライアント開発が、別組織になっているときのデバッグ中に使いました。各 API 個別のテストはもちろん書いてあるのですが、それとは別に、ちょっとした変更を依頼されたときに、スモークテストを走らせていました。

回帰テストのテストケースは、以下の項日から構成するとよいでしょう。

- リリース前の品質保証プロセスで見つかった問題。

- 顧客およびユーザから報告された問題。

- 要求什様に雌づくシステムレベルテスト。 

p.158

（テストがないという意味での）レガシーコードを触るときに、これやりますね。まず fail するテスト書いて、修正して、pass させる。それを回帰テスト（ユニットテストに含めるにしろ、より上位レベルのテストになるにせよ）として残す、と。レガシーコードをいじるときには、いきなり全部のテストを書くわけにもいかないので、変更/修正する箇所から段階的に追加していくことになるかと。

リリース済みバージョンと次回リリースの開発を同じコードラインで対応しようとするのではなく、保守用と継続開発用でコードラインを分割しましょう。 p.171

よい子のみんなは、きっとやっているよね ♡