今年度から本格的に開発が始まっているプロジェクトのために、影舞を設定。
既に他のプロジェクト用にセットアップしたものがあるのだが、プロジェクトはそれぞれ生存期間が違うし、その間に影舞もRubyも新しくなるしということで共用しない方がいいであろう。
ということで Ruby 1.8.2 + 影舞 0.8.6 で新規セットアップ。
次に(バグレポート)プロジェクトをその上に作る。 毎回BTSテンプレートをベースに新規作成し、今まで作成してきた時のメモを頼りにフィールドのカスタマイズをしてきたのだがちょっと面倒くさい。
何回かプロジェクトで使った経験から、だいたい自分好みの運用・フィールド設定がみえてきたので、今回は影舞プロジェクトテンプレートを作成して、簡単に新規プロジェクトを作成できるようにすることにした。
まずテンプレート作成用に1つプロジェクトを作って、今までどおりフィールドをカスタマイズ。運用時に迷わないようにフィールドの説明文を詳しめに書いておく。
で、できあがったら影舞データディレクトリの中の project/<プロジェクト名>/reporttype.xml をコピーしてルート要素の id属性と name 属性をテンプレート用に変更。 description 要素内容も簡単に書く。
できたら resource/ja/template ディレクトリの下の normal ディレクトリを、先ほどつけた id属性の値と同じ名前のディレクトリとしてコピー。この中の reporttype.xml を自作したもので置き換え。
これで次回から新規作成時に使えるようになる。 めでたしめでたし。
「すごい会議」のコミットメントリストの話の部分を読んでいてすぐ思い浮かんだのは、影舞上にリストを作るということ。
影舞は比較的自由にフィールドをカスタマイズできるので、実際に作ってみた。
それなりに形になったかな。 後で簡単に導入できるように(不完全)影舞プロジェクトテンプレート化しておく。
昨日の続き。
一人6つ程度担当分野を考えホワイトボードに書いた後にそれぞれ番号をふり、「n番とm番は一緒」という風にマージしていく。
結局4人のチームに対して8つの担当分野が決まった。
ここからは「一番効果的な担当者」を決める作業。 まずそれぞれの担当分野に適任と思う人を手元の紙に1人づつ書いてもらう。 書き終わったら挙手で人数を数える。
参加者の中で自身を少な目に投票した人がいて、その人が最初担当に浮かびあがってこないという事があったが、未決担当を再投票しなおして確定。
皆で決めた担当に対して反対意見はなし。 逆にちょっとそれがこわかったりするけど、皆それが一番効果的という事で納得したということでいいのかな。
それから一つの疑問は「どのようにすれば学習的配慮を含む担当決めができるか」。 この手順だと一番効果的な担当者が決まるのだが、もし「多少効果が低くなるけれど、スタッフの学習を考えた担当決めにしたい」時にはどうするのがよいだろう?
コミットメントリスト作り。
皆それぞれ手元に書いてから、ホワイトボードにリストアップ。 依存関係をチェックして期日を調整したり足りないコミットメントを追加したりして、最終的に30強のコミットメントが確定。
自分も含めまだ、コミットメントのタイトルづけは不慣れ。 作業として書きがちな部分もあるが、慣れればコミットメントらしい表現ができるようになるだろう。
メジャーメントは今回明示的に書かなかった。 影舞上のコミットメントリストに登録する際に、整理して決めることにする。
チャレンジに必要なエネルギーのプレゼント手順。
自分にもチャージしておく。
2日に分けて全手順完了。
全手順やったという満足感と同時に、担当決めとコミットメントリストを獲得。
「すごい会議」全手順は、プロジェクト開始時に1日かけてばっちりやるのが一番効果的なんだろう。で、チェックポイントでは「集団解決の型」を使う。
そういえば「集団解決の型」はまだ実践してないな。 今度使ってみよう。
影舞でコミットメントリストを作成して運用している。
今までコミットメントに設定できる状態として
を用意していた。
担当は「割当済み」コミットメントを達成すると状態を「完了」に変更するのだが、そうすると割当済みリストから消え、よく見る影舞のプロジェクトトップページに表示されなくなる。 メンバにメールで通知がいくものの、全員で完了の合意が取れていないのがちょっとよくないな。なので、
のようにしてみた。 担当が達成したと判断したら「確認待ち」とし、コミットメントリストの進捗チェック時に皆で確認した上で「完了」とする流れに。 これでより、プロジェクトの状態を皆で共有できるのではないかと。
ちなみに「提案」は一度も使われていないので不要のようだ。
ソフトウェア開発の見える化としてソフトウェアかんばんの良さは実感しているのだが、分散開発ではさすがに「情報カードで」というわけにいかず実行しにくい。
今回の分散開発プロジェクトに向けていろいろ考えた結果、Google ドキュメントのスプレッドシートを使ってソフトウェアかんばんを遠隔共有してみようと思う。
TRICHORD を使ってみたいのだけれど予算の問題が。 検討したのは以下。
スプレッドシートだとカードっぽさが薄れるが、共有・同時編集という点では安心して使えるし最大行数的にも OK。 一番運用しやすそうだということでこれでいくことにした。
以下のようにスプレッドシートを作る。
列 | 内容 |
A | カード番号をつける。 |
ストーリーカードは S番号。タスクカードは S番号T番号とする。 | |
B | カード作成日を書く。 |
C | ストーリーカードの時にストーリー名と作成者名をかく。 |
D | タスクカードの時にタスク名と作者名をかく。 |
E | 期日をかく。 |
F | TODO の時に @ とかく。DOING に移行した時は @ を消す。 |
G | DOING の時に @ と開始日、担当者の名前を書く。DONE に移行した時は @ を消す。 |
H | DONE の時に @ と終了日、担当者の名前を書く。 |
I | 備考欄 |
TODO、DOING、DONE 列は1列にまとめることもできるが、ちょっとは「かんばん」っぽくなるかと思って分けることにした。
2月の Developers Summit 2015 で zakwa 氏と再会したのをきっかけに、当時一緒に仕事をしていた気が置けないソフトウェア開発者4人で同窓会をすることになった。セッティングしてくれた zakwa 氏ありがとう!
手配してくれたお店は「焼きたてパンとワインのお店」COGS DINING KAGURAZAKA。神楽坂から路地に入ったところにあるお店で、上品な味の料理で満足だった。店内もうるさくなくて話しやすかったし、たばこを吸っている人もいなかったので快適だった。
現職のまま続けている1人と、別の場所で働くことになった3人だけれどみなそれぞれソフトウェア開発現場に関わっていて、それぞれの開発スタイルなどについて情報交換したり。
大企業だからしっかりした開発をしているとか、スタートアップだからモダンな開発をしているとかでは必ずしも無いよねという話だった。例えばバージョン管理一つにしてもうまくできていない(やっていない)場合も多いとのこと。当時を振り返ってみると小規模かつ独学の状況ながら、今では普通になってきたプラクティスやツールをその時から実践/活用していたなと自画自賛した。
「書けなくなったホワイトボードマーカーはその場で床に投げ捨て」に共感を持ってもらえていたのが、振り返って当時の自分の一番の成果だな。
退職時に使っていた社内 Wiki は Naney 謹製のものだったのでその後どうなったのかなとたまに気になっていたのだけれど、ビル管理会社の人に社内サーバの電源を切られたことによりサーバごと死んで闇に葬られたらしい。R.I.P.
同窓会らしく「あのひとは今」的な話をしたり、当時フィルムカメラで撮っていた業務風景のアルバムを持ってきて盛り上がったり。あとはレーシックやドライアイ治療ひぇー的な話題が出たり。あとは展示会の時のレクサー・リサーチポロシャツ制作秘話とか。
そういえば出席はできなかった2013年2月開催の「LEXER設立20周年記念サロン・パーティ」で会社のるぐるロゴの立体置物が配られたと聞いて、あ、欲しかったなーと。
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。