Redmine 4.0.0 released !! - プログラマの思索
ずっと待ち続けていたRedmineのVer4.0がついに先日リリースされた。 ラフなメモ書き。 【参考】 Redmine 4.0.0, 3.4.7 and 3.3.9 released - Redmine Redmine3.4.0 Released !: プログラマの思索 Redmineの新機能開発チケットの記事のリンク: プログラマの思索 【1】今回のリリースで最も重要な点は、Rails5に対応したことだろう。 最新のRubyやRailsに追随することで、セキュリティパッチや最新ライブラリへの対応などがやりやすくなるはずだ。 【2】リリースされた機能改善のうち、個人的に重要と思うチケットは下記がある。 一つは、メールを非同期的に送信する機能改善だ。 Feature #26791: Send individual notification mails per mail recipient
「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
Redmineの要員管理のプラグインLychee Resource Managementの感想 - プログラマの思索
アジャイルウェアがRedmineの要員管理のプラグインLychee Resource Managementを公開されていたのでメモ。 ラフなメモ書き。 【参考】 Lychee Resource Management：アジャイルウェア (引用開始) 「今誰が空いているかわからない」「予実をマッチさせたい」「スタッフの負担がバラバラ」…そんなマネージャの悩みにLychee Resource Management。 稼働時間、稼働率、生産性をグラフと表でリアルタイムに把握できる。 ユーザーごとの稼働時間、稼働率、生産性を任意の期間、任意のプロジェクトで把握することができます。 また、日単位、月単位やグループでまとめることも可能。様々な見方でリソースを把握し、マネジメントを支援します。 (引用終了) 【1】MSProjectを使っているマネージャなら、ガントチャートだけでなく、EVMや稼働率、クリ
「価値ある製品を生み出すためのアジャイル実践ポイント」の資料が公開されました - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Redmineは実績工数管理システムになりうるか - プログラマの思索
「Redmineは実績工数管理システムとして使えるか？」という問題に対して、考えたことをラフなメモ書き。 結論は、運用ルールさえきちんと決めれば、実績工数管理システムとして使えると思う。 【参考】 WorkTime - Work Time - r-labs estimate_timelogの0.1.0を公開しました。 - アルパカDiary toritori0318/redmine_estimate_timelog ・ GitHub Redmine で予定/実績レポートを表示するプラグイン(estimate_timelog v0.5.0)を Redmine 2.x に対応させた - suVeneのアレ suvene/redmine_estimate_timelog ・ GitHub 【1】現状と問題 SIのプロジェクトリーダーは月末月初になると、工数確定・工数照合という重要な作業で繁忙にな
モダンPMの３大技法～CPM、WBS、EVMS - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
テストはソースコードの冗長化 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
CSV形式のデータをSQLを使って解析する方法 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
ユースケース駆動ではなくロバストネス駆動開発？ - プログラマの思索
「ロバストネス駆動開発」という言葉を見つけたので思わずメモ。 【参考1】 天使やカイザーと呼ばれて ≫ ロバストネス駆動開発？ 天使やカイザーと呼ばれて ≫ ロバストネス図113枚!! OOAD講座：第5回「ロバストネス分析を設計・実装につなげる」 | artisan edge thinking ロバストネス図の使い道: プログラマの思索 ユースケース→ロバストネス分析→クラス設計という順に開発していくスタイル。 この時、ロバストネス分析が最も重要であるという認識から、「ロバストネス駆動開発」とネーミングしたらしい。 確かに、ロバストネス図がきちんと書ければ、バウンダリ・コントローラ・エンティティを多少変形するだけで実装に近いクラス図を設計できる。 ロバストネス図を1日中書いたら113枚になった、という記事は確かにすごい。 単なるテーブル保守画面ではなく、背後に複雑なロジックがあったり、バ
Redmineのビューをカスタマイズするプラグインのメモ - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
R言語の解説記事のリンク - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
マイクロサービスとドメイン駆動設計の設計思想のメモ - プログラマの思索
@yusuke_arclamp さん、@sugimoto_keiさんが、マイクロサービスとドメイン駆動設計の設計思想に語っているつぶやきが参考になったのでメモ。 以下は、疲れた頭で思いついたことを書き殴り。 間違っていたら後で直す。 【元ネタ】 マイクロサービスとドメイン駆動設計の設計思想のTwiiter拾い - Togetterまとめ Martin Fowler氏がマイクロサービスの特徴について語る マイクロサービス移行の代償 マイクロサービスとSOA マイクロサービスアーキテクチャとは何か - arclamp SOAとマイクロサービスを複合設計に当てはめると見えるもの: ソフトウェアさかば マイクロサービスはコア資産 - Martin FowlerのMonolithFirstを読んで -: ソフトウェアさかば さかばさんはTwitterを使っています: ".@akipii こんなのもあ
Redmineは事務処理の申請承認ワークフローに使えるか？ - プログラマの思索
Redmineを事務処理の申請承認ワークフローに使えるか、考えたことをラフなメモ書き。 【参考】 RedmineをBPMツールとして使うアイデア: プログラマの思索 Redmineにワークフローエンジンとして必要な機能～ワークフローに組織マスタの情報を持たせる: プログラマの思索 【1】事務処理の申請承認ワークフローは簡単な仕組みなのだから、Redmineのワークフロー管理機能とチケット管理機能でほとんど実現できるのではないか、と思ってしまいがちだ。 実際、つい10年くらい前までは、LotusNotesで簡易なワークフロー管理は実現できていた。 例えば、見積書の作成・承認、旅費申請、事務用品の購買申請、他部署への作業依頼などがあるだろう。 しかし、業務を詳細にヒヤリングして分析してみると、意外に複雑だったりする。 特に、古い大企業や古いメーカーほど、縦に長い組織階層とサイロ型組織、昔ながら
在庫は悪なのか善なのか - プログラマの思索
@hatsanhatさんたちと飲んでいて、在庫の話が出た。 @hatsanhatさんたちの話をログとして書いて、考えたことをラフなメモ書き。 間違っていたら後で直す。 【参考】 第39回IT勉強宴会の感想～花束を作る花屋の業務モデルをT字形ERと三要素分析法で比較する: プログラマの思索 渡辺式データモデリングの復習: プログラマの思索 【1】在庫はエンティティなのか？ モデル初心者は在庫をエンティティとして作りたがる。 すると、複雑なモデルになりがち。 在庫は商品の状態、またはサマリ。 在庫は、入出庫テーブルからタイムバケットごとに算出される数量。 在庫をエンティティにすると、在庫からのトレーサビリティが難しい。 在庫が分かるだけでは意味がなく、その在庫はどこにどんな商品があるのか、という情報までさかのぼらなければならない。 そうすれば、在庫を削減して業務を効率化することもできる。 【2
第8回東京Redmine勉強会の感想 #redmineT - プログラマの思索
第8回東京Redmine勉強会の感想をメモ。 興味のあることだけ書く。 【参考】 第8回勉強会 - redmine.tokyo 第8回東京Redmine勉強会 #redmineT - Togetterまとめ 第8回redmine.tokyo勉強会に行って来た #redmineT - やっさんメモ redmine.tokyo 第8回勉強会に参加しました(#redmineT) - torutkの日記 【1】今回の勉強会は、テーマが玄人向けの話が多かったので、Redmineを既に運用されている人にとってはツボにはまったと思う。 逆に、Redmine初心者の観点では、レベルが高すぎて理解しにくかったかもしれない。 でも、現時点のRedmineでのノウハウはある程度出し尽くせたと思う。 個人的に今回の勉強会で感じたことは二つある。 【2】一つは、Redmineのチューニングを駆使すれば、200万件の
チケット駆動開発はチケット管理ツールから離れて定義できるか - プログラマの思索
チケット駆動開発はチケット管理ツールから離れて定義できるか、という問題についてラフなメモ書き。 思索のメモであり、特に主張はない。 【1】チケット駆動開発は、チケットを起点にして、ソフトウェア開発の作業の発生からリリースまでを記録して管理していく仕組み。 このアイデアはとてもシンプルだし、誰でも思いつきそうなアイデアだ。 このアイデアを何とか抽象的な概念で再定義できないか、とずっと考えていた。 チケット駆動開発の特徴や利点を話そうとすると、必ずチケット管理ツールの使い方が出てくる。 そのツールの機能や使い方から切り離して、チケット駆動開発を説明しようとすると、何かしっくりこない感覚がある。 チケット駆動開発のプラクティスをパターン化しようとしたけれど、PMBOKやXPの部分集合みたいな感じになって、自分が描いたイメージよりも矮小化された気がしていた。 だから、チケット管理ツールをベースに説
システム設計よりも業務プロセスの設計をやっている - プログラマの思索
業務プロセス設計についてラフなメモ書き。 主張は特に無く、アイデアをメモ。 【1】業務システムを設計・開発していると最近、システムを設計しているという感覚がない。 むしろ、業務を設計しているという感覚に近い。 すると、既存の業務フローを簡素化してシステム化するという仕事になりやすい。 特にERP導入の場合はそうだ。 既存の手作業のフローがどこまでERPの機能に吸収されて効率化されるか、がERP導入の一つの目的だから。 しかし、既存の業務フローを変更するのがとても難しい経験を何度もしている。 現場にとって、長年の業務フローが変わると、担当者の作業が増えたり減ったりするために、組織に影響をおよぼすのはご法度なのだ。 組織構造に関わるBPRの場合、ユーザ企業の責任者に承認を得て、業務フローを変更しなければならない。 既存の業務フローが変わることをきちんと合意しておかないと、せっかく決めた要件はユ
Redmineの「チケット計測のススメ」の記事がすばらしい - プログラマの思索
チケット計測のアーキテクチャとしては、Redmineのチケット一覧画面で必要なクエリをあらかじめ作成しておく。 次に、RedmineのREST APIを使って、クエリを呼び出してCSVへ出力し、そのCSVをパース＆解析して、各種メトリクスを出力する仕組み。 仕組みは簡単だが、すごく良いアイデアだ。 従来のソフトウェア工学では、常時監視した方が良いメトリクスは既に知られている。 アジャイル開発ならば、下記が既に知られている。 詳細は「リーン開発の現場 カンバンによる大規模プロジェクトの運営」を参考にすると良い。 ・累積フロー図：ステータス毎のチケットの枚数を時系列に並べたグラフ ・Velocity：チームの開発規模を表す ・リードタイム：平均のリリース間隔を表す。チケットの平均完了日数。 ・サイクルタイム：ステータスが変更される平均時間を表す。 累積フロー図は、チケットの増減を通じて、チーム
チケット駆動開発の理想と現実 - プログラマの思索
知人と話しながら、チケット駆動開発の理想と現実について気づいたことをメモ。 あくまでもメモであり、主張はない。 【1】Redmineを導入したならば、チケット駆動開発で運用するのが普通だと僕は思っていた。 しかし、実際の数多くの現場はそうではないですよ、と。 丁度、日本のソフトウェア開発の現場では、アジャイル開発ではなくWF型開発が主流であるのと同じように、と。 【1-1】チケット駆動開発はXPに影響を受けすぎているのでは？、と。 世間のアジャイル開発のイメージは、XPよりもScrumの方が有名だ。 Scrumのプロセスフレームワークの中で、タスクカードがチケットとして使われる場合が多いでしょう。 全ての作業をチケットにして作業をはじめる「チケット駆動」は特殊でしょう。 WF型開発の現場では、そうではない。 チケットの入力結果は、ガントチャートで確認する方が普通ですよ、と。 【1-2】チケ
Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ - プログラマの思索
Redmineの運用の現場を見ていると、チケットをストックとして見る場合とフローとして見る場合で観点が異なるように思えた。 ラフなメモ書き。 【1】Redmineを運用し始めた時に、チケットよりもRedmineプロジェクトの分割に重きを置いたり、チケットをWBSと一体視して、1チケット＝1担当者で運用する現場を見かける時がある。 たいてい、上手く回っていない。 本来のチケット駆動開発では、チケットを経由して一つの作業を複数人が分担してやり取りする。 その流れがチケットで表現されるから、今誰がボールを握っているのか分かるのに、チケットをWBSで固定化してしまうと、手戻り作業が発生するたびに、現状を把握しにくくなる。 このアンチパターンを「WBS駆動」「担当者固定」と僕は呼んでいる。 【2】@akahane92さんも言っていたが、Redmineでは、チケットのコメントが長くなるような運用の方が
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
