XP
私たちのチームはXPで開発を行っていますが、新メンバーに読んでもらうためのドキュメントがあります。もちろん包括的なドキュメントではないし、求められる量にはおそらく届いていないのでしょうが。とにかくドキュメントが無い、ということはありません。 …
昨日からプロジェクトに本格的に新メンバーが参加した状態でイテレーションを開始しました。昨日は2コマ、今日は3コマペアプロで回しましたが、やはりペアプロは知識の伝達には効果覿面ですね。新しく参加したメンバーにも分かりやすいと好評でした。
デリバリーナンバー(ハネムーンナンバー)は1では無いけれども、XFDを設計したりメンテできるのは先週惜しまれつつチームを去ったXFD職人ただ一人ということが判明しました。XFDナンバー(?)は、1ですね。
プロダクトオーナーの希望で、今週は実は全体進捗の把握のために全体の作業量の見積りを行っていました。全体進捗の「大まかな」把握は必要という考えです。
今日でプロジェクトを離れてしまう人がひとり。穂は実るほど頭を垂れるという言葉をまさに体現した人だったと思います。大変お世話になりました。 でも、またいろいろなところで会えると思っています。この業界狭いですし。 ありがとうございました。またお…
XFD(eXtreme Feedback Device)、始動! とうとうCruiseControlと某デバイスが連動して動くようになりました。 もう一つの秘密兵器も始動したけど、今はまだ秘密(まだ不定な部分があるため)。
「なぜ」このイテレーションはうまくいかなかったのでしょうか。明日はその「なぜ」を５階層くらい掘り下げてみようと思います。プチ問題構造分析です。
リリースは終了したものの、今回はなかなか手こずりました。並行開発している他チームとの間での情報交換にまだ改善の余地ありです。
プログラミング系のタスクと異なり、インフラ系のタスクはどこでどのくらい苦戦するのかは事前にはほとんど分かりません。特に比較的マイナーなソフトウェア群を組み合わせる場合にはこの傾向が顕著だと感じます。ですから下手にはまってしまうとイテレーシ…
今日またイテレーション(第5イテレーション)が終了したので、明日またリリースのために客先へ向かいます。このイテレーションは最後までインフラに苦しめられました。結局リリースを行うところまで持って行くことが出来たのですが、今日は終電に間に合いませ…
はまりっぱなしだったインフラ系の地雷タスク群にも、ようやく光が見えてきました。しかしまだ大物が残っているので気が抜けません。今日もヘトヘトです。
最近体調が落ちてきています。特に胃腸関係。体の発するメッセージにもう少し敏感にならなければならないと感じています。他のメンバーに迷惑かけないようにしないと... はてなダイアリーの更新も滞りがちになってしまいました。
今日予定されていたリリースは無事終了。いや、結果だけ見ると無事終了だけれども、やはり相手先の勝手の違うインフラにヒヤヒヤさせられました。早いところこの慣れないAPサーバを乗りこなせるようにならないとまずいな...でもこれで明日の羽生さんのセミナ…
このイテレーションは地雷が埋まりまくりでした。でも来週頭にはリリースできそうです。ふ〜。このイテレーションが一番しんどかった...
NDO::Weblog(http://naoya.dyndns.org/~naoya/mt/archives/001321.html)より 本筋とはあまり関係ないところに反応しますが... Shibuya.pm での近藤さんの講演資料 にも少し紹介されていますが、ユーザからの要望を吸い上げてそれをダイレクトに反映させるフ…
地雷原で戦う戦士が二人と、後ろで虚ろな目でボーっとしている酔っぱらいが一人という構図でした...すみませんでした。本当にすみませんでした m(_ _)m
ヘトヘトです。実は明日も出勤だったりします。XPでも休日出勤は(たまに)あります。次のリリース近いですから...
このイテレーションがうまくいった原因を分析すると、 プロジェクトを始めてもうすぐ2ヶ月になるためにチームがプロセスに慣れてきた ストーリーポイント見積りの係数が安定してきた 1週間のイテレーションの威力 助っ人を呼ぶことによって地雷系タスクのリ…
イテレーションの長さを1週間に短縮した結果、今日がもうイテレーションの終了日でした。過去のイテレーションは甲斐性の無いバーンダウンチャートを晒していた私たちのチームですが、このイテレーションはきれいにバーンダウンしました。計画より若干早く終…
フローつながりで... 以前どなたかから頂いた質問に、「ペアプロしているときにフロー状態に入ることはありますか」というものがあります。私に関しては、答えはノーです。デマルコがPeoplewareの中で言及しているようなフロー状態に入ることはありません。 …
「やまざきのはてなダイアリ(id:yamaza:20040822#p1)」より わたしは仕事場では音楽は聴きません。というか、ペアプロ中は音楽の聴きようがないんです。なので一人でプログラミングをしていて、かつ周囲がうるさいときにヘッドホンで音楽を聴きます。たとえ…
CVSのコミットログを書くときには注意しましょう(^^;
お客様がいるときに受け入れテストを作ってしまうのが一番です。普段であれば仕様に疑問点があっても質問事項一覧にまとめてメールで送るなどの手段しかありませんでした。フィードバックループが長くなるのでどうしても仕様を誤解するリスクが増えてしまい…
そして今日がそのオンサイトカスタマーの日です。燃えます。がんがん質問してがんがん受け入れテストを設計/実装します。
実は前回のイテレーションの回顧にて、オンサイト度が低いことがそのままプロジェクトのリスクになっているという分析が出ていました。このため今週の月曜日の顧客ミーティングの際に、週二回のオンサイトの日の片方を午後に変更していただけないかと提案し…
ということで今日早速他チームから一人ヘルプに来てくれて、地雷の一つを(ほとんど)除去してくれました。言ってみるもんだ。これでこのイテレーションのリスクはかなり下がりました。感謝しきりです。
自分のチームのメンバーであれば、「XXさんとペアを組めば1コマで終わる」のように、人に依存したタスク見積りを行うことはできます。問題は、「YYチームのZZさんがヘルプに来ていただければ1日で終わるだろう」というような他チームの人に依存する見積りを…
スパイクは見積りの規模感をつかむために行うので、タスク分割前に時間があまっている場合には試しに短時間のスパイクを行ってみることにしました。今回のイテレーションもインフラ周りの変更が含まれるため、見積りの不確実性が高いといえます。このためイ…
先週の回顧で、1イテレーションの長さが2週間というのは長すぎるのではないかという結論が出ました。このためお客様に対してイテレーションの長さを現在の半分の1週間に変更することを提案し、承諾していただきました。ストーリーのトラッキングやお客様の意…
最初に実績値の報告として、2イテレーション分の実績値をお客様に報告します。実績値は第2イテレーションの実績値と第1、第2イテレーションを通じての平均速度を報告しました。
