プログラマの思索

はじめまして。
いつも参考にさせてもらっています。
アジャイル開発の進め方はある程度は理解できるのですが、実際に現場で適用しようと思っても見積り、計画段階で悩んでしまいます。
理由はある程度はっきりしていて、開発作業の分母が曖昧なので、見積りの精度が上げられないためです。
私は、長い間ウォーターフォールベッタリの開発だったので、その考え方がなかなか抜けないせいもあるとは思います。
あれこれ考えているのですが、結局は仕様変更に伴う工数（このあたりは感や経験しかないのでしょうか…）を、見積り時にバッファとして上乗せするくらいしか思いつきません。
このバッファが無ければ、仕様変更＝工数オーバーとなってしまいます。
ウォーターフォールとは違い、出来る限り早い段階で仕様変更を受け入れることで、それに伴う工数を最小限に抑えられると言うことなのでしょうか。
何かヒントが見つけられればと思いコメントさせて頂きました。
長文失礼致しました。

◆mgさん

こんにちは。
いつもBlogを読んでもらってありがとうございます。

＞ウォーターフォールとは違い、出来る限り早い段階で仕様変更を受け入れることで、それに伴う工数を最小限に抑えられると言うことなのでしょうか。

最初に断っておくと、Blogなので、記事の内容も、このコメントも僕の一意見に過ぎません。
僕は、純粋なアジャイル開発というよりも、アジャイル開発で理解できたいくつかのプラクティスを応用している感覚です。
mgさんの現場で使えるかどうかは、僕は分かりません。

アジャイル開発のプロジェクトマネジメントの観点は、製造業のようないわゆるQCDではなく、スコープ(機能)・コスト(工数)・スケジュール(納期)の三角形で調整します。

アジャイル開発では、複数回のリリースを前提に開発していきます。
なので、リリース計画を作る時に、顧客の要望と工数、期間をトレードオフしながら、開発してリリースしていきます。
仕様変更に対応すれば当然工数がかかるので、今リリース予定している機能を削るか、リリース時期を延ばすか、顧客と調整する必要があるし、開発チームはその理由を説明する必要があります。

「品質はスケジュールよりも優先する」というソフトウェア開発の原則を開発チームだけでなく顧客にも理解してもらい、お互いにWin-Winの関係に持っていけるように、心がけるのが大事だと思います。

あきぴーさんこんにちは。
コメントどうもありがとうございます。
スコープ（機能）・コスト（工数）・スケジュール（納期）で顧客と調整すると言う観点は、特別意識していた訳ではありませんが、“この期間ではここまでしかできません”と言った調整はやっているような気がしますが、こちらの一方的な都合を言っていたような気がします。（Win-Winの関係を持つと言う意識が薄かったと…）
あきぴーさんの仰る通り、人のやり方（考え方）がそのまま使える訳ではないのは重々承知しています。自分なりに咀嚼したうえでヒントにできればと考えています。
どうもありがとうございました。