Entries

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
この記事にトラックバックする(FC2ブログユーザー)
http://burnlight.blog3.fc2.com/tb.php/429-a6419621

トラックバック

コメント

コメントの投稿

コメントの投稿
管理者にだけ表示を許可する

Shibuya.trac第10回勉強会参加しました

Shibuya.trac第10回勉強会 に参加しました。

Shibuya.trac第10回勉強会

■きっかけ
redmineを使ってて2年以上になりますが、backlog pluginが動かないし、デモサイトも動作が怪しいのですが、
backlog pluginをうまく使われているらしいyusuke_kokubo さんが発表されるということで、
参加してみました。

印象的だった内容と、そこから自分が考えたことをメモしておきます。
人の名前と開催時刻は記載。タイトル記載は省略。

■Oかもとさん (xx:xx
最後のスライドに全く同意です。
MSProjectを使いこなせない人が、他のツールをつかいこなせることはないと思います。

MS Projectの不満を言っている人に
うまくいかない話をよくよく聞いてみると、
ツールが悪いと言うよりも
その前提となるプロジェクト管理の基礎知識がない例が多く感じました。

逆に、じゃあMS Project以外のツールが何がいいの?となると、それっぽいのはあまり挙がりません。
フリー、商用含めていくつも調べましたが、価格、機能、普及を考えるとMS Projectが無難です。

メインとなるTrac lightning後継については、
自分ではTracからredmineに移行しちゃったので詳しくはわかりませんでしたが、
すごいエネルギーを感じました。

■こくぼさん (20:55
今回、一番聞きたかったというか見たかった内容。
Redmine backlogs Pluginを自分でうまく動作できてないので、どんな感じなのかがとても興味ありました。

直接見たら、もう一がんばりして使えるようになろうというやる気が戻りました。

Sprint -- 対象バージョン
Story -- 親チケット
Task -- 子チケット

という対応付けだそう。

redmineのチケット親子関係付けが公式リリースに入ったのは、R1.1からです。

閉会後、ちょっとこくぼさんにお伺いしたら、
公式リリース版R1.1で、backlogs pluginは素では動かないらしい
ちょっと手を加える必要ある。
redmine バージョンとしてgithub からの最新版で動作させるのがお勧め。
backlogs pluginのサイトに
redmine R1.1で動作させるための情報を書いたけど、今は見えなくなってるらしいとのこと。

ということでしたが、自分は安定版で楽に行きたい主義。
(ruby, railsとも知らないので、詰まったとき対応に時間がかかるため)
もう少し調査してみます。


ウォーターフォールでもなくアジャイルでもない自分のスタイルをやりたいというのは
熱いですねぇ。


■ゆかわさん
(22:06
Mantis にはチケットの最大放置日数 というのがあるのですね。

放置チケットの棚卸しには良い観点。

通常の運用時にチケットの一覧を見る際には、更新日の古い順でソートして,
古い順から片付けると、埋もれるを防げそう。

■ふじはらさん (22:13
redmineはこんなに大量チケット、大人数でもいけるんですね。
これで、自分のサイトも何人きても安心です。
しかし、これだけの規模あると、
1プロジェクトづつはいいけど、管理画面が大変そうですね。
プロジェクトへのユーザ追加とか、標準画面からじゃ厳しそう。

redmine のバージョンアップで社内ユーザがついてきたということですが、
どんなチケット管理システムと競合しているのでしょうか興味あります。

■ikikkoさん 22:18
Backlog というaspのチケット管理システムのご紹介。
見た目重要。
結婚式のタスクが140。

■大澤さん 22:22
デブサミ チケット管理システム大決戦 が過去最高の入場者だったそうで。
行きたかった(泣)
チケット管理システムの比較表をつくられるそうで。

wikipedia にもチケット管理システムの比較表がありますが、
Comparison of issue-tracking systems

どんな感じになるのか楽しみです。

■川口さん (22:28
チケットの優先度付け + 終わりをはっきりさせるだけで生産性が2倍になるとのこと。

優先度というか、価値判定は難しいことの一つですね。

■まとめ
ウォーターフォールとアジャイルと管理についてなんとなく考えてみました。

よくあるウォーターフォールの図だと、こんな感じ。
waterfall-1

でも、たいていは、後工程に、前工程の一部が残っていく。
waterfall-2

スクラムは、短い周期でまわしていく。
waterfall-3

でも、現実的に全部の内容をきめずに細かいリリースというのは難しいと思われる。
最初の仕様をもとにしたモックのことはリリースソフトウェアというより
仕様決定の途中のデモと考えた方が自然。

とすると、

ウォーターフォールとスクラムを組み合わせてこんな感じ?
waterfall-4

だから何?という感じでオチはつかず。

■謝辞

企画、運営された方
会場提供されたNifty様
建物に出入りされる時に動向していただいた方
お菓子提供してくださった方
発表された方
などに感謝致します。
スポンサーサイト
この記事にトラックバックする(FC2ブログユーザー)
http://burnlight.blog3.fc2.com/tb.php/429-a6419621

トラックバック

コメント

コメントの投稿

コメントの投稿
管理者にだけ表示を許可する

Appendix

プロフィール

burnlight

  • Author:burnlight
  • 忘れないように色々メモします。

ブロとも申請フォーム

この人とブロともになる

ブログ内検索

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。