第2回 オフショア開発における私の失敗例(1)
2003年にJUDE（チェンジビジョンの設計支援ツール）開発部に配属されてから，すでに5年が過ぎました。その間，自らJUDEの設計・実装・テストに従事すると同時に，福井のJUDE開発チーム（以下，福井チームと呼びます）と上海のJUDE開発チーム（以下，上海チーム）の間の橋渡し役も勤めてきました。IT業界では，このような役割をブリッジSEと呼びますが，JUDE開発部ではコミュニケータ（communicator）と呼んでいます。 JUDEコミュニケータとしては，(1)福井チームが決定したストーリー（JUDE開発チームが採用しているXP方法論の手法で，シンプルなテキストや画像によって記述される機能要求）やタスク，開発方針などを上海チームに伝達する，(2)上海チームの質問と意見を福井チームに伝える，(3)それらの質問や意見に関する福井チームの回答を上海チームに説明する，(4)上海チームの進捗（しん
第3回 オフショア開発における私の失敗例(2)
前回に引き続き，今回も私の失敗例と改善策を紹介します。オフショア開発に携わる同業者の方々の参考になれば幸いです。 失敗例3－進捗が見えなかったことによる失敗 福井のJUDE開発部には，福井チームと上海チームのタスク看板（図1）があります。ToDo，Doing，Doneの三つの進捗状態に分けて，タスクを付箋に書いて貼り付けるのです。 月曜日の朝に行われるイテレーション・ミーティングで，前の週のタスク進捗を確認し，今週のタスクを決定します。そして，毎日の朝会（図2）の前にタスクの進捗状況に応じて看板を更新し，朝会で自分の進捗を報告します。私は，看板にリストされている自分のタスクを更新すると同時に，Wiki（上海チームの進捗を管理している）の情報をもとに看板にある上海チームのタスクも更新します。 ◆失敗シーン 月曜日に，ある複雑なタスクを上海チームに開発してもらうことになりました。このタスクによ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
