Mike Cohn / アジャイルな見積りと計画づくり

最近関わっているプロジェクトは、本質的に機能の不確実性が高いということが多いプロジェクトです。ですので、不確実性、あるいは計測/制御でいうところの誤差、をコントロールするという視点で、プロジェクト管理できないかなぁと考えている今日この頃。

「アジャイルな見積りと計画づくり」を、誤差のコントロールの視点から読みました。実験的にやっていることや、今後、やっていきたいなと思うことのメモです。

従来からある計画手法の多くが犯している誤りは、フィーチャをプロジェクト開始時に固定 できると信じていることだ。そのため、いったん計画を立てたら、その後は変更を認めなかっ たり、複雑で手間のかかる変更管理プロセスを強制して計画の変更を阻害したりしている。 (p.261)

前提が間違っている、と。もちろん開始時に固定すべき/固定できるプロジェクトは存在する。けど、そうじゃないなら、そうじゃないなりのプロセスが必要で、ほかができなくて自分たちができるなら付加価値になる。

「2週間後には、今日よりも多くのことが明らかになっています。イテレーションでなにをすべきか決まっていないのに計画を立てる理由があ りますか?必要ないんです。大規模なプロジェクト、特に複数のチームから構成されている プロジェクトでは、作業の連携のために2イテレーションか3イテレーション先まで計画することがあります。ですが、いまの私たちには必要ありません」 (p.303)

ある程度の、おおざっぱに見積もりは、もちろん必要。でも、細かい見積もりは不要。「精度」という語彙は曖昧なので、確度と分解能と言えばいいかな。確度が高いことは大事だけれど、分解能は低くてよい。

1ポイントのストーリーよりも短い時間で完了できる2ポイントのストーリーがあるというのは、まったく理にかなったことであり、予想の範囲内でもある。(p.179)

誤差は含む。見積もりは期待値分布の代表値にすぎない。ひとつのタスク、ひとつのストーリーの誤差で一喜一憂していはいけない。もちろん傾向として、全体的に20%オーバーするとかであれば、見直しがひつようだけど。

スパイクとはイテレーション計画に含める タスクの一種で、何らかの知見を得たり、疑問を解消することを日的に取り組む作業のことだ。[...] スパイクを実施すれば2つ目のタスクヘの見通しが得られるので、 このタスクをより正確に見積もれるようになるのだ。 p. 170

まず、おおざっぱな見積もりをして、そのあとで実際のタスクを見積もり直す。もちろん誤差はある。でも、コントロール下に置くことができる。

大きなストーリーはストーリーでおこなう操作に沿って分割すること。 p.140

例として CRUD する場合には、Create でひとつのストーリーにする、というもの。Django の場合は、管理画面でDBテーブルの内容を見るのがカンタンなので、これはありだと思いす。実は今のプロジェクトで、この区切りを使っている。

大きなストーリーの機能要求と非機能要求とをそれぞれ個別のストーリーに分割すること を検討せよ。 (p.142)

今のプロジェクトで実験中。まして、パフォーマンスがどの程度かやってみないと分からないので、まずは正しく動く機能を実装しています。

岡島幸男/受託開発の極意

要件定義について最近よく考えたり、実験したり、実践したりしています。そんなわけで「受託開発の極意―変化はあなたから始まる。現場から学ぶ実践手法 」から要件定義関連で気になったことをメモします。

手段の話が先行すると視野が狭くなり、お客さまが本当に実現したいことからかえって遠ざかることもあります。たとえば 「ユーザが入力したデータを保持する」という目的を実現するにはいくつもの手段がありますが、「SQL Server にデータを保管する」という手段に限定してしまうと、ほかの手段を検討する機会を失うことになります。 (p.56)

つい実装よりのことを考えてしまうのですが、そこはぐっとこらえるようにしています。なんだったら、DB に格納する、というコンセプト自体を疑えるようにしたいです。だから、要件は明確にしつつも、レイヤーの高いところで話をしないといけない。オブジェクト指向分析っていうのは、本来そういうためのものじゃないかなぁと思っています。オブジェクトが最終的なクラスになる必要はないですが、分析段階で認識出来る抽象的な「モノ」があると何かと便利です。

特に重要なのは業務フローです。システムの提供する機能だ けではなく、手作業やほかのシステムも含めた「お客さまの業務そのもの」を表現します。(p.59)

要件定義の結果、最終的には「システムは何をすればいいの？」ってことが分かればいいのだけれど、その途中で、外部で何が起こっているか、すくなくともシステムから何が知覚できるのかは書いておかないとシステムは作れないと思います。顧客の立場では逆もしかり。業務フローもちゃんとまとめておくというのは共感です。


それから丸投げ対策なんかも書かれていました。丸投げの発生はしょうがないと考えています。これまでシステムのことを考えもしなかった人たちが、システムを新たに使ったり発注したりするでしょう。そのときに、丸投げすんなって言ってもいいけど、逆にそういうセグメントをターゲットにすることだってできると思います。クリステンセン「イノベーションへの解」にならうなら、最も供給が不足するところに利益が集まるわけです。


さてさて、別な話とみせかけて、スケジュールの話も。

要件定義フェーズで怖いのは「いつになっても終わらないこ と」です。このままでは時間切れで開発に突入してしまいます。 お客さまに進捗を示すことは重要です。ヒアリングも回数を重ねると堂々巡りになることがあります。前回の課題を継続検討していたり、「そもそも論」に立ち戻っていたりしてはスケジ ュールどおりの完了は見込めません。(p.56)

仮に仕様変更があることを前提にした開発であったとしても、前提条件としての仕様は明確にしておいたほうがいいですね。自戒も込めて。でないと、変更が発生したときに、どのくらいの規模での変更があるかさえわからなくなります。規模に影響する要件定義はできるだけ早く決めていくようにしよう、と改めて思いましたとさ。

トム・デマルコほか / アドレナリン・ジャンキー その3

アドレナリン・ジャンキーの続きです。

20 一人一役

仕事の一部（コンポーネント、任務、目標、アクションアイテムなど）について単独で責任を引き受けるとき、その人が役割を理解して引き受けるのは、作業と期待される結果が明確に対応しているからである。[...] ひとりで責任を引き受けたからといって、同僚やその他の関係者に協力を求めたり、必要な意見を得たりしてはいけないということではない。肝心なのは、任務を受けた人がその部分について引き続き責任を負うことである。(p.64)

単純には役割分担だけれど、実際には、役割の境界がプロジェクト開始時には不明瞭な場合だってあります。そういうときでも、任務をまっとうする責任を負えるカルチャーがいいなぁと言う話です。一方で、知識がひとりに集中してしまうといけないので、情報の共有やレビューは大事だと思います。XP ではペアプロをすることで共有するわけで。

別に特定の責任を負うからといって、他のことを知らなくていいわけでもないし、知らせてはいけないわけでもないと思います。そういう次元ではなくて、アサインされたタスクをちゃんとやろうぜ、と。そのためには、期待される結果が明確になってないといけないわけです。耳が痛い話です。

21 ソビエト式

どうすればソビエト式 [要求した機能は備えているが使う気にならないような] の製品をつくらずにすむだろうか。それには、プロジェクト計画に、明確に機能面以外の要求を対象とする作業を組み込むことだ。こう言うと簡単なようだが、ソビエト式のシステムのほとんどは、機能面以外の品質があっさり無視されたためにソビエト式になったことを考えてみるといい。 (p.70)

このあたりは、37 Signals のどっかの文章に書いてあった、インタフェースから考えるだとか、ストーリードリブンな考え方とかが合うのかも知れない。このところ、内部の機能よりも、ユーザの眼に触れるところから考えるようになっています。ほとんどのばあい、ユーザに見えるのはUIなわけですから。あるいは、APIとか。いずれにしても、外側での振る舞いの期待と実際のギャップを埋めるようにしています。難しいですけどね。