- チケットに登録する作業の粒度が大きすぎてちっともチケットが消化されない
- 逆に登録する作業の粒度が小さすぎてチケットばかりがたまっていく
- そもそも作業者（特にプログラマ）がチケットを登録してくれない
この3つではないでしょうか。
1について・・・
最大でも1回のスプリントの期間内で消化できる作業量を目安にすればいいのではないかと思います。
消化できないのがそもそも作業としての粒度が大きいということになります。
そういう場合は登録しているチケットを親にして、作業を細分化し、細分化した作業は子として登録します。ひとつひとつ消化していくイメージですね。
2について・・・
やたらチケットがたまっていくのは、プロジェクトを管理するものの心理として、
「プロジェクトの全てを記録に残したい」
という暗黒面に陥ってしまった結果と言えるかもしれません。
チケット駆動開発のスローガンとして、有名なもののひとつとして「No ticket, No work.」があります。
「チケットなしで作業をするな」ということですが、何でもかんでも登録しちゃっていいの？という疑問があります。
チケットはプロジェクトとしてのToDoリストであり、
個人のToDoリストではない。
と私は思います。
そもそもプロジェクトを管理するためのツールなのに個人のToDoを登録してしまうと、プロジェクト全体の進捗が見えなくなります。
とはいえ個人のToDoリストの管理環境をどうすればよいのかが見えませんでした。（課題１）
3について・・・
これはIT業界にいると多くの人が経験として分かっている事柄だと思います。
職人気質のプログラマさんであればあるほど、
「ドキュメントを作るより作った方が速い！」
「現物はソースなんだ！！！」
となりがちです。
おっしゃることは分かるのですが、
みんながあなたみたいなスーパープログラマではないのです。
世の中にはね、ほら、ソースの読めないSEとかいるじゃないっすか。
自己紹介も交えてみました。ソースの読めないSEです。生きててすいません。
上記は冗談半分、本気半分なのですが、システムを紐解くのに、わざわざ全ソースを読まないといけないんですか？という話が大きいです。
小さいスマホアプリぐらいならそれもいいのかもしれませんが、クリティカルな業務システムにおいて、トラブルが起こった時やリプレイスのためにソース解読とか時間がかかるばっかりで意味のない作業なんです。
そんなもんより、ソースの索引となる設計書や仕様書があったら話が速いのです。
設計書・仕様書からトラブルの目星を付け、ソースを解析するのが、正しいアプローチなのです。
そのためには意味のあるドキュメント作りが大切なのですが、納品のための意味のないドキュメントを作らされるのが、プログラマさんがドキュメント作りを嫌がる要因の一つではないかと思います。全メソッドの仕様書とか本当に必要なのかよ。
話が若干逸れてしましましたが、プログラマさんたちはちゃんと登録してくれるのかが心配です。（課題２）
閑話休題、
課題１と２を抱え、先日オープンソースカンファレンス2014.Enterprise@Osaka というイベントへ行って参りました。
何かヒントがあるかもしれないし、人脈づくりという意識高い系（）な期待をこめ。
で、まぁ、結論から言うと、この会場でいい出会いがあったのです。
出展企業リストを見ると、 ファーエンドテクノロジー株式会社 という企業があり、ここがRedmineを使って何やら事業を展開されている模様なので凸ってみました。
対応してくださった物腰が柔らかく、かつ腰の低い方に、私の疑問をぶつけてみました。
Q： 何でもかんでも登録するとチケットがたまるばかりになってしまいそうで心配。
A： ありがちな罠。進捗管理に使う分とはプロジェクトを分けろ。（課題１の解消）
Q： プログラマさんたちが使ってくれなさそう。
A： 使わないプログラマは多い。そういう場合はリーダーが登録・編集汁。使わん奴は使わん。（課題２の解消）
あっという間に解決です。
つまり方針としては、
- お客さんが見える用のプロジェクトと内部で使用するプロジェクトを分ける。
- 個人のToDoは内部用を使いましょう。
- チケット編集をしない人は無理にやらせなくてもいいので、PLが対応しましょう。
ですね。実際の運用に入ったら、少しずつ形として整えていけばいいのかなと。
まずは先行して内部用プロジェクトを導入し、使用のための勘所を探ってもらう方向性としました。
ちなみにその物腰が柔らかく、かつ腰の低い方はファーエンドテクノロジー株式会社の社長さんでした。
「引きこもりたいので全てオンラインで対応できるようにしています」
「引きこもりたいのですか」
「今日は頑張って大阪まで来ました」（会社は松江にある）
「それは頑張りましたね。勇気ある行動です」
「Redmineを使用している1%でもうちのシステムを使ってくれればいいと思っています。使用する母数が大きくなると使ってくれる人も多くなるので。だからRedmineの布教活動をしています」
「布教活動？」
「redmine.jpっていうサイトがあるじゃないですか」
「ありますね。参考にしています」
「あれ僕が作ったんですよ」
「え！！！それはすごいですね、日本の公式サイトですよね！」
「いえ、公式じゃないんです」
「え？」
「ほら、ここ、見てください、非公式って書いてるでしょ」
今まで unofficial という文字に気づいてなかった
「小さすぎませんか・・・」
「書いてるのでいいのです」
「公式にしてもらった方がいろいろ便利なこともあるんじゃないですか？」
「そうなると大人の事情が入って以下略」
「なるほど、激しく納得です」
というわけで社長さん、お時間をいただきありがとうございました。
このプロジェクトが成功したら、全プロジェクトで活用ということになるかもしれません。
そうなったらご連絡します。
0 件のコメント:
コメントを投稿