nDiki : タスクカード

タスクカード - task card

項目:

など。

スポンサード リンク

2005年10月26日 (水)

京大式カード

rimage:ISBN:4004150930

開発ストーリーカードタスクカードを利用するスタイルを試験的に導入しようと思いシモジマへいって、B6情報カードを買ってきた。

無地と京大式と2種類買ってみたが、京大式カードってそういえば何だ? 聞いた記憶はあるが。 この罫線の引き具合がポイントなのか?

知的生産の技術」を読まねばならないかな?

スポンサード リンク
[ 10月26日全て ]

2005年10月28日 (金)

ソフトウェアかんばん

naney:57031780

先週金曜日に参加した総会関連のプロジェクトについて KPT 法を用いた評価セッションを実施。

プログラマ間でのコラボレーションが一つの課題になった。 決して悪い状態ではなく比較的いい感じであるのだが、より良くしていこうというわけである。

またこのプロジェクトはリリースを前にまだ開発要素が目白押しということもあり、その辺りの見通しもより明確にして共有したい。

ということで、今回はあらたにソフトウェアかんばんを使ってみることにした。

よく紹介されている方法はタスクカードを「TODO」「DOING」「DONE」というカテゴリ分けされた壁に貼って見える化する方法である。

今回はこれをちょっとアレンジして実践してみることにした。

まずはこれでスタート。

実装しなければならないストーリーがたくさんあることを直観的に、他のスタッフにも理解してもらえる。社長も「まだこんなにやることがあるのか」とプロジェクトの状況を理解してくれたようである。

今後であるが、以下の点をまだ行っていないので順次実行していきたい。

  • イテレーションの設定
  • タスクの見積もり
  • ストーリーの見積もり
  • 全体の見積もり
  • 定期的チェックタイムの設定
  • 貼りやすいプッシュピンの入手

[ ソフトウェアプロジェクトマネジメント ]

[ 10月28日全て ]

2005年11月30日 (水)

ストーリーカードタスクカードを導入した開発の成果物を納品

naney:69018707

なんとか月内に発送できた。

今回はストーリーカードタスクカードを試験的に導入。 終盤ちょっとチェック頻度がさがってしまったという反省はあるものの、開発ペースがつかみやすくなったり、機能の実装漏れを防げたりと効果は十分あったと感じた。

その他、プログラミングについて互いに積極的に教えあうなどチームメンバそれぞれ学習できたという点でもなかなか良かったと評価したい。

チームの皆さまオツカレサマ。特に松下君オツカレサマ。

[ 11月30日全て ]

2006年4月10日 (月)

ソフトウェアかんばん「見えない化」

チームメンバが重なっている2005年度の2つのプロジェクトがほぼ終了したので、事後評価セッションを開催。

興味深いポイントについて:

ソフトウェアかんばんが見えない

今回1つのソフトウェアに対してソフトウェアかんばんを適用した。 担当開発者の2人は以前このコンビで別のソフトウェアでかんばんを使用し、コラボレーションが促進したのだが、今回はどうもイマイチであった。

先日のレイアウト変更で、タスクカード/ストーリーカードを貼る(座っている場所から見える)パーティションが無くなってしまったのが敗因と推測されている。

ぐらさん言わく「見えない化」

issue tracking

開発中に発生する

などについて誰かが指摘した後、迅速・確実に処理がなされないことが多かったという意見も多かった。

後半「コミットメント・リストチェックを電子上での各自チェックに切り換え」たことにより、皆が頭を突き合わせて真剣に意思決定する場が減ったのが大きなマイナスだったか。 その方式は2月に終了したスタッフが2拠点に分散したプロジェクトで成功した方式で、うまくいったので導入してみたのだが、このチーム向きではなかったようだ。

やはり基本は顔合わせということを実感。

またコミットメントではないけれど、細かい issue を追跡する仕組が必要かなと。 ツールに走って issue tracking system 導入して遊ぶという手もあるが、手段が目的になってしまいそうでもある。

どのようなプロセスがチームに向いているのかも含めて、ここはひとまず紙ベースでいろいろ試行してみようと思う。

できるだけシンプルにして、各自が自分の好みのツールと連動して処理していけるようにするようにしたい。

(というか、自分は自分の GTD プロセスとスムーズにやりとりできるようにしたい。)

インタフェースを変更するなら、古いのも deprecated 扱いで残して

複数人開発で途中開発者間にまたがるインタフェース仕様が何回か変更になった。 改良のために仕様変更はアリだと思うが、コード変更に愛情が足りなかったため実行できないコードが断続的に発生し、確認のための開発待ちが発生した。

通常開発中のコード内でのこのようなインタフェース変更については

  1. インタフェースを変更する人が、同時に呼出し側のコードも修正してコミットする
  2. しばらくは古いインタフェースを @deprecated で残しつつ、新しいインタフェースを提供する

のどちらかを取りかつ周知をする必要があるが、この辺がうまくできていなかった。 次回はうまくやれるはず。

ちなみに「できるだけ早く仕様を決定するようにする」というアイデアも出たが、これはまず守られない。もちろんみんなそれを望んでいるし、そのように努力しようとするんだけれども、最初の時点で完全な仕様を決定できることはほどんどない。仮にその時点で完全でも、数ヶ月後には状況が変わり仕様がふさわしくなくなってしまっていることもある。 無理に最初の仕様に固執することの方がデメリットが大きいことも多い。

止まらないプログラミング

変に一人で抱えこんで数時間あるいは1日プログラミングを止めてしまうことを無くそうという提案。

  • 30分ルール

「30分」のところは15分だったり1時間だったりするかもしれないが、とにかく必要以上に一人で悩んで立ち止まらないようにしようという話。

関係者に確認すれば数分で解決してしまうことも多い。 技術不足とかそういうこととは関係なし。 もしかしたら「そのインタフェース実はまだできてないので結果は適当です」というのを呼び出して結果が合わないと悩んだりしてたりとか。

チームのトータルのスループットを最大にするようにコミュニケーションしよう。

[ 4月10日全て ]

2007年3月1日 (木)

WiKickerソフトウェアかんばん

情報カードベースでソフトウェアかんばん(ストーリーカード + タスクカード)を作っている開発プロジェクトがあるのだが作ったっきりあまり活用されていないので、今回は試験的に WiKicker による Wiki 上でかんばんを作ることにした。

まだ荒削りだけれども、まずはとにかく以下のルールで始めてみる。

ルール

カードの作り方

基本的には 1カード毎に WikiPage を作るようにする。 ページ名はストーリーカードを表す SC と 状態 (TODO / DOING / DONE) を含む名前にする。

  • SC/TODO/<ストーリー名>
  • SC/DOING/<ストーリー名>
  • SC/DONE/<ストーリー名>

タスク名も同様に作る。

  • TC/TODO/<ストーリー名>
  • TC/DOING/<ストーリー名>
  • TC/DONE/<ストーリー名>

カードの内容は XP で扱っている内容で。 新規作成が楽なようにテンプレートページを作っておき、これをコピーして作れるようにしておく。

状態変更

TODO -> DOING -> DONE という状態変化にあわせて、WikiPage 名を変更してページを移動させる。

 例:
 TC/TODO/名前をつけて保存メニューを追加
   |
   V
 TC/DOING/名前をつけて保存メニューを追加
   |
   V
 TC/DONE/名前をつけて保存メニューを追加
一覧ページの作成

SC/TODO、SC/DOING、SC/DONE、TC/TODO、TC/DOING、TC/DONE ページを作りそれぞれに、子階層の一覧を表示させる (WiKicker の [[index:child]] を使用)。

参照

タスクカードからは「SC/<ストーリー名>」という名前で、ストーリーカードへリンクさせる。

WiKicker では「SC/<ストーリー名>」というページない場合、「SC/*/<ストーリー名>」というページを探してリンクしてくれる。この機能のおかげで、状態にあわせてページ名を変更してもリンクはそのままで追従してくれる。

担当者

担当者が割り当てられて実行中のタスクカードには [[DOING:担当者名]] という文字列を記述しておく。

「DOING:担当者名」で検索することで、各担当者が何を実行中なのかリストアップすることができる。また DOING: を「DOING:担当者名」を検索する Wiki 自身への InterWiki として定義しておくことで、この記述自体を検索結果へのリンクとすることができる。

[ 3月1日全て ]

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日全て ]

2009年12月10日 (木)

今日のさえずり - フロスティ食べたい

naney:4174421200

2009年12月09日

2009年12月10日

  • 07:42 ほぼ日手帳2010今日から2009と一緒に持ち歩く。2006のカバーを装着。
  • 09:22 階下の人引っ越ししちゃったのかな。一昨日引っ越し業者がきてたらしいし、人気もない。
  • 09:55 秋葉原 声優のたまごの上に AKIBA SPACE ができてる。 http://movapic.com/...
  • 12:15 秋葉原 声優のたまごの入っているビルに新しく入ったテナントはこれか。 http://bit.ly/6oZLKJ #Akihabara
  • 12:33 後ろの人のアカウント、ビンゴだった。
  • 12:56 モバイル Google マップSO905iCS では 2.3.2 で最新。2.3.4 はおりてこない。徒歩ルート案内使えず。 http://bit.ly/5wW9S3
  • 20:17 ちょっとヨドバシカメラ
  • 20:30 インプレスの年賀状CD-ROM買った。家族用。
  • 20:49 ん? 今普通に動いているけど、京浜東北線止まってたのか。結果的に社内説明会が長引いてよかったかも。
  • 21:25 12月分の電気ご使用量のお知らせきた。オイルヒーターの稼働率が上がっているからちょっとドキドキしたけど昨年同月を下回っていてひと安心。
  • 22:07 @TokyoBlueline ピーク月は2万円オーバーしますね。タイマーと温度調節の設定に腐心しています。
  • 22:10 昨晩設定した FeedTweet が動き始めてる。「ポスト紹介」部必須だと思っていたけれど空にできるのか。つけたくないので外す。
  • 22:17 それと FeedTweet で bit.ly 設定しておいたんだけれど URL 短縮サービスが am6.jp になっている。確認したら API key の項目で最後に余分な空白(改行?)がはいっていたみたい。次 bit.ly になるか確認。
  • 23:54 ウェンディーズどうなるんだろ。フロスティ食べたい。
  • 23:57 久しぶりにウェンディーズ行っておこうかと思ったが秋葉原昭和通りの店はもう無いんだっけ。
  • 24:39 年賀状CD-ROMイラスト9000 (2009-12-10) http://ff.im/-cItuG
  • 24:51 今回は FriendFeed の方が FeedTweet より先の巡回/投稿。タイミングの問題だけではあるが。
  • 24:58 Ameba 会員登録中。
  • 25:10 Amebaなう登録完了。まだ lonely。
  • 25:27 Amebaなう: 【1ヶ月】または【500件】までしか保存されません。保存上限を超えると自動的に古いものから削除されます。 http://bit.ly/5eflVa
  • 28:46 FeedTweet 投稿されてない。夜は苦手?
[ 12月10日全て ]

2016年6月10日 (金)

チケット ID でやりとりする

みんなで大小様々なプロジェクト(企画開発やタスク)を同時に進めている場合は、常に全てを頭で把握しておくことは困難ですしまたナンセンスです。その代わりに各プロジェクトの情報を知りたいと思った時には、あちこち探しまわることなくさっと手に入る状態にしておくべきです。

そのためには、まず前提として必要な事柄が書き出されてオープンに情報共有できている状態にある必要があります。

そしてそれらに簡単にたどりつけるようにするために各プロジェクトやタスクに ID (番号やキー)を発行し、チケット/タスクカードやドキュメント、コミットログなどに明記するのが、現実的に一番取扱いやすいです。

JIRA のようなユニークなチケット ID がチケットに発番され、かつそのチケットに permalink のあるチケット管理ツールを中央に据え、その ID を活用することでぐっと情報が共有しやすくなります。ここで ID 形式がさっと人が読んだり手書き・手入力したりできるものであることが大切です。

そういう点で言うと Trello は permalink しかないのでセンターを取れないなと思っています(Trello アーカイブ性も弱いという点もあります)。

[ 6月10日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

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

follow us in feedly

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

月別インデックス
Process Time: 0.083309s / load averages: 0.45, 0.54, 0.72
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker