皆様はじめまして。角森と申します。
この話題で三木さんが紹介された相手です…
このMLは5年間ひたすらROMっていたのですが、自分のことが話題にされたの
でびっくりして出てきてしまいました。
＞三木さん
その節は貴重なお話をありがとうございました。
ペアプロの上司を煙に巻く話は大変参考になりました。
今度実践させていただきます。
ちなみにタスクかんばんの件は断念したわけではなく、内容をカードに書か
ずにタスク番号だけを書いて「内容はExcelで見てね」としたのです。
ぱっと見で中身が分からないため効果半減ではありましたが、全体のタスク
状況が分かりやすいのと作業が片付く実感が沸くのでメンバーにはなかなか
好評でした。
もうかれこれ4年ほど前の話です。
今ならTracかTRICHORDを使っていたでしょう…
数年間、XPを実践しようとしては挫折してきたので
最近はXPのプラクティスにこだわらずに
できることをちまちまやるようになってしまいました。
朝会とかKPTとかTrac導入とかデュアルディスプレイとか
（最後の方、アジャイル関係ない…）
気が付けば、XPに出会ったころの熱い思いを忘れてしまっていたのかも…
今回は強力なサポーターもおられるので、少しがんばって実践してみようか
と思います。とりわけペアプロは是非とも取り組みます。
成果が出たらここで報告させていただきます！
# ここまで言えば、やらないわけにはいかないだろう…
On Thu, 10 Apr 2008 22:13:44 +0900
t-fukatsu@....jp wrote:
> 深津です。
>
> > > # マイルストーンにストーリーチケットとタスクチケットを紐づけしておけ
> > > # ば進捗率も一目瞭然だし
> > あ、ダメですよ！マネージャーに楽させちゃあ。
> > 次の仕事が降ってきますよっ。（違）
>
> いえいえ、マネージャー役の私が楽をするための措置ですw
>
> Trac のチケットをタスクカード代わりに使い始めたら、開発陣からも「紙って
> 必要なん？」という声が上がるようになりまして、試しに電子文書だけにしたら
> お互いに手間が減ったという次第です。
>
> ちなみにチケットによるタスク管理は、客先からも「これこそ見える化だ!」と
> 好評をいただいています。
>
> # 進捗報告が面倒になったので、客先担当者にもアクセス権限を与えただけw
> # こちらはソースコードも含めて包み隠さず記載するんで、そちらで勝手に解釈
> # してください、と。
>
>
> > > 最初は無理矢理押し通したせいもあって白い目で見られましたが、一ヶ月も
> > > しないうちに何も言われなくなりました。
> > 「慣れ」もあるでしょうけど、やっぱり“よい実績ができてきたから”なんじ
> > ゃないでしょうか？ ;)
> > # もし、ずっと続けることができているなら、ほぼ後者の理由かと。
>
> XP もどきを始めてから3年ほど経ちますが、バグの発生件数や品質は他の開発者
> と比べても大きく差があると思います。
> もっとも様々な意味で初めてづくしのプロジェクトですんで、比較するのは難し
> いんですが。
>
> # 個人開発が基本のウチの会社としては初めてのチーム制、初めてのプロジェク
> # ト管理、初めての長期プロジェクト、などなど
>
>
> > # 長期計画と短期計画を“ごっちゃ”にするからおかしくなるんじゃないかと
> > # 思っていたり。。。
>
> 私が客先担当者にやった刷り込みですが。
>
> 中・長期計画(半年〜1年)はざっくり工数しか出せないから、参考程度で考えて
> くれ。
> その代わり短期計画(1週〜1月)はきっちり出す(＝ストーリーカード、タスクカ
> ード)し、ずれるようなら理由と共にすぐ報告する(＝チケット)。
>
> 一番最初にこれを徹底的にやったおかげか、少なくともこちらの計画に文句が付
> くことはありませんし、納期の引き延ばし交渉もやりやすいです。
>
> もっとも、客先に常駐しているマネージャーの腕に依るところも大きいですが。
>
> # 私は開発リーダーであって、客先との交渉や根回しはマネージャーの役目。
> # 従って私が真っ先に丸め込まなければならないのはマネージャーで、そういう
> # 意味ではそのマネージャーが顧客役に相当する。
>
>
> > ○全体計画との調整が難しくなる→できるところへ別のタスクを振る
> > →責任範囲がグレーになる→外部調整がややこしくなる
> > ・情報共有されている場では、かえって不平不満がでる（心の中の話です
> > ね・・・）
> > ・契約内容によって反応がまちまち（↑上にもかかるところですが）
>
> うーん、チームが小さいせいもあるかもしれませんが、ウチではあまり問題にな
> ってませんね。
>
> 全体計画との調整は先述の刷り込みが効いているのか、できんもんはできんと突
> っぱねてますし、そもそも無茶な要求自体がほとんどありません。
> 3ヶ月分として降りてきた要求仕様をストーリーに分割してみたら1週ぐらいしか
> あふれなかったりとか。
> # 先週末に降りてきた要求仕様案はぐだぐだだったんで差し戻したけど。
>
> また、ウチのチームではタスク分割する際にかなり詳細な設計検討までやること
> にしています。
> で、この詳細検討は開発者(私含めて3人だけどw)の全員参加が原則ですので、誰
> がどのタスクを受け持ってもこなせるというわけです。
>
> 他にも定時上がりを義務づけたり、そのための工夫をするなど、いろいろやって
> ます。
> 公平感はかなり高いのではないかと。
>
>
> -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> Takanari FUKATSU / MINERVA Co., Ltd.
> TEL : 053-431-1600
> FAX : 053-431-1601
> E-Mail: t-fukatsu@....jp
> -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
--
角森 健二 Kenji.Tsunomori@....jp