いつも読んでる、小川さんのブログから。
＃こうやってほかのひとのブログ読みながら、自分でも書けるってのは、
＃メモどりとしてはいいかも（書き急いじゃう感はあるけど）
以下、引用
Twitter / kobachi_dearu: 【期日・バージョンのない大量の『今すぐ』チケット】 リリース直後のバグ対策など今すぐやって欲しいのはわかるが、いつ本番反映するのかという計画がない。工数の見積もりもしていない。気分の問題でやっており、今やっている作業を止めてでもやるべきか、というマネジメントができていない。
Twitter / kobachi_dearu: 【外部連携仕様確定前に実装チケット】 のちに大量のバグチケットを生むことが約束されている。タスク分割も十分でないのでプログラマーがタスク分割して「仕様」や「実装」チケットを割り振ることになる。プログラマーにもプロジェクトマネージャーの給料を払うべきである。
「Redmine に上げといたから、あとはよろしく～」みたいに BTS の中だけで仕事していると、こうなりそう。
BTS で情報共有やタスク管理「してるつもり」になっている。
事象の発生に伴って、「どう攻略するか」を考えないといけない。
チケットが「単なる指示書」になるまで詳細化されていればいいけど（いきなりはそこまでしないでしょ）、
タスク分割、優先度の差し替え、誰がやる？、いつ終わる？、...とチームで考えないといけない。
トップダウンで誰かが全部決めちゃうのか、チームで話し合って進めていくのか、考えることにはかわりない。
自主・自律のアジャイルなチームであってもそこは一緒。
私のやってる２～３人程度の小さな規模の案件なら、
アナログな「ホワイトボード＋ポストイット」のタスク管理で十分だ。
これをやってて思ったのは、やっぱり基本は
人間が普段やっていることをどう仕組みに落とすか
ってこと。
ホワイトボードでやっていると、自分たちの（何気ない）作業のひとつひとつが意識できるようになる。
すると「これを BTS でやったらどうなるだろ？」と考えてみることができる。
よく言われるように「ツールありき」ではないことがあらためてわかったと思っている。
先日、こちらのブログで「コミュニケーションの管理」という言葉を知り、
ちょっとググって PMBOK のコミュニケーション管理ってのを読んでみたところ。
チーム内のコミュニケーションのとり方までは、わざわざいちいちプロジェクトで決めなかったなぁ。
上記のは、まさにチーム内のコミュニケーションの問題。
チケットを安易な備忘録にすることなく、チームが使えるチケットにするための、ひとつ前段階の仕組みがどこかに必要だ、と思った。
