第14回RxTStudy勉強会「Redmineの未来を考える - 機能・運用・コミュニティ」の感想 #RxTStudy - プログラマの思索
昨日の第14回RxTStudy勉強会は、たぶん過去最高の参加者で盛り上がりました。 以下、自分の感想をラフなメモ書き。 以下、長文です。 【元ネタ】 RxTStudy #14 「Redmineの未来を考える - 機能・運用・コミュニティ」 - RxTStudy～Redmineとタスクマネジメントに関する勉強会 | Doorkeeper 2016/03/5 RxTStudy #14 「Redmineの未来を考える - 機能・運用・コミュニティ」 - RxTStudy～Redmineとタスクマネジメントに関する勉強会 - Togetterまとめ 【1】@g_maedaさんの講演は、RedmineのVer3.0～3.2の新機能紹介とRedmineを作っている人々の話。 2015年の1年間で、メジャーバージョンアップ3回、取り込まれたチケット数は約190枚。 わずか数名のコミッタがオープンソースの
Redmineの理想と現実～RxTStudy #12 「ITS活用最前線～現場からの実践報告」の感想 - プログラマの思索
第12回RxTStudy「ITS活用最前線～現場からの実践報告」で司会＆モデラーをしてきました。 大手SIのRedmine導入事例が聞けたこと、本音ベースのパネルディスカッションができて、参加者からも満足度が高かったように感じました。 以下ラフな感想。 【参考】 RxTStudy #12 「ITS活用最前線 ?現場からの実践報告?」 - RxTStudy～Redmineとタスクマネジメントに関する勉強会 | Doorkeeper RxTStudy #12 「ITS活用最前線 ～現場からの実践報告?」 - Togetterまとめ 題12回RxTstudy「ITS活用最前線 〜現場からの実践報告〜」 - Togetterまとめ 【1】前田さん 【1-1】Redmine本家の話が興味深い。 前田さんは、最近コントリビュータになられたので、Redmine本家にある3千～4千ものチケットを整理したり
Redmineが日本人好みのツールであるという仮説 - プログラマの思索
第10回東京Redmine勉強会のグループディスカッションでも話題になったのが、Redmineの運用が大規模化していく上での課題だ。 @Will_meaningさんとのやり取りがとても参考になったのでメモ。 以下は私的感想。 【参考】 Redmineの運用が大規模化していく上での課題～@Will_meaningさんとのやり取り - Togetterまとめ Redmineを運用している規模について - Google グループ 第10回東京Redmine勉強会～「メトリクスの見える化とその周辺」 #redmineT - Togetterまとめ 【1】@Will_meaningさんが持つ問題意識は「なぜ海外ではJIRAが多く普及していて、日本ではRedmineが多く浸透しているのか」。 彼の意見を読むと、「SVN中心の開発プロセスはRedmine、Git中心の開発プロセスはJiraやGitHub
Redmineは事務処理の申請承認ワークフローに使えるか？ - プログラマの思索
Redmineを事務処理の申請承認ワークフローに使えるか、考えたことをラフなメモ書き。 【参考】 RedmineをBPMツールとして使うアイデア: プログラマの思索 Redmineにワークフローエンジンとして必要な機能～ワークフローに組織マスタの情報を持たせる: プログラマの思索 【1】事務処理の申請承認ワークフローは簡単な仕組みなのだから、Redmineのワークフロー管理機能とチケット管理機能でほとんど実現できるのではないか、と思ってしまいがちだ。 実際、つい10年くらい前までは、LotusNotesで簡易なワークフロー管理は実現できていた。 例えば、見積書の作成・承認、旅費申請、事務用品の購買申請、他部署への作業依頼などがあるだろう。 しかし、業務を詳細にヒヤリングして分析してみると、意外に複雑だったりする。 特に、古い大企業や古いメーカーほど、縦に長い組織階層とサイロ型組織、昔ながら
チケット駆動の罠～複雑さはチケットの粒度に関連している - プログラマの思索
チケット駆動の罠の記事をメモ。 【参考】 JIRAに死を | TechCrunch Japan (引用開始) ここで強調したいのは、悪いのは必ずしもJIRA自身ではない、ということだ。 ここまで書いてきたことはすべて、ソフトウェアのアーキテクチャと開発を“チケット”の集合に還元する、という考え方に由来している。 JIRAの最大の罪は、それが、もっとも成功し広く普及しているチケットシステムであること、それだけだ。 ソフトウェアプロジェクトをチケットの集合で表す、という考え方そのものが、真の敵だ。 (引用終了) tadashi-aikawaさんのツイート: "本文にも書いてあるけど JIRAをディスっているのではなく JIRAの使い方をディスっているだけ。 Confluence使えばおけ JIRAに死を | TechCrunch Japan https://t.co/pNEqwe12Ex vi
プログラマの思索: Redmineを使って気づいたこと
日々の新規開発をRedmineのチケットで進捗管理して気づいた点があったのでまとめてみる。 【1】ロードマップを見ると、進捗率が逆に下がる場合がある 下記のロードマップになるようにチケットを登録したと仮定しよう。 ◆ロードマップ1：5月1日現在 進捗：0％ #1 機能Aの開発（新規） #2 機能Bの開発（新規） #3 テスト（結合テスト）（新規） すると、普通は、0％→33％→66％→100％ と進捗率が上がって終わるはず。 ◆ロードマップ1：5月5日現在 進捗：100％ #1 機能Aの開発（終了） #2 機能Bの開発（終了） #3 テスト（結合テスト）（終了） しかし、テストでバグが上がったり仕様変更が入った時、バグ報告をチケットに登録すると、下記のようになる。 ◆ロードマップ1：5月6日現在 進捗：42％ ← 終了3件/全7件だから。 #1 機能Aの開発(終了) #2 機能Bの開発(終
Redmineを使って気づいたことpart4～チケットの状態管理 - プログラマの思索
Redmineを運用して気づいたことを書いてみる。 【元ネタ】 ソフトウェア開発の必須アイテム，BTSを使ってみよう：第6回 運用の開始｜gihyo.jp … 技術評論社 ソフトウェア開発の必須アイテム，BTSを使ってみよう：第9回 BTSの運用データを解析して役立てる｜gihyo.jp … 技術評論社 [redMine] 最近の redMine 05/02-05/06 - Don'tStopMusic (2007-05-06) 【1】チケットのステータスは、トラッカー(チケットの種類)に応じて異なる Redmineによるチケット管理で重要な概念はトラッカー。 Redmineのトラッカーは、チケットの種類を意味する。 デフォルトでは、バグ(defect)・機能(feature)・サポート(support)の3種類がある。 バグ修正、機能追加、その他のタスク(例えば、環境構築など)で使い分け
バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠 - プログラマの思索
TiDD初心者が陥りやすいアンチパターンを実際に見つけたのでメモ。 【1】チケット駆動開発の概念に慣れておらず、Redmineでタスク管理をまず始めた人に多い特徴がある。 それは、バージョンが設定されておらず、ロードマップが空っぽないし非表示な状態。 話を聞くと、Redmineのバージョンの意味や使い方が理解できないらしい。 だから、彼は、Redmineのチケット一覧画面でタスク管理を実施している。 彼のチケット一覧画面を見ると、スクロールできないくらい、たくさんのチケットが無造作に一覧表示されている。 どうやら、必要なタスクはチケットに登録しているが、彼のチケット管理を見ていると、チケットの納期が意識されていない。 そのチケットはいつリリースするのか？の観点が漏れているみたい。 何故なら、チケットがたくさんありすぎて、どのチケットが必要なのか、チケット一覧画面では分かりにくいからだ。 だ
Redmineはプロジェクトを横断して使うべきか否かという議論の感想 - プログラマの思索
Redmineはプロジェクトを横断して使うべきか否かという議論をTogetterにまとめた。 過去の僕の経験を踏まえながら、Redmineの運用スコープはどこまでなのか、を振り返ってみる。 ラフなメモ書き。 【元ネタ】 Redmineはプロジェクトを横断して使うべきか否か - Togetterまとめ 【1】当初は、メンバー3人で、短期間の受託開発案件をこなしていた。 その時、Redmineを導入して、Redmineの機能を一つずつ試しながら、アジャイル開発の実現方法を習得していった。 少人数のメンバーで1個のチームだけだから、イテレーションごとにRedmineの運用ルールを軌道修正して、アジャイル開発のプラクティスを1個ずつ試していけた。 一番の発見は「イテレーション・リリースバージョン・マイルストーン一致の原則」と「プロジェクトとブランチ一致の原則」だった。 「イテレーション・リリースバ
Excelの内容をredmineのwikiへ変換するアドオン - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Jenkinsをジョブ管理ツールとして使うアイデア - プログラマの思索
@akiko_pusuさんのJenkinsの事例を読んで、Jenkinsをジョブ管理ツールとして使うアイデアについて考えたことをラフなメモ書き。 間違っていたらあとで直す。 【元ネタ】 Jenkinsをバッチ監視ツールとして運用する事例: プログラマの思索 2枚の絵でわかるJP1ジョブ管理の仕組み - あしのあしあと Monitoring external jobs - 日本語 - Jenkins Wiki Jenkinsをメトリクス収集ツールとして使うアイデア: プログラマの思索 【1】基幹系業務システムの命は、Cobolで書かれたバッチ処理だ。 Webシステムやクライアントアプリから収集された業務データ、売上データは、夜間にバッチ処理で一括集計されて、日次や月次の商品有高帳、損益計算書、貸借対照表などを出力する。 これらの数値をにらめっこしながら、経営者は日々の経営方針を微修正しながら
Webプログラミングは何故オブジェクト指向でない？～WicketはWebプログラミングにオブジェクト指向を取り戻す - プログラマの思索
Webプログラミングは何故オブジェクト指向でない？～WicketはWebプログラミングにオブジェクト指向を取り戻す JavaでWebアプリを10年書いて思ったこと。 Webプログラミングは全然オブジェクト指向でない。 Sevlet＋JSP主体のプログラミングスタイルは、リクエストとレスポンスへPrimitiveな値をどうやって渡すか、という手続き型の発想でしか書いていない。 従来のWebプログラミングスタイルの問題点について書いてみる。 以下ラフなメモ書き。 【参考リンク】 Wicketって？ ウェブ開発をもう一歩前に Wicketで始めるオブジェクト指向ウェブ開発：第1回 Hello, Wicket｜gihyo.jp … 技術評論社 【コラム】イマドキのIDE事情 (39) Wicket、Grails、Click - IDEでみる軽量Javaフレームワーク | エンタープライズ | マイ
プログラマの思索: RedmineがExcelよりも素晴らしい点
Redmineの使い方は下記を見よ。 http://www.redmine.org/projects/show/redmine 【1】以下、Redmineを使った感想を書いてみる。 1-0.ガントチャートがリアルタイムに表示される。 こいつに一番感動した。 プロジェクトリーダーは、ガントチャート保守に、彼の作業時間の殆どを費やす。 その理由は、プロジェクトのリスクがガントチャートでしか把握できないからだろう。 考えてみれば、作業の開始日と終了日、作業状態さえ入力すれば、リアルタイムにガントチャートは計算できるはず。 殆どのITプロジェクトのガントチャートは、手作業でかなりの時間を浪費して作っているか、MSProjectのように保守しても理解しにくいか、どちらかだ。 ソフトウェア開発のプロジェクト管理で最もIT化されていない部分と言える。 1-1.SVNリポジトリとチケットが相互リンクできる
【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」 - プログラマの思索
関西Ruby会議01＠関西-KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」を公開します。 CC Attribution ライセンスとします。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) チケット駆動開発は、まちゅさんが最初に提唱された。 しかし、チケット駆動開発の概念はまだ曖昧で、一部でしか注目されていない。 僕は、Redmineというプロジェクト管理機能を持つBTSがプロジェクト管理をIT化してくれて、プロジェクト運営が大きく変わったことを経験した。 その体験をチケット駆動開発(Ticket Driven Development)という概念へ昇華できないか、考えた内容が上記の資料です。 コメントがあれば嬉しいです。 【参考】 Rubyist
プログラマの思索: ツールが開発プロセスを改善する
Redmineでチケット駆動開発(TiDD)を運用して気付いたことは、開発プロセスが大きく改善されただけでなく、従来の開発プロセスの弱点が浮き彫りになったこと。 下記の記事を読んで考えたことを書いてみる。 【元ネタ】 ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー 元請SIerがTracのような環境を提供できない３つの理由 - なからなLife 元請け企業が用意すべきもの - T/O 【1】強力な構成管理ツールが無い時代はライブラリアンが独裁者 構成管理の基本は、任意のバージョンのシステムを再現できること。 今時、Subversionのようなバージョン管理ツールの無いSW開発プロジェクトはありえないだろう。 CVSやVSSが無かった頃は、構成管理ツールなど存在せず、構成管理を人手でやるしかなかった。 今でも、Excelなどの設計書はバージョン管理で制
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
