です。

作業速度はあまり落ちません、ええ落ちませんでしたとも。 休憩を取る頻度が若干上がりましたけれど。。。

体調がぼろぼろでも、ペアプロしてると手が止まることはありません。 今日は、10月から入った新メンバとペアでした。新機能を作成するタスクへ着手中、新メンバは入って日が浅いので質問してきますし、私はアーキテクチャや現状の設計に至った経緯などを説明…

「アジャイルと規律 ?ソフトウエア開発を成功させる２つの鍵のバランス?」では、メンバ離脱のリスク対策として ペアプロ等で暗黙知を共有しておく 代替要因を予め確保 成功時ボーナスを用意 (して離脱を予防) って論旨。 ↑の想定ケースが今回のには若干当て…

短期リリースって、 動くものを提供する 他と結合可能な状態を保つ ってことなのだと改めて実感。 課題は後者。 それから、やっぱりインフラにハマったですよ。。。 皆様、お疲れ様でした。

今回は、インフラに振り回されたイテレーションでした。 って、前回のイテレーション最終日にも同じコト書いてたな。。。id:manhole:20040903#1094226289 XPで言うところの係数とは別個に、「インフラ係数」が欲しくなってきました。 プログラム作業とインフ…

お疲れ様でしたっ! それにしても、万全の準備をしていてもインフラに踊らされようとは。。。

長い一週間でした。。。 思うように進捗を上げられなかった原因は、ほぼインフラ(地雷)にあると思っています。 次イテレーション以降でどう解決したものでしょうかねぇ。。。 # 速度には反映されるので、同じペースでハマり続けていても見積もりの精度は上が…

されど進まず。これでもかと地雷を踏んでいる最中です。(--; 1週間のイテレーションなのに、水→木→金と絶賛爆発中。。。こーゆー地雷インフラを含むストーリーの見積もりって、どう出すのが良いのでしょう? まず、見積もりの時点ではハマることは予想できま…

英語力が足りてないだけかも。。。 何か指針がないかとぐぐってみた。 全てのメソッドテスト用メソッドには首尾一貫した名前をつける メソッドテストとは単一のメソッドが定義通りに機能するかを検証する活動である。メソッドテスト用メソッドは'testMethodN…

id:t-wada:20040826 テストが失敗したときに何が失敗したのかが一目瞭然 テストの可読性が上がる。日本語のほうがやっぱり読みやすい テストをアサーションメッセージから書くことによって「これから何をテストするのか」が明確に意識される

ソースがない クラスローダまわりの資料がない バッドノウハウ多数 そのプロダクトに精通しているメンバがいない スタックトレースから行番号を取得できても、勝手に生成されるEJBスタブでデバッグできず。 problem 引き際を見定められなかった。 そのプロダ…

先日のミーティングにてお客さんへお願いし、今日の午後数時間 作業フロアに居て頂きました。 今までは 会議室で イテレーションのストーリー選択や見積もりを行う 進捗報告 質問コーナー という形態を取っていましたが、今回は 作業フロアで 受け入れテスト…

未だに、日本語モード 英字モード の切り替えキーに慣れません。 普段使うキーボードの切り替えキー位置が HHK では ESC キーなため、よく間違えて ESC を押してしまいます。 うーん、自分用にもHHK買うべきか。 それとも普段使うキーボードのキーアサインを…

スコープを半分にすると、(時間1/2 * 機能1/2) で、1/4 になるんですね。← 例えば、[縦軸:機能 × 横軸:日] フォーマットの Excel シートとかが。

想像以上に便利です、Eclipse のコードテンプレート。 TabキーでのフォーカスやEnter押下後のカーソル位置指定を組み合わせて、Assert First を"より自然"に行えるような改良(?)を行いました。『TDDer養成ギブス プラクティス集』って面白そうですね > コー…

第3イテレーションのタスク分割を行いました。 今イテレーションからは期間が半分の 1 週間になります。 # 第2イテレーションの回顧 (http://d.hatena.ne.jp/manhole/20040809#1092054631) で、期間が長いとの結論にたどり着いたため。 なので、ストーリーの…

アプリケーションサーバのクセ クラスローダまわり ビルドプロセス改善 1 クリック step でどこまでできるか!? インフラは、早期対策が望ましいです。価値を生み出すモノではないため工数として弾きづらい項目ですが (今回は考慮に入ってますが(^^;)、後にな…

間近に控えた次イテレーションに向けて、技術調査を行いました。別名地雷踏み。今回の地雷は2つです。 開発が始まって間もないということもあると思いますが、インフラ系の地雷が出揃っていないのです。 過去のイテレーションが遅れたほとんどの原因がインフ…

※このエントリは 2004/08/14 に書いてます。 プロセスを改善するため、問題構造ツリーにて 本当の問題 本当の解決策 具体的な解決手段 を探る。

※このエントリは 2004/08/14 に書いてます。 ハンズオンで TDD しました。もちろんペアプロです。(初対面の方とご一緒しました) いろいろと思うところ・謎?な出会い・反省点・気づいたことがありました。 # 個人的にこっそり回顧してみました。衝撃的だった…

※このエントリは 2004/08/14 に書いてます。 議題が多くでました。主な Problem は、見積の甘さやリリース時の反省点など。 ある問題の解決策を考えていく中で、1イテレーションが長すぎるとの考えにたどり着きました。 あー、確かに期間を短くすると幾つか…

読了。ライブ感あふれる一冊。 # コーチに聞いていた箇所は、思ったほど衝撃的ではありませんでした。(^^;そのかわりに、いちばんショッキングだった文はこれ。 最初にプロジェクトの全体像を「考えない」ことに起因する、すべての恐怖を無視する必要がある …

http://dann.dyndns.info/diary/20040725.html#p03

※このエントリは2004/08/09に書いてます。 リリース完了なので、今日は軽め。 お客さん先でソースコードを変更したため、社内のCVSへコミットしました。 どんな変更を行ったか4人の目で再確認しながら、丁寧にコミットコメントを書く。 リリース作業中はちょ…

第1段階クリアっ! 明日は第2段階。 教訓: 「きっとハマらないなー。運が悪かったらハマるかもなー」って事項は、大抵うまく行く。 今日もうまく行った。 「たぶん時間かかるんだろうなー」って事項は確実に時間を食う。 ええ、時間が掛かりましたとも。。。 …

なんだかんだでタスク完了! おわったー。(←むしろ明日が本番だってば) 今イテレーションは、 作業してるのに残りタスクが減らない 隠れタスクがぼろぼろ出てくる やっぱり環境でハマった やっぱり見積もりが甘い で「進捗管理表」がエラい方向になりかけまし…

本体部分のソースコードを「こめんと書うんた」に投入してみました。 ソースコード : テストコード = 1 : 3.7 もはやテストが無いと生きていけないカラダになってしまっっている。。。 プログラマ改造計画の被険体、って感じです。

ここに来て環境系の落とし穴が。 くっそー、もっと早い段階で発見できなかったかなー。 環境系は、イテレーションの序盤で手を付ける方が良さそう。仮にハマっても調整しやすいから。

テストファーストって言うけれど、クラスをちゃんと作れば事前のテストはいらないでしょ? クラスをちゃんと実装できないからなのでは?? 「テストが品質」だって言うけれど、それもクラスを(いきなり)実装できるスキルが無いからなんじゃないの? だなんて思っ…