[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[jfriends-ml 11612] 「アジャイルソ フトウェア開発の奥義」 : 第一回議事録 (案)
栗野＠日大です。
2004/11/27 に行なわれた、「アジャイルソフトウェア開発の奥義」
の第一回 議事録(案)をお送り致します。
[注意] 議事録の読み方について。
本来は、読書の途中で、出て来た質問とその回答、コメント等の記録
を取る ( 本の内容は、本自身を読めば済むので.. ) ことが目的のよ
うです。
僕は初めて参加だったので、上記のようなルールをしらず、本の内容
の方の Log も取っているので、大変見づらいかと思いますが、御容
赦ください。
以前の議事録との互換性のある部分は、原則として、
Q. や A.
で始まる部分で、この部分が、主に参加者の発言の記録です。他の部
分、特に、p.xx と書いてある部分は、どちらかというと、本を読み
上げている時に、僕が個人的に、大事だと思ったキーワードが入って
います。
# その意味で、客観性を要求される議事録なのに、主観性たっぷりの
# 内容になっています。
-- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< ---- 8< --
java 読書会 <http://www.javareading.com/bof/>
BOF in てくのかわさき 第５研修室 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 図は、分析図であり、スケジュール図ではない。
適用ミス ?
初心マネージャとしては、スケジュール表がないと不安
# アンチテーゼとして書いてある
# ４つの価値、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 ペアプログラミング
一方がコーディング : 一方がチェックを行う
役割は交替 ( １時間で何度も交換 )
チームも一日一度は交換する
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< --
--
栗野 俊一 <kurino@xxxxxxxxxxxxxxxxxxxxxx>