[#Agile] アジャイル開発の課題と対策 その3 - チケットコミュニケーション - #TiDD
全てのことを全員が熟知する事は、規模が大きくなると難しくなります。10人、100人、1000人、あるいはやや多い人数で、組織の壁があると思います。専門性の度合いによっては、より小規模なところに組織規模の壁があります。
組織を分けざるを得ない場合、アナログ媒体でもうまく開発を進める事ができます。しかし、専門性が高くなればなるほど、チケットシステムが有効に活用できます。
この記事ではアナログ媒体のスケール方法とその限界をしめします。そして、チケットシステムでのコミュニケーションと運用のポイントを説明します。
アナログ媒体でのスケール方法
アジャイル開発では多能工が良いとされていますが、専門性が高い場合は、多能工を維持する事が難しくなります。「その2」で書いたようにチームをある程度担当ごとに分けざるを得ない場合、そのコミュニケーションの方法によって、プロジェクトの成否が分かれます。
タスクボードやカンバンなど、アナログの媒体を使ってもスケールは可能です。田口さんの事例のように複数チームのボードを近くに並べれば、他チームの情報が入手できるようにできます。また、ボードや朝会を階層的にして、スクラム・オブ・スクラムのように全体を構成する事もできます。ストーリーカードやタスクカードの情報量が少なければ、 カードの色やシールなどで補う事が可能です。
アナログ媒体の限界とチケットシステムの利点
しかし、アナログ媒体での情報交換には限界もあります。
- 外部との会議に参加する人の能力でチームの情報量が制約される
- 専門性が高くても担当者同士で情報交換されると、情報が隠蔽される
- 過去の情報の検索が困難で、経緯がわかりにくい
このような懸念がある場合、以下のような特徴を持つチケットシステムを中心としたコミュニケーションを検討すべきだと思います。
- 電子化された情報なので、いつでも誰でも見る事ができる
- 専門的な議論が隠蔽されないように管理と公開が可能
- 様々な情報を関連づける事が可能で、検索も容易
運用のポイント
(1) 情報インデックスの一元化
全てをチケットにするのではなく、チケットシステムから情報を辿れるようにします。チケットに限定せずに多様なコミュニケーションを必要に応じて活用しましょう。メールはチケットに内容をコピーしておき、電話は要点をチケットにまとめておきます。
(2) 形式知と暗黙知のバランス
「[#TiDD] SECIモデルから朝会という「場」を考える - 平鍋さん@SEA関西 -」に書いたように形式知だけでなく、暗黙知も活用します。アナログコミュニケーションは情報量が多いですが、スケールが困難です。逆に形式知は規模の拡大には強いですが、情報量は限定的です。チケット(形式知)を活かして情報交換を効率化しつつ、微妙な情報を失わないように、打ち合わせや電話などの様々な方法を活用します。
(3) 紙おむつ的防護
紙おむつというのは、中身は守って湿気(情報)は外へ出します。特定の担当者をインタフェースにする事は、自己組織化に向けたチームの防護壁としては効果的ですが、情報のボトルネックを生む可能性があります。チケットなら承認の必要なものは厳密なワークフローで管理できますし、担当者間の詳細な情報交換も他のメンバーや外部から見える状態で情報交換できます。
まとめ
ソフトウェア開発は、特定の方法に限定されるものではありません。それぞれの方法には向き不向きがあり、開発対象やチームの経験なども考慮して、様々な工夫が必要です。
アジャイル開発やDOA、もちろんチケット駆動開発も同じです。「いける!」という感触と迷惑をかけない自信があるならばそれで進めれば良いでしょう。しかし、少しでも不安を感じるならば、何らかの方法で補わなう必要があります。
ここまで書いてきた事は、特定の前提でのみ成り立つ事です。現実はここに書いたほど単純ではなく、さらに複雑です。プロセスをプログラミングするときアジャイル開発と同じです。常に全体のゴールを意識しつつ、緻密に考え、必要な時は素早くやり方を変更する必要があるでしょう。
« [#Agile] アジャイル開発の課題と対策 その2 | トップページ | [#Agile] 組織的改善から現場改善へ #JaSST_Kansai »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
「チケット駆動開発」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- [#TiDD] ポケモンGOにチケット駆動開発のポイントを学ぶ(2018.05.01)
- [#TiDD] プロジェクトを成功させるチケット管理(2017.07.02)
« [#Agile] アジャイル開発の課題と対策 その2 | トップページ | [#Agile] 組織的改善から現場改善へ #JaSST_Kansai »
コメント