『アジャイルな見積りと計画づくり』第01章のコメント・疑問

１．doubledispatch:

疑問点ではないですが、陸軍元帥の言葉が気に入りました。使いたいです。

「計画することがすべてだ。立てた計画はどうでもいい」

【当日の議論】

実行のために計画使用とすると、前提条件・不明点・リスクに気づくから「計画する」ことが大事(doubledispatch)

計画通りにプロジェクトや戦争は行かないから、臨機応変に再計画を高頻度でする。立てた計画はバイブルではない。

→だからどうでもいい。(daxanya)

モデリングすることがすべてだ。モデルはどうでもいい。というフレーズをアジャイルモデリングの中で見た。(yama__moto)

【おまけ】

ヘルムート・カール・ベルンハルト・フォン・モルトケ元帥はプロイセンの軍事学者。対デンマーク戦争・普墺戦争・普仏戦争

に勝利してドイツ統一に貢献した。甥も第一次世界大戦時の参謀軍事議長で有名なので、区別するために大モルトケという。

2.doubledispatch:

P34中段で、「計画が簡単に変更できるようになっている必要がある。」とあり

ますが、この意味は「長期間に詳細にブレイクダウンするな」というニュアンス

でいい？

それとも、マネジメント上や契約上の厳格な変更管理・承認手順により、

臨機応変さが失われることがマズイというニュアンス？

(daxanya)どっちとも取れますね。詳細に計画を立てすぎると、変更時に変更箇所

が多くなりすぎて変更しづらくなる。

もしくは変更しようと思っても変更プロセスに時間がかかると、変更し

づらくなる。変更しやすさというのは、結構さらっと書いてますけど

難しい部分があるかと思います。

【当日の議論】

変更プロセスが長いと承認のスタンプラリーが終わる前に、事態がさらに進んでいる。

⇒変更管理手続きは簡易なのが望ましい。(daxanya)

チーム間の引き渡しタイミングの変更は他チームに影響を与えるので、簡単に変更できない。 (Ｙｏｕ＆Ｉ)

⇒日々のToDoの期限の変更は現場に決定権を移譲し、大きなマイルストーンの変更になると

承認行為が必要等、レベルの切り分けが大事と思われる。(doubledispatch)

3.kaku_kaku:

P29『「フィーチャ」という言葉を本書では、ソフトウェアの機能、特性や特徴...』とあるが、

中段あたりの『各画面はそれぞれ機能であるがフィーチャではない。』とある。

各画面単独で『欲しい商品を注文できる』を実現できないので、フィーチャにならないということか？

(Ｙｏｕ＆Ｉ) ここの一文を読んで、自分はUX(User Experience)的な話かなと思いました。

例えば、Amazonにおける1-Click注文システムとか。

でもそう定義すると、1-Click注文システムにおいて各画面は必要であり、2章の機能

ベースではなくフィーチャベースでスケジューリングする話にうまく繋がってくるかも？

(daxanya)フィーチャーの定義に「機能」という言葉が入っているのはちょっとわかりにくいかもですね。

フィーチャー＝「売り文句」に値する、機能、性能、特性、見た目と考えると少しましなのかも

しれません。それがそのソフトウェアの売り文句に値する機能なのかどうか。

例えば商品選択画面をすごくシームレスにさくさく選べるようにできれば、それはフィーチャー

となるかもしれませんが、どこにでもあるような機能しかないとするとそれはフィーチャーとは

呼べないみたいな。

【当日の議論】

・フィーチャを差別化する特徴的な機能、叶えたい主目的としてみると、派生機能に対する作業が漏れないか？(daxanya)

・フィーチャの定義って何だろう。侃侃諤諤(daxanya,Ｙｏｕ＆Ｉ,bleis,a_hisame,mayonezudaiou etc)

・フィーチャ・ドリブン・ディベロップメントもあるけど、その場合の駆動するフィーチャは、ユースケース駆動のユースケースと

何が違うの？栗林さんがフィーチャについて昔語ってたなあ(doubledispatch)

・ファウラーのぶりきじゃに、ローラースケート実装の逸話があった。商品購入のWEBサイトを提供する目的を数か月早く

リリース可能であるなら、バックエンドシステムへの入力を人力でローラースケートの派遣女性が行う実装でも問題ない

という逸話がのってた。これは、フィーチャを提供してっるってことかな。。(doubledispatch)

⇒注文先を記述するWEB画面しかなくて、他の機能がないけどそれは漏れじゃない。次回リリースで提供されるフィーチャ

という文脈。上記までの議論は、最初にトータルの仕様がある前提で語るので、フィーチャ以外の機能の漏れを気にした

けど、フィーチャを小規模に少しずつリリースするつもりの文脈では気にしてないということかな？(doubledispatch)

※まあまあ受けて、賛同されたので紹介してよかった。

Martin Fowler's Bliki in Japanese ローラースケート実装

http://capsctrl.que.jp/kdmsnr/wiki/bliki/?cmd=view&p=RollerSkateImplementation&key=%A5%ED%A1%BC%A5%E9%A1%BC%A5%B9%A5%B1%A1%BC%A5%C8

4.Ｙｏｕ＆Ｉ:

P.30 ステークホルダー：利害関係者。取引先企業等。

金銭的な利害関係の発生する顧客や株主だけではなく、企業活動を行う上で関わるすべての人のことを指す。

Ｔｗｉｔｔｅｒで話が出ていましたが、P.35の章末の「話し合ってみよう」を皆で話し合ってみよう！

5.daxanya:

P.31 1-3.意思決定を支援する －意思決定の前提として、これを作るといくら儲かるのかが

大前提としてあるわけですね。逆に言うとオープンソースソフトウェアは、意思決定支援が

いらないから見積もり不要という話になる？ 後ででてくるのかな。

【当日の議論】

・日々改版されてリリースされてるから、計画駆動っぽくない(daxanya)

・一応計画あるんじゃないかな。Rubyはぐだぐだだけど、12/25ターゲットだし、Eclipseも年１回だし。(bleis)

・だからこそ、Eclipseはオープンソースっぽくない。スポンサーのIBMに対する義理から期限が生じてるような。

例として微妙(daxanya)

・バグフィックスは高頻度だけど、メジャーアップデート(ファイルシステムの変更とかロックの粒度とか）はターゲット

おいて段取り組むんじゃないのかな。どうやってやってんだろう(doubledispatch)

■話合ってみよう

【（スタッフが固まる年配側テーブル）】

選択したテーマ：３．これまでにうまくいったプロジェクトで、計画づくりが果たした役割をはなしてみよう。

(doubledispatch)：初めて小規模チームのリーダーをした際、後輩１年目と２年目の女性と委託の年配SE２人で一日、

お菓子を食べながら要件定義からリリースまで１年間の概略予定を話した。いつごろまでに何

ができてるべきか、事前準備として何が必要か、話してホワイトボード一枚にタイムラインを書いた。

丸一日話したことを、後輩達がA3１枚にまとめてくれて、後は工程ごとにそれをブレイクダウンして

ガントチャートを引いて仕事を振った。

自分の首が回らなくてスケジュール詳細化が遅れたり、指示ができなくても、委託さんたちも彼女

たちも待ち時間に前倒しの準備作業をいつもしてくれてたから乗り切れた。詳細化した作業のToDoを

与えてない時期でも、１年のタイムラインのA3の紙を大事に参照してフィーチャ実現のために動いててくれた。

→１年前にその打ち合わせを主催した自分が忘れかけてたのに。。。。

(????) ：シャドウワークの見える化ができるのが、計画づくりのいいこと。リリース昨日を列挙したガントチャート

以外の仕事を洗い出す。

(????） ：計画づくりって、GTDを共同でやってるみたいですよね。

(yama__moto) ：システムの全体とか、工程の全体がわかると作業者じゃなくて、参加する担当者として能動的に

なってくれますよね。

(????) ：余裕が大事

(daxnya) ：一人で把握できる限界がある。（⇒だから計画づくりが必要、という議論の流れでよかったですか？）

【若者が多いテーブル】

議論内容を思い出して書いて頂けると助かります。次回はファシグラしましょう。