« Redmineチケットの関連リンク | トップページ | チケット駆動開発のスケールアップ »

2010/02/09

XP祭り関西2010~チケット駆動開発を用いたソフトウェア品質改善事例

XP祭り関西2010のTiDDセッションで小枝さんが講演された資料が公開されたのでメモ。

公開資料だけでは雰囲気が伝わりにくいけれど、小枝さんは物腰が柔らかく、現状のSW開発の問題点を的確に分析されていて、とても興味深かった。

・組込SW開発では、SW開発部隊以外にHW部隊や品質保証部隊など社内の別の部署と連携する必要がある。
 そのために、コミュニケーションがスムーズにいかない場合がある。
 
・「システムテストの手戻りが多い」という問題点を最優先に対処した。
・一部の協力会社の開発者は、製品知識が少ないので間違った理解で実装してしまうため、単体テストで防げない。
・多発する変更要求やバグを正確に開発者へ伝えるために、TiDDを採用した。
・BTSとしてMantisで運用した。
 Mantisは、ステータス別に色分けされるので、ぱっと見ただけで状況が分かる。
 新規(紫)や担当(黄色)が多い場合、チケットが未着手か遅延しているので、早急に対処が必要。
 解決(緑)が多い場合、テストやレビューで止まっているので、早急にリスケが必要。

・チケットにはバグだけでなく、仕様変更なども登録する。
 「仕様変更に対処しなかった」という意思決定の結果も残した方が後で役立つ。
・TiDDには、イテレーションのPDCAサイクルとチケットのPDCAサイクルがある。
 チケットのPDCAサイクルを早く回せば進捗がはかどる。

・チケットの粒度はプロジェクトに応じて変わる。
・細かいチケットになるほどチケットは溢れる。
 だから、ランクを付けて、ランクの順にチケットをこなす。
 例えば、100枚のチケットがある場合、10個ずつランク分けして、10個ずつ作業してリリースしていく。
 そうすれば、作業しやすくなるし、自然にアジャイル開発になる。

・チケットをイテレーションに割り当てて、約1ヶ月のサイクルで小刻みにリリースした。
 すると自然にアジャイル開発になった。
 開発にリズムが出て、開発者のモチベーションも向上した。

・TiDDで解決できない問題点もまだある。
  システム設計が不十分
  テスト技術力が低い
  要求管理が不十分

組込製品開発のように、多数の部署と連携しながら開発する場合、TiDDによって情報共有がスムーズになる利点がある。
しかし、TiDDはいわゆる下流工程では威力を発揮するが、上流工程のコントロールなどではその効果が得られない時もある。
それらは今後の課題と言えるだろう。

|

« Redmineチケットの関連リンク | トップページ | チケット駆動開発のスケールアップ »

Agile」カテゴリの記事

コミュニティ」カテゴリの記事

ソフトウェア工学」カテゴリの記事

チケット駆動開発」カテゴリの記事

プロジェクトマネジメント」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/47525859

この記事へのトラックバック一覧です: XP祭り関西2010~チケット駆動開発を用いたソフトウェア品質改善事例:

« Redmineチケットの関連リンク | トップページ | チケット駆動開発のスケールアップ »