阿部です。
>> 進捗が気になってしょうがないのは上司の常では？と思ってるんですが。
>> ですから、テストの半分くらい（エラーコードが帰ってくるパターンとか）
>> は後回しにして、基本的なテストを先に書いてから機能の実装に入ります。
>>
>上司の目は関係ないですね。
>最初にタスクに対して見積もった通りに進捗できていれば良いでしょう。
タスクの見積もりとは、ストーリーカード、タスクカードを書いて
その作業量を見積もる＆実装順を計画にいれる、という事でしょうか？
＃もっと広い意味での「タスク」と言っているとは思いますが。
辻さんに言われましたが、どうも「テスト・ファースト」という言葉
自体の意味にこだわっていただけかもしれませんね。テストを書くという
行為に、「すべて列挙すべき」という思いがあってそれで「できていない」
と思い込んでいたように思います。
>> そうすることで「テスト・ファースト」は破られてしまいますが、毎日
>> ほぼ確実にテストが１００％成功するコードをコミットできます。
>> XPで「テスト・ファースト」が重要であっても、私的なプライオリティでは
>> 「テストに成功したものだけをコミットする」という方が重要です。これは
>> チーム開発する上でCVSを用いて開発している関係上、動きもしないコードを
>> コミットされると困る、との判断からです。
>
>テストファーストと"動きもしないコードをコミットされる"
>は、関係ないと思います。
継続的インテグレーションのサイクルとしてテストに合格したコードを
コミットする、といったもの（どこまで正確かいまいち曖昧ですが）があったと
思いますが、上記のように「すべて書く」といった点にこだわったため、
その「すべて」よりも「動くコードをコミットするほうが優先」と書きました。
「テスト・ファースト」の意味合いを誤解していた所為で、終わらないテスト
にこだわっていつまでもコミットできないのはチーム間でコードを共有する上では
まずいだろうとの思いがあり、テスト・ファーストは守れない、と書いたわけです。
-------------------------------------------------------------
Takashi Abe <abetaka@....jp>
HP: http://homepage1.nifty.com/taka-page/
合気道 薫友会 : http://homepage2.nifty.com/kun-yu/index.html
-------------------------------------------------------------