Some Days You Get the Bear

IT系エンジニアの、日々の気づきや考えたこと。

人間がやっていることを仕組みに落とす

いつも読んでる、小川さんのブログから。

チケット駆動開発のアンチパターンの事例

#こうやってほかのひとのブログ読みながら、自分でも書けるってのは、
#メモどりとしてはいいかも(書き急いじゃう感はあるけど)

以下、引用

Twitter / kobachi_dearu: 【期日・バージョンのない大量の『今すぐ』チケット】 リリース直後のバグ対策など今すぐやって欲しいのはわかるが、いつ本番反映するのかという計画がない。工数の見積もりもしていない。気分の問題でやっており、今やっている作業を止めてでもやるべきか、というマネジメントができていない。

Twitter / kobachi_dearu: 【外部連携仕様確定前に実装チケット】 のちに大量のバグチケットを生むことが約束されている。タスク分割も十分でないのでプログラマーがタスク分割して「仕様」や「実装」チケットを割り振ることになる。プログラマーにもプロジェクトマネージャーの給料を払うべきである。

Redmine に上げといたから、あとはよろしく~」みたいに BTS の中だけで仕事していると、こうなりそう。
BTS で情報共有やタスク管理「してるつもり」になっている。

事象の発生に伴って、「どう攻略するか」を考えないといけない。
チケットが「単なる指示書」になるまで詳細化されていればいいけど(いきなりはそこまでしないでしょ)、
タスク分割、優先度の差し替え、誰がやる?、いつ終わる?、...とチームで考えないといけない。
トップダウンで誰かが全部決めちゃうのか、チームで話し合って進めていくのか、考えることにはかわりない。
自主・自律のアジャイルなチームであってもそこは一緒。

私のやってる2~3人程度の小さな規模の案件なら、
アナログな「ホワイトボード+ポストイット」のタスク管理で十分だ。

これをやってて思ったのは、やっぱり基本は

 人間が普段やっていることをどう仕組みに落とすか

ってこと。

ホワイトボードでやっていると、自分たちの(何気ない)作業のひとつひとつが意識できるようになる。
すると「これを BTS でやったらどうなるだろ?」と考えてみることができる。
よく言われるように「ツールありき」ではないことがあらためてわかったと思っている。

先日、こちらのブログで「コミュニケーションの管理」という言葉を知り、
ちょっとググって PMBOK のコミュニケーション管理ってのを読んでみたところ。
チーム内のコミュニケーションのとり方までは、わざわざいちいちプロジェクトで決めなかったなぁ。

上記のは、まさにチーム内のコミュニケーションの問題。
チケットを安易な備忘録にすることなく、チームが使えるチケットにするための、ひとつ前段階の仕組みがどこかに必要だ、と思った。

広告を非表示にする