読書会(アジャイルソフトウェア開発の奥義)第1回議事録

[ 戻る ]


-- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< --
java 読書会 

BOF in てくのかわさき 第5研修室 at 2004/11/27 10:00 - 17:00

出席者(敬称略)
宮本, 西野, 高橋(徹), 坂本,
上手, 金井, 岩室, 根本, 遠藤, 小棚木, 山下, 岩永,
塚原, 横山, 高橋(智), 丸山, 金, 門脇, 
和田, 村上, 杉山, 杉浦, 吉本, 亀井, 栗野, 吉村

スケジュール
    1. 自己紹介
    2. 読み手、書記の選出
    3. 読書会 (12:00 - 13:00 は昼食)
    4. 16:45 - 片付け
        机の並びを戻す
    5. 17:00 - 有志(ニ次会 at 近所の居酒屋)

本 : 「アジャイルソフトウェア開発の奥義」

==

# 一日 100 頁を目標

厚いので、来年の 8 月までかかりそう..
書くのに何年、かかった ?
    著者は、3 人
        紹介されている言語も ( 著者によって ) 異る..

==

読書会の流れ
    (上記の流れ..)
    読み手 : 本を朗読する ( 毎回、3, 4 人で、交替、希望者 )
        随時、質問 ( 割込みも Okey )
        # 眠気防止にも効果あり
    書記 ( 基本的に 1 人 )
        議論の内容を Log
        結果は、ML へ、流す。

==

これまでの実績では、だいたい、一回、50, 60 頁位..

==

# 集まりが悪かったので、少し雑談を...

経緯 ( Internet 協会 [ 旧 java カンファレンス ] の java 部会 / 読書会 )
    1997 発足 ( java object 設計 ) java 互助会 ML で初めた
    ほぼ、毎月 1 回 ( 通算 60 回 .. ? )
    主に、java, 関連した、Programming, 設計の本
        Web で題材を募集して、投票で、読む本を決定

    Internet Week でこの BOF を紹介する予定
        ja-ジャカルタの枠の中に 30 分だけ挟まっているので浮いている

    Q. Internet Week は、有料 ? => YES 12/02 ( 三日目 )
        一応、無料枠 ( 三名分 ) もありますが..
            ML で希望者を募集
        参加料が高い
            割引できるかも..

==

<自己紹介>
    省略

==

序 (p. iii)
    Eclipes の開発をした
    成功の鍵は、プロセスではなく人

訳者序 (p.iv)
    プログラミングは人間プロセス
        数学的な解があるわけではない
    プラクテス/原理/デザインパターン
        個別に記述された内容が纏まって説明 ( 奥儀 !! )
        これまでは、秘伝 ?

    デザインパターンの価値は ?
        なぜ、生き残っていたのか ?
            人間の思惑と、ソフトウェア原理のせめぎあい
        # 天下りでは困る => 過程が欲しい ( 過程が面白い )

    概念に対して、ケーススタディが欲しい

    11 個のオブジェクト志向設計原則

Q. 本当に「デザインパターンの形成過程」まで、書いてあったかなぁ.. ?
    試行錯誤の部分がなかったような..
        # 原書で読んだ時には、気がつかなかった

[まえがき (p.vi)]
    三つのポイント
        原則
        プラクティス
        デザイパターン

    ケーススタディの形で紹介
        ミス => 修正 という段階を踏む
           # 設計の過程がみれる

    Code に本質がある
        詳細の部分が重要(悪魔のように潜んでいる)
    ケーススタディの紹介

Q. java と C++ のコードが入りまじっている.. 作り方の問題 ?
    A. 元々 C++ 屋だから C++ の Code では ?

Q. java に統一したかったのは ? ( 時間がなかった ? )
    A. C++ 屋は C++ 否定して java にという話にならない

# C++ と java の関係は ?

設計は、言語と無関係では ?
    java に書き直す時間がなかったのかも ?

sample code は、直接利用されるわけでなく、デザインパターンの元になるだけで..

java の読書会なのに C++ が混ざっているので、気を付けて
    テンプレート とか STL とか C++ にあり java にないものもある
    # 解らない人は、尋ねよう ( 誰かが知っているさ.. )

(p.viii) XP の衝撃
    あまり、参考にならなかった

(p.ix) Beck
    C++ と smalltalk の衝突 ?

    設計ステップを省略してよいの ?
        実際に、自分自身がダイアグラムの検証にコードを利用していた (XP)

Q. 密室で一人ペアプログラミング ?
    A. 一人で自問自答
    A. ペアになる人がいない ?
    A.「仕様書をかけ」と言う人が必要 ( いないと辛い ..)
        クラス図などは、後から自動生成というアプローチもあるよね !!
        # 「クース」: 電通 ( ひがやすおさん )
            シーサーの開発者
                アパッチなみの組織/仕組を作ることを目標
            一人で提案.. ( 単純な設計方針 )
                EJB は使わない
                    ステートはアプリケーション側
                境界テストはしない..
                etc..

(p.x)
    XP プラクティスで「Test First」 だけが有効
        Test が失敗することから初める

(p.x-xii) 構成, 利用法
    Source Code は URL 経由で入手可能

C. 謝辞/検閲
    (業界?) 有名人が沢山いる ( 日本人はいない )

(p.xiv) 著者紹介
    ローバート=C=マーチン
        ボブ [Bob] おじさん
    ジェームス=W=ニューカーク
    ロバート=S=コス
        .NET プログラマ
(p.xv) 訳者
    瀬谷 啓介

(p.1)
    原理、プラクティス、パターンは重要
        しかし..
            最終的には「人」次第

    人間は、「プラグイン可能なプログラムニット」ではない !!

    「ソフトウェア開発組織」のことを「誰もが同じ顔をした弱
    小集団」と思う会社は競争力を失う

Q. そんな会社あるの ?  
    いやですね..
        Excel の結果をのせて、仕事を要求する..
        営業のとってきた仕事に愕然とするプログラマは多いのでは ?
            PG が営業を評価する仕組が必要なのでは ?

(p.3)
    プラクティスなしに後悔することは多い
        プロセスマネージをはじめるが..
            場当たり的 ( 過去の実績のみ.. ) なプロセス作成は逆効果
            # プロセスを重くする方向に進む

    # 原理に基くプロセス開発をすべき !!
        => アジャイルアライアンス

1.1.1 アジャイルアライアンス

    プソセスやツール    人と人の交流
    包括的なドキュメント  動作するソフトウェア
    契約上の交渉      顧客との協調
    計画に従う       変化に対応

    # 左の価値は認めるが、それより右を重視

o 人と人の交流
    小さなツールから初める
    チームを作ることが重要
    
==

[昼休み]

Q. 「Maneged C++ ?」やりたい人は ?
    GC が入っている !!
        そこでまで C++ がしたいの ? C# で十分では ?
        現場は、未だに.. C++ のまま..
            職場で、結局、どこからか C++ ということが決っていて..

    Java World は、今低調 ( XML ばっかり.. )
        先月の Coding Rule の話題は..
            そんなコメントかかないでしょう。
        ビギナーが特集に上ってきているイメージ
        値段がさがったが、レベルはもっと下った
            日本人にかかさず、もっと翻訳を
        モデリング/フレームワークの話が .. ?  
        読者の対象としてビギナーがふえてきて..
        # アンケート葉書で、フィードバックを !!

==

[午後]

(p.5) 包括なドキュメントよりも、動作するソフトウェア

    人間が読むためのドキュメントは必要 ( コードは人間向きでない )
        しかし.. 氾濫したドキュメントは却って有害

    簡潔で要を得たドキュメントだけが価値がある
        しかし、新人はどうする ? ( 伝える為のドキュメントがない.. )
            先輩がついて、確実なドキュメントとしてのコードの形で伝える

    マーチンの第一法則
        重要で差し迫ったドキュメント以外は作成しない

Q. 差し迫った必要のあるドキュメントって?
    重要でも、差し迫ってなければ不要
        Pull 型 ( 顧客が要求する ? )
        # 顧客も形式的に要求することが.. ?
        # 内と外では重要度が違うのでは ?
        # 説明的な図は必要 ?
        ## 検収に必要なものというのは不要では ?
        ### 法律 (契約) の問題も...

    開発側と顧客の同意が必要
        責任問題 ?
             内容を具体化

    この部分の表現は理念の話なので、詳細を議論してもしょうがないのでは ?
        現実的でない ?
            プラクティスも必要
            次の所で説明があるのでは ?

        欧米人の論理構造は、Top Down
            頭の部分には詳細がないのでは

    # 必要なドキュメントとは、仲間内で必要な情報では ?

    ドキュメントにも二種類
        プログラマ間
        顧客との間

    どのようなドキュメントを最初から、決めている手法もある

p.6 契約の交渉より、顧客との協調を重視
    ソフトウェアは日常雑貨のようには購入できない
        => 品質に悪影響

    顧客からのフィードバックが不可欠

    計画通りには上手くゆかない、契約は結果的に守れない
        => それを重視してもしょうがない

    成功したプロジェクト
        受入テストにパスしたブロックにボーナス
            顧客との共同化へのバイアスになる

Q. 契約そのものが難しいのでは ?
    Q. そもそも、そんな経験のある人は ?
        A. 今やっているのがそんな感じ
    近いことをやっているが.. 交渉担当が Yes Man だと大変
    期間は、?
        3 月単位

    Q. 販売グループをまとめたテンプレートが欲しい

    反復開発が前提 ?
        そのようなグループを作るのも難しい

    Q. 契約までを含めたた事例が欲しい
        A. 経験を積んでいる段階で、事例集めという側面もある。

P.7 計画に従うより変化に対応

    ビジネス環境が変る
    顧客は、システムの開発状況に応じて変化する
        開発は、なかなか変化させることができない

    スケジュールを並べたいマネージャの問題

    Q. パート図って ?
        A. 昔の図 プロセス関係と、実施時間を書き込んだもの
        仕事をプロセスに分割し、依存関係を記述し、クリテイカルパスを見付ける
        PERT : Programing Evaluation Review Technique
        MS Project でかく NS 図 ?
        # 他のものはこれの変形
        # PG の世界には ? (そもそも、時間が見積れない..)
        ## モジュールの依存関係に使える ?

        イメージの共有に利用でききる
            視覚化ツールとして利用可能

    Q. パート図とソフトウェア開発の関係は
    A. プロセスが複雑なシステムでは、依存関係とクリティカルポイントの把握が必要
    Q. ソフトウェア開発は依存関係が複雑か ?
    A. モジュールの依存関係など

Q. 内部と外部区別は ?

    # 論争に参加したので、Log なし

(p.8)
    現実の世界では、形そのものが崩れる

    Q. Pert 図は、分析図であり、スケジュール図ではない。
        適用ミス ?
        初心マネージャとしては、スケジュール表がないと不安

    # アンチテーゼとして書いてある
    # 4つの価値、11 の原則

(p.8) 原則
    優先事項 : 顧客の満足
        一部分でも初期に納品する
        頻繁に納品する
            の二点と最終製品の品質には、相関関係がある

    要求変更を歓迎する
        顧客のフィードバックを取り入れる
        市場の変化に対応する

    実働可能なソフトウェアの納品を頻繁に行う

    顧客と開発者が密接に触れて働く

    人が重要 : やる気のある人をメインに据える
        環境は、その人のために揃える

    もっとも重要なコミュニケーション手段は会話

    実働するソフトウェアこそが進歩状況
        # スループットでの評価 ?

    持続できるペースで..
        マラソンという観点 ( ソフトウェア開発の観点 ? )

    高度な技術と優れた設計
        乱雑なコードを残してはいえけない (リファクタリングとの関係は ?)

    シンプルさが肝心
        # フレームワークはシンプルなの ?
        やらなくてはいけないことだけを行う

    チームは自己管理できなければならない

    チームは、プロジェクトの見直しを行う

(p.11) 結論
    プロセスが重くなるのは、よくない
        XP がよい !! ?

Q. カラー UML はどうなっての ?
    続いていないのでは ( 製品がサポートしていない.. )
    Q. 自分が UML を書いている時にクラスに色をつけている ?
        A. 自分の形で色を付ける
        A. システムが色を付ける
        A. 自分と外というかんじて入ろい
        A. 内と外区別するためにいろ
            Togather (tool) では、Rule Base でいろを付ける
            現状としては、各自で独自にやっている ??
        # この本では、色の仕組を提案しているので...

==

(P.13) 2 . XP

    一つ前は概念だけ、ここでは、その具体的な実践手法 ( プラクティス )

    顧客をチームメンバとして迎いれる
        顧客とは ? def
            仕様を决め、決定権を持つ人物 or グループ

    Q. パッケージソフトの顧客とは ?
    A. ( 決定権をもつ ) パッケージソフトを企画する営業 ?
        仕様を要求するメンバと、お金や決定を行うメンバが異る
            一般ユーザをどう巻き込む
                β版 ? 公開

        ペルソナ : 顧客エミュレータ ?
            「コンピュータは難しい」という本で紹介( アラン.. )

        MS では、マジックミラーごしに、開発者が眺めていて、フィードバックする
        U/I に関しては、フィードバックのフレームワークがきまっている
            デザイン部門では定式化されている

        理想は ? 顧客 ( End User ) を引き込むのが望ましい

        結局、(部外者)一人では(お金と要望の二つを)把握できない
            # 賢いマネージャ ( ブリッジ SE ) がいるだけではだめ..

        # 製造業では、現地生産が多かったが、顧客との距離が問題で、
        # 日本に戻している ( 距離が遠いと、意図が十分に伝えられない )

        ## Network の問題 / 30 m 以内 ? / 顧客先で作業したとき
        ## に、自社との VPN は必要 ( CVS コミットできないと困る.. )

(p.14) 
    具体的な詳細がなくても評価はできる
        詳細があることは認識している必要はある
        詳細は結局変更されるの最初の段階では把握する意味がない

    顧客
        同意内容を Indexing する ( ユーザストーリィの作成 )
    開発側
        ユーザストーリィを実現するために必要な大まかな時間を提示

p.15 短期間のリリース
    繰り返し型の開発 ( イテレーションプラン )
        作業量の見積もりが可能 !!
            実績ベースのスケジューリング
            顧客が再計画する
    リリースプラン ( 6 回程度のイテレーションの纒まり )

Q. 概要の所では、詳細を詰めない
    Q. 何時詰る ?
        A. On Site 決定
    Q. 詳細を省いたときに、しわ寄せは ?

    # 結局、完璧な仕様はどうせ実現できない ..
    #    イテレーションの形で吸収する

    A. 顧客との合意は、ゴールだけ ?
    A. 最初にする内容
        WB Base
            List up
            優先順位
        Q. 展開等は、後で
            後で、できる.. ( その場でよい.. )
        A. 顧客側は業務のプロのはず..
            顧客は User ? 管理者 ?
            エラーメッセージなどは、統一されてはずだが ??
            # Error Log は最初に決らないと... !!
            ##   監視 Tool では見落してしまう !!

        LOG には色々と問題が.. ?
            運用者の User ストーリィ
            Use Case で残らない問題 ?
                運用の Use Case もありうる
                    Log 管理 User Story も必要

        # インフラ屋としては、話の流れがアプリに流れるのが面白い
        # アプリ屋はインフラ屋を意識していない
        ## Log をシステム化しないと System.out に出すことになる
        java では、System.out に出すと、コンテナが拾うので(Log が混在して..) 大変
            # インフラとアプリ Log が混ざるのは困る
            ## Log Rotate で失われる

        # その点の問題点をまとめたら価値があるのでは、
        java なら JMX : インフラ屋に興味がある

    # 良い面もあるが、「全体像がみえない」という欠点がありそう
    #    例 : Logging, Error Message ?

    Log にも色々
        java な Byte Code を書き換えて System.out を Log4j へ..
        Trace Log は、Aspect でも Okey
        Domain Base な Log は、Domain Specific な Tool が欲しい
        Module に特化した Log は、Module でするしかない

    Q. Log 要件って、何時決るの ?
        「ちぶり(?)」的には、ある程度の仕組が決っているので、そこで決定 ?
        インフラ的には、最初に決っているのでは ?
            せめて、フォーマットだけでも決めてほしい
            「業務コード」でしか取れないような問題がある
                # 業務と運用の切り分けがしたい !!
                #    メッセージを分離できれば..
        アプリ的には、後回しにされることが多い
            インフラから、チェックリストを欲しい
            インフラで何ができるかを知りたい
        # 最悪のパターンは、問題点が起きた時に Log からチェックできないこと !!
        ## Tool でとれない Log Format だと困ってしまう..

    XP 的には、「障害検知」というキーワードが必要では ?
        要件定義をしている時には、運用のイメージがわかない

        インフラ的には、運用者が目の前にいることが多い
            インフラ屋や、開発がいなくなった後に運用者が残る
        # インフラ屋も、運用を経験してもらう

    XP 的に要求を突っ込む段階は次の 4 つ ?
        ストリーカード
        タスクアウト
        実装時にオンサイト User に
        リリースの後評価で.. 次のイテレーションで..

    実装(物創り)屋は、ドメイン知識を必要としているのでは ?
        機能だけでなく、運用もイメージできるように..

    System 開発で、どこで適用するか ?
        幾つかの段階やステップがあるので、個々に適用できる所に入れる
            プロがかかわってできる方法論
                # 逆に、視野の範囲外の問題まで要求するのは無理
        # プロの組織化が必要

    Log を System.out に出さないことは「コーディング規約」で縛る

    短期リリースの場所の所で、段々、運用の視点を入れてゆく
        # 結局、Logging は後回しになる .. らしい ..

        Log の形式 vs. Log の内容

    Logging 等の運用などは、開発側から出すことが多い
        運用フェーズ専用のチームを短期間、割当る場合もある
        最初の短期リリースの段階まで待つ必要はあるが、そこでやれる
            顧客側でも、簡易実施環境があって、検証できることが条件 ?
                実験運用
                仮運用 (?)
                    リリースしたら実際に利用してもらう
                # 顧客をそこまでまきこむ

            先に入力モジュール部分だけを要求されるかも
                # 表示は最初は、しょぼい
                後から表示関係を詰る

            # 実際に、顧客側の環境で動くことを想定する

        イテレーションの中で、本当に、顧客をまきこむ
            # Start up 手順がきまらなかったり ??

==

Q. イテレーションは期間限定 ( 2 week ) ? ストーリがはいらなかったら ?
    A. Yes, 限定する。ストーリをみじかくする
    期間をのばしてはいけない

==

p.14 ユーザストーリィ

    受入テストを用意する
        スプリクト
        受入テストは別グループにまかせることがある
            それだけ重要

    Q. スプリクトって ?
        A. junit ? / National Test Manager Test Script
        User 行為のスクリプト
            テストの実行スクリプト
        受け入れテストの要件 ?
            顧客の出す要件のテスト内容
                検収テスト
        jhyson とか .. ?
        Tool は何でもよい
            # 言語も拡張される ?
        負荷 tool / 自動化 tool

p. 16 ペアプログラミング

    一方がコーディング : 一方がチェックを行う
    役割は交替 ( 1時間で何度も交換 )
    チームも一日一度は交換する

    Q. CVS の Author はどうするの ?
        A. チーム名 / 責任者
            # 個人の責任/名誉は ? : 意味がない
            CVS の ID はマシン名
        一日二回ペアをかえる

    Q. 週 40 時間は Okey ?
    A. 努力しているが、リリース前は超過してしまう。

    Q. Commit するときには ?
    A. 変更点を入れる
        ストーリィによって、自動的にきまってしまう ?

    Q. 内は WF (water fall model) なんで、PP (pair
    programming) だと変に思われる。会社が認めている ?

    A. チームに開発がまかされているので、チームが同意すれ
    ば、それ以上に、顧客が認めるれば.. (会社は関係ない
    .. このチームは、会社内では異色と考えられている..)

    Q. 実践例はめずらしいが効果的 ?
    A. 初級者と初級者の組み合わせはあまり意味がない
        初級者と上級者の組でやると、教育が進む
        同じレベルじゃないとだめ ? そんなことはない
            スキルより、人間関係
        Q. キーバインド問題は ?
        A. 諦める ( 予め決めておき、統一する )
        A. ツール問題かも ( 一瞬で切り換えるソフトが欲しい.. )
        A. 会話がメインになっているので、開発環境のスピードは
        気にならないのかな ?
            実際に入力速度さがっても気にならない

p.16

    ペア間で知識の移動と、ペアそのものの変更によって知識の
    拡散が進む

P.17 テストファースト
    最初に、テストを失敗させる
        テストケースがプログラムを先導する
    回帰テストが容易なのでリファクタリングが容易

    共同所有
        得られたコードは、どれも共有される
            専門家は排除しないが、専門外の Task が
            割当られることはある
                専門分野をふやす機会が得られる

p.18 継続なインテグレーション

    CVS を使う
        早いもの勝ち
            マージ作業が必要
                チェックインのタイミングを早める
                前のプログラマと相談する

    全ての作業が、できるだけ新しいコードに基いて作成される

p.18 持続可能なペース
    残業は許されない ( リリースの最終週は例外 : 全力疾走 )

p.19 オープンワークスペース
    ペアの作業も結構近くに
        つかずはなれず
            他のペアにトラブルがあれば、周りが気が附く程度の距離

p.19 計画ゲーム

p.20 シンプルに
    短期間の視点
        先のことを考えない
    必要に応じて、D.B. やミドルを用いない
        目の前にあるものだけで実現する

    Q. インフラを選ばないと設計できないのでは ?
        A. 必要ならば入れる

        # SEer の設計は、インフラが入っている
        #    見積もりが必要なので、しょうがない..
        #    商習慣の問題

    Q. 最終段階のコストが判断できない
        A. プロトタイププロジェクトを挙げる

p.20 「あとで必要」になんてならない
    今必要なものだけで..
        # 今必要であることがきちんと証明できなければ入らない

p.20 同じことは二度しない
    重複をみつけたら、直に削除する
        => テンプレートパターン / 抽象化

p.21 リファクタリング
    # 主に 5 章
    機能を変えずに、構造を変更する作業
        => コードの劣化を減らす
        変更を行なったら、すぐに test する

    # 何時でも行う ( 30 分おき.. )

Q. 今の仕事で、コードをリファクタリングしたい。テストケースがないんだけど..テストケースを作るべき ?
    A. YES
    でも、テストケースがつくること自身が難しいが..
        テストケースがない作業は、リファクタリングとは呼ばない ( 定義から .. )

    再構築 : テストが作れる状態にする (リファクタリングの前段階)
        レガシィーコードの再利用の本もある

    最初に構造を変えるしかない

Q. テストファースト ( 熱中症になる )
    Q. 熱中症になったことがあるか ?
    A. テストの陰鬱なイメージがなくなる
    A. 最終結果の所でテストするとダメージが大きい / 単体だと解りやすい
        「完成」の楽しみを前倒しに..
    テストケースを要求する
        顧客側が最初に要求してくれると嬉しい
    # Jtest の良いところは、テストできる所が視覚的に把握できる

    # 皆が熱中症になっていることは良く解った..

p.21 メタファー

    メタファーは実際的でない ? ( はずすという人も多い.. )
        でも XP 的には、メタファーは重要
        # ジグゾーパズルの例
        ## Bottom up より Top Down ってこと ????
    # Q. イメージの生成に失敗したら ?
    #    イメージを間違えないように打ち合わせを ??

Q. 本当に、「しょくぱん」なんてクラスを作るの ?
    A. そうらしい

    ## メタファーの説明自身がメタファーなんで..

P.25 (プランニング) 計画ゲーム

    XP ではプランニングに関して詳細化している

    顧客 : ユーザストーリィ
        最初に集める必要だが、途中から追加してもよい

    設計者 : ユーザストーリィに対して、見積もりを行う
        Point 単位 ( 相対評価 )

    ユーザストーリィの粒度が問題
        大きいと、大きく見積ってしまう
        小さいと、小きく見積ってしまう

    実際の見積もりには、「Point × 速度」の形の絶対的な評価が必要
        その単位で、ストーリィの粒度を决める必要がある

    Point の見積もりは、相対的なので、最初に行える
    速度の見積もりは、プロジェクトが進むに連れて正確になる
        速度を知るために、プロトタイプを行う ( スパイク )

    Q. スパイクの訳語は .. ?
    A. 意訳すれば、「最初の一歩」とか「橋頭堡」かな ?????

p.28 イテレーションプランニング
    # スケジュールは、Top Down だが、「波頭」がある
    イテレーションが始まったらストーリィは変えない
    イテレーションは、期間を决めて動かさない
    「速度」は直前の実働結果を利用する
        「速度」は、状況に応じて変化するものと考えてよい

p.28 タスク
    # Q. タスク分割は ?
    自分で仕事を選んでゆく
        マネージの仕組が背景にある
        全体の状況をチーム全体が把握する
        自分の能力の把握も可能

        # 調整も行う

    Q. 本当にできるの ?

p.28 中間地点
    再度、進行状況を把握し、再スケジュール
        Point は、タスク単位ではなく、ストーリィ単位 !!

    顧客は、「動く物」が得られる
    顧客は、「望む順」に得られる

    # XP の利点は、出資者が、作業の流れをコントロールできること

    Q. プロジェクトは何時終るの ?
        A. お金の切れ目が..

    all or nothing は悲しい...
        部分的に入手できると..

    早めに判った方がよい
        重要なものが先 ? 難しいものが先 ?

    見積もり ? ( 性善説 ? )
        チームのメンバがバッファをとってしまうと..
        # 顧客が前にいると、サボれない
        ## 缶詰になるので、8 時間しかできない
-- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< --


[ 戻る ]