redmine.tokyo 第7回勉強会ディスカッション

redmine.tokyo 第7回勉強会

2014-11-15 @tkusukawa

名前はくすかわと言います

仕事はシステム開発部門の(残念な)部門長

Redmineに日々大変お世話になっております

工数入力・集計プラグイン：WorkTime を個人的に作成/仕事で使用/OSSとして公開しています

自己紹介: @tkusukawa

2014/11/15 2 redmine.tokyo 第7回勉強会ディスカッション

Ustreamで映像配信しています

顔出しNGな方は言って下さい

録画をYouTubeにUpする予定です

NGまたは要編集は言って下さい

2014/11/15 redmine.tokyo 第7回勉強会ディスカッション 3

確認

ディスカッションの

進め方


説明

①まず、私からみなさんに質問をします

ディスカッションの進め方


Redmineの使い方でよく議論になる事柄について、です。

② 選択肢の中から選んで挙手で意思表明して下さい（全員）



どちらとも言えない選択肢ばかりですが、あえて選んで下さい。

③ なぜ「そう思う」のか

手を上げて発言して下さい



あえて主張してみて下さい。（つっこみ所、大盛りでお願いします）

④ 補足／反論して下さい



（多少脇が甘い感じがGoodです）

⑤ みなさんの日々の苦労が醸し出されることを期待



各自のドメイン・現場を前提とした意見になるのはとても自然なことです。

⑥それぞれのドメイン・現場で正解は異なる

→ それぞれのドメインで「やってみないと解らない」



⑦他の人の意見からなんらかの疑似体験/気付きがあれば幸いです



⑧ 意見が変わった → 了見が狭かった → 得るものが有った◎



① まず、私から選択的な質問をします

② 選択肢の中から挙手で答えて下さい（全員）

③ なぜ「そう思う」のか発言して下さい

④ 補足／反論して下さい

⑤ みなさんの日々の苦労が醸し出されます

⑥ やってみないと解らない事が多い今日この頃

⑦ なんらかの疑似体験／気付きがあれば幸いです

⑧ 最初と意見が変わった → 得るものが有ったということ



（つっこみ所大盛りで）

（多少脇が甘い感じがGoodです）

挙手のお願い

拍手のお願い

笑いのお願い

呟きのお願い（ハッシュタグ: #redmineT ）

発言のお願い


お願い

ディスカッションをはじめましょう


＜アンケートの回答から＞

プログラム開発を大前提としている（と理解している）ので、運用業務に特化したチームでの活用が、Redmineでそのメリットを十分に享受できるのか（乗り出しても効果があるのか）についてはまだ疑問です。

【質問：二択】

A: Redmineは運用管理ツールとして十分使える

B: Redmineは開発(プロジェクト)管理用のものだ


Redmineの用途について

アンケートの中にこの言葉が多かった


A: Redmineの導入で簡単にトレーサビリティを確保できる

B: Redmineを導入してもトレーサビリティを確保する運用は大変だ


トレーサビリティについて


A: 課題管理はRedmineがあればエクセルは不要

B: Redmineがあっても課題管理にはエクセルが必要


課題管理とエクセルについて


A: 工程管理はRedmineがあればエクセルは不要

B: Redmineがあっても工程管理にはエクセルが必要


工程管理とエクセルについて


A: 全ての業務をチケット駆動にすべきだ

B: 一部の業務はチケット駆動にはできない（一部の「ヤミ作業」はやむを得ない）


No Ticket, No Workについて


A: チケットの完了基準は予め定義すべき

B: チケットの完了基準は最初は曖昧でも良い


チケットの完了基準について


A: チケットのコメントの数が多過ぎるのは良くない

B: チケットのコメントの数は際限なく多くても良い


チケットのコメント(Note) の数について


A: 初心者が戸惑うので限定的な仕様にして欲しい

B: 汎用的なことは良いことだ


Redmineの汎用性の高さについて


A: 思いついたら【プロジェクト】を作って良い

B: 【プロジェクト】はよく考えて作るべき


プロジェクトの作成について


A: 【プロジェクト】は一定期間でクローズすべき

B: 終わらない【プロジェクト】があっても良い


プロジェクトのライフサイクルについて


A: 【チケット】は一定期間でクローズすべき

B: 終わらない【チケット】があっても良い


チケットのライフサイクルについて


A: チケットの最終責任者を【担当者】にすべき

B: チケットの今の作業者を【担当者】にすべき


チケットの担当者について


A: 知っておいて欲しい人をウォッチャーに入れる

B: 知っておきたいチケット/Wikiのみウォッチする


ウォッチャーの使い方について


A: 個別にRedmineを立てるのが小回りが効いて良い

B: 一つのRedmineを全員で使った方が良い


Redmine構築の粒度について


A: ワークフローをしっかり作り込んだ方が良い

B: ステータスやロールは少ない方が良い


ワークフロー設定について

【質問：五択】

A: 新規開発案件に対してチケット/Wikiに追記する

B: 新規開発案件に対してチケットを作成する

C: 新規開発案件に対してバージョンを作成する

D: 新規開発案件に対してプロジェクトを作成する

E: 新規開発案件に対してRedmineを立てる


新規開発案件の取扱方について

【質問：四択】

A: 開発ドキュメントはチケットに書く/添付する

B: 開発ドキュメントはWikiに書く/添付する

C: 開発ドキュメントは文書/ファイルに置く

D: 開発ドキュメントはバージョン管理に入れる


開発ドキュメントについて

【質問：四択】

A: 運用ドキュメントはチケットに書く/添付する

B: 運用ドキュメントはWikiに書く/添付する

C: 運用ドキュメントは文書/ファイルに置く

D: 運用ドキュメントはバージョン管理に入れる


運用ドキュメントについて


A: なるべく最新バージョンのRedmineに更新すべき

B: 頻繁にRedmineのバージョンを上げない方が良い


バージョンアップについて


A: Redmineの標準機能のみを使った方が良い

B: 積極的にプラグインを活用した方が良い


標準機能とプラグインについて


A: 標準のフィールドはなるべく活用した方が良い

B: 不要なフィールドはなるべく使わない


チケットフィールドについて


A: いつも書く項目はカスタムフィールドにすべき

B: なるべく説明に書く運用で済ませた方が良い


チケットへの記述事項について


A: モジュールはなるべく活用した方が良い

B: 必要最小限のモジュールのみ使った方が良い


プロジェクトで使うモジュールについて


A: Redmineとチャットがあれば社内メールは不要

B: そんなことはない


メール不要論について


A: Redmineを他システムと連携させた方が良い

B: Redmineは他システムと連携させない方が良い


他システムとのシステム連携について

【質問：三択】

A: もっと多くの機能を標準で持つべき

B: これ以上の機能はプラグインで追加するのが良い

C: 機能が多過ぎるので削った方が良い


Redmineの機能の数について


A: できればRedmineの運用指南を他社に頼みたい

B: Redmineでも何でも運用設計は自社でやるべき


Redmineのコンサルティングについて

A:

B:


質問：二択

redmine.tokyo 第7回勉強会 ディスカッション

Technology

redmine.tokyo 第7回勉強会ディスカッション