nDiki : 影舞

2003年12月19日 (金)

[ お仕事 ] 影舞 0.8.3

年明けから本格的に開発が始まるであろうプロジェクトに向けて、バグトラッキングシステムを用意。 以前すでに影舞 0.8.1 をインストールしてある のだが、Ruby を 1.8.0 に上げて再度入れなおしておく。 影舞アップデート時にメンテナンスが面倒なので WiKicker/影舞ラッパーは外しておく。

[ 12月19日全て ]

2004年1月11日 (日)

www.naney.org BTS 休止

ディスク容量が結構やばくなってきたので、ホームにインストールしていた Ruby とともに、影舞を削除・www.naney.org BTS を停止。

[ 1月11日全て ]

2004年10月8日 (金)

Ruby 1.8.1 + 影舞 0.8.4

会社の社内サーバで影舞を使っている。 別の部隊でも気にいってプロジェクトで使いたいというので、昨日インストール方法を簡単に説明しておいた。

しかしうまく動かせないようで、助けを求めてきたので軽くヘルプ。 すでに私が稼働させている Red Hat Linux 8.0 BOX (私は以前セットアップした Ruby 1.8.0 + 影舞 0.8.3 を使用中)へインストールしようとしているのだが、うまく動いていない。

public_html の下に Rubyインストールしていたり、影舞インストールマニュアルを無視していたり。 UNIX 経験が浅いスタッフなので前者はしょうがないとはいえ(もちろん修正する必要あり)、後者はなぁ。 まず、READMEインストールマニュアルは読んでくれ。 中国出身なので言葉の問題があるのも理解できないこともないが、読まずに動かないと言われても。

それからうまく動かないからといって、はなから Ruby の問題だとか影舞の問題だとかブツブツ言わないように。 フリーソフトウェアという概念自体から(いやソフトウェアライセンスというものからか?)説明しなければならないな。

ちなみにそのスタッフの帰社後、同じ構成ですんなり動作する事を確認(影舞 CGI プログラムインストールしたディレクトリが group writable になっていたため、ちょっと suEXEC でちょっとはまったが)。

せっかくなのでこれを機に自分の動かしているやつのバージョンを上げておくか。

[ 10月8日全て ]

2004年12月31日 (金)

私的10大ニュース2004 [ comp ]

cool programs

Palm OS 生活復活

PEG-TJ25を購入し、Palm OS 生活復活。 最初はおもちゃのつもりで買ったのだが、プロジェクトマネジメントなどにシフトした仕事のスケジュール管理などで大活躍。

PDA 市場の明るい話はあまり聞かないが、末長く製品が出て続けて欲しい。

http://www.naney.org/img/2004/X/X2004-03-05-0003.jpg http://www.naney.org/img/2004/X/X2004-03-14-0004.jpg http://www.naney.org/img/2004/X/X2004-04-10-0001.jpg

[ 12月31日全て ]

2005年5月26日 (木)

影舞プロジェクトテンプレートを作っておく

naney:15457364 今年度から本格的に開発が始まっているプロジェクトのために、影舞を設定。 既に他のプロジェクト用にセットアップしたものがあるのだが、プロジェクトはそれぞれ生存期間が違うし、その間に影舞Rubyも新しくなるしということで共用しない方がいいであろう。

ということで Ruby 1.8.2 + 影舞 0.8.6 で新規セットアップ。

次に(バグレポート)プロジェクトをその上に作る。 毎回BTSテンプレートをベースに新規作成し、今まで作成してきた時のメモを頼りにフィールドのカスタマイズをしてきたのだがちょっと面倒くさい。

何回かプロジェクトで使った経験から、だいたい自分好みの運用・フィールド設定がみえてきたので、今回は影舞プロジェクトテンプレートを作成して、簡単に新規プロジェクトを作成できるようにすることにした。

影舞プロジェクトテンプレートの作成

まずテンプレート作成用に1つプロジェクトを作って、今までどおりフィールドをカスタマイズ。運用時に迷わないようにフィールドの説明文を詳しめに書いておく。

で、できあがったら影舞データディレクトリの中の project/<プロジェクト名>/reporttype.xml をコピーしてルート要素の id属性と name 属性をテンプレート用に変更。 description 要素内容も簡単に書く。

できたら resource/ja/template ディレクトリの下の normal ディレクトリを、先ほどつけた id属性の値と同じ名前のディレクトリとしてコピー。この中の reporttype.xml を自作したもので置き換え。

これで次回から新規作成時に使えるようになる。 めでたしめでたし。

[ 5月26日全て ]

2005年5月30日 (月)

すごい会議コミットメント・リスト影舞

すごい会議」のコミットメント・リストの話の部分を読んでいてすぐ思い浮かんだのは、影舞上にリストを作るということ。

影舞は比較的自由にフィールドをカスタマイズできるので、実際に作ってみた。

  • 「状態」は悩んだ結果、とりあえず「割当済み, 提案, 完了」とした。「提案」は無くてもいいかもしれない。
  • ゲストでも「状態」と「担当者」以外は書き換えられるようにした。ゲストによる変更を許可しないと、空にしたくないフィールドにはデフォルト値を設定しておかなければならないが、適切なものが思い浮かばなかったので。
  • 期日でソートとかできるといいけど、まあできなくてもいいか。
  • トップページで表示される一覧表で「最初の報告者」は表示しなくてもいいので report_index.rhtml をコピーして編集。

それなりに形になったかな。 後で簡単に導入できるように(不完全)影舞プロジェクトテンプレート化しておく。

[ 5月30日全て ]

2005年7月1日 (金)

すごい会議はじめての全手順(2/2)

rimage:ISBN:4479791183

昨日の続き。

戦略的フォーカスを達成するのに、必要不可欠な担当分野はなにか? 15:00 - 16:00 (60分)

一人6つ程度担当分野を考えホワイトボードに書いた後にそれぞれ番号をふり、「n番とm番は一緒」という風にマージしていく。

結局4人のチームに対して8つの担当分野が決まった。

ここからは「一番効果的な担当者」を決める作業。 まずそれぞれの担当分野に適任と思う人を手元の紙に1人づつ書いてもらう。 書き終わったら挙手で人数を数える。

参加者の中で自身を少な目に投票した人がいて、その人が最初担当に浮かびあがってこないという事があったが、未決担当を再投票しなおして確定。

皆で決めた担当に対して反対意見はなし。 逆にちょっとそれがこわかったりするけど、皆それが一番効果的という事で納得したということでいいのかな。

それから一つの疑問は「どのようにすれば学習的配慮を含む担当決めができるか」。 この手順だと一番効果的な担当者が決まるのだが、もし「多少効果が低くなるけれど、スタッフの学習を考えた担当決めにしたい」時にはどうするのがよいだろう?

それぞれの担当者が、いつまでに何を達成すれば戦略的フォーカスが確実に達成されるのか? 16:00 - 17:30 (90分)

コミットメント・リスト作り。

皆それぞれ手元に書いてから、ホワイトボードにリストアップ。 依存関係をチェックして期日を調整したり足りないコミットメントを追加したりして、最終的に30強のコミットメントが確定。

自分も含めまだ、コミットメントのタイトルづけは不慣れ。 作業として書きがちな部分もあるが、慣れればコミットメントらしい表現ができるようになるだろう。

メジャーメントは今回明示的に書かなかった。 影舞上のコミットメント・リストに登録する際に、整理して決めることにする。

いまから1ヶ月以内に、自分の起こす一番大きな、インパクトはなにか? 17:30 - 17:45

チャレンジに必要なエネルギーのプレゼント手順。

自分にもチャージしておく。

終了 (合計約6時間、休憩含まず)

2日に分けて全手順完了。

全手順やったという満足感と同時に、担当決めとコミットメント・リストを獲得。

すごい会議」全手順は、プロジェクト開始時に1日かけてばっちりやるのが一番効果的なんだろう。で、チェックポイントでは「集団解決の型」を使う。

そういえば「集団解決の型」はまだ実践してないな。 今度使ってみよう。

[ 7月1日全て ]

2005年10月27日 (木)

影舞でのコミットメント・リストの状態を改良

影舞コミットメント・リストを作成して運用している。

今までコミットメントに設定できる状態として

  • 提案
  • 割当済み
  • 完了

を用意していた。

担当は「割当済み」コミットメントを達成すると状態を「完了」に変更するのだが、そうすると割当済みリストから消え、よく見る影舞のプロジェクトトップページに表示されなくなる。 メンバにメールで通知がいくものの、全員で完了の合意が取れていないのがちょっとよくないな。なので、

  • 提案
  • 割当済み
  • 確認待ち
  • 完了

のようにしてみた。 担当が達成したと判断したら「確認待ち」とし、コミットメント・リストの進捗チェック時に皆で確認した上で「完了」とする流れに。 これでより、プロジェクトの状態を皆で共有できるのではないかと。

ちなみに「提案」は一度も使われていないので不要のようだ。

[ 10月27日全て ]

2008年3月12日 (水)

今日のさえずり - 「おてんちゃん」ワクワクIT@あきば2008 でもらった。

2008年03月11日

naney:2325256007

  • 11:43 Heap 構造書いた。最近コレクションクラスで済ませるから、基本データ構造自分でなかなか書かないよな。
  • 11:59 iモード.net って Web メールなのか。
  • 18:45 明日のイベントの事前登録の自動応答メールがみあたらない。プリントアウトして持参せよとの指示があったのだが。

2008年03月12日

  • 12:53 これから秋葉原ダイビル「ワクワクIT@あきば2008」に行ってくる。
  • 13:39 ワクワクIT@あきば2008、ひととおり知っている人に挨拶してきた。あとはオフィス待機にする。[mb]
  • 14:38 よかった、影舞メンテナンス続いていたのか。今月 0.8.7、0.8.8 がリリースされてる。
  • 14:46 鼻かみすぎてヒリヒリしてきた。メンターム塗っておく。
  • 14:47 [photo] 「おてんちゃん」ワクワクIT@あきば2008 でもらった。 http://tinyurl.com/39xoul
  • 23:48 目が痒いのでついにステロイド(フルメトロン)に手を出した。
  • 23:57 IronPython、Debian パッケージにも既になっていたか。

naney:2327691259 naney:2327717397

[ 3月12日全て ]

2008年3月30日 (日)

Google ドキュメントソフトウェアかんばん

ソフトウェア開発見える化としてソフトウェアかんばんの良さは実感しているのだが、分散開発ではさすがに「情報カードで」というわけにいかず実行しにくい。

今回の分散開発プロジェクトに向けていろいろ考えた結果、Google ドキュメントのスプレッドシートを使ってソフトウェアかんばんを遠隔共有してみようと思う。

他の検討候補

TRICHORD を使ってみたいのだけれど予算の問題が。 検討したのは以下。

  • TRICHORD - 本命。使ってみたいが予算が。
  • Firefox + Internote (light-board.com ライク) - カード感は十分。しかし共有に難。
  • 影舞用に新しくソフトウェアかんばんテンプレートを作る - 影舞を使い慣れているという点では○。ただストリーカードとタスクカードをどう扱うかが課題。
  • Wiki - 以前やって失敗した。
  • XPlanner - インストールと学習が手間。それと開発止まっている?
  • その他 Agile Project Management Tool - カードメタファで良さそうなのはあるが、予算が。
  • Google ドキュメント プレゼンテーション - 矩形をカードにしようとしたが文字は別オブジェクトで書かなければならず×。文字の背景を設定するというのも試したが見栄え・操作性が良くなかった。

スプレッドシートだとカードっぽさが薄れるが、共有・同時編集という点では安心して使えるし最大行数的にも OK。 一番運用しやすそうだということでこれでいくことにした。

スプレッドシートの作成

以下のようにスプレッドシートを作る。

  • 1シート目はインフォメーションシートにする。ソフトウェア概説・かんばんルール・通信事項などを書くのに使う。
  • 2シート名以降をかんばんにする。複数ソフトウェアならシートを分けてもよいかもしれない。
  • かんばんシートE列の背景を「条件をに応じて変更」で本日より前だと赤くなるように設定する。
  • かんばんシートF・G・H列の背景を「条件に応じて変更」で @ と書くと背景がそれぞれ赤・黄・青くなるようにする。

カードの書き方

内容
Aカード番号をつける。
ストーリーカードは S番号。タスクカードは S番号T番号とする。
Bカード作成日を書く。
Cストーリーカードの時にストーリー名と作成者名をかく。
Dタスクカードの時にタスク名と作者名をかく。
E期日をかく。
FTODO の時に @ とかく。DOING に移行した時は @ を消す。
GDOING の時に @ と開始日、担当者の名前を書く。DONE に移行した時は @ を消す。
HDONE の時に @ と終了日、担当者の名前を書く。
I備考欄

TODO、DOING、DONE 列は1列にまとめることもできるが、ちょっとは「かんばん」っぽくなるかと思って分けることにした。

運用

  • カード番号は重複しないように。
  • カードの状態にあわせて @ を書き換えていく。
  • DOING から TODO に移る時には、開始日と担当者名を消さないで残しておく。
  • 列単位でソートしないこと。
  • タスクの粒度はできるだけ揃える(例えば半日~1日にする)。

課題

  • カードが増えた時に使いにくくならないか? 終わったカードを別シートに分けるルールなどを考える。
  • タイムボックス等にあわせて並べ替える時の手間。
  • カード番号が手動。
  • 集計について考慮していない。
[ 3月30日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.083374s / load averages: 0.71, 0.66, 0.56
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker