「社内スタートアップによる組織の成長に伴い発生する痛みとその解決策について」の資料が素晴らしい - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
業務ロジックをデータモデリングはどこまで表現できるか？ - プログラマの思索
「業務ロジックをデータモデリングはどこまで表現できるか？」について考えたことをラフなメモ書き。 業務システムでは、データが命。 データには個人情報が含まれるために管理が重要だったり、売上データやPVデータから、どの層の顧客から売上やアクセスが多いのか、を計測することもできる。 すると、それらデータを格納するRDBが必要になり、そのテーブル設計が重要になってくる。 顧客の業務プロセスをモデリングする場合、最近ならOOAが主流。 でも、DOAの方が現代は重要性を増していると考えている。 例えば、Railsのような優れたWebフレームワークがあれば、ER図さえきちんと作れば、DBマイグレーションとプログラム雛形を自動生成することによって、テーブルのCRUDのような画面はすぐに作れてしまうからだ。 日本におけるデータモデリングの歴史は意外に古い。 TH法、T字型ER、渡辺さんのXEAD Model
Jenkinsでプロジェクトの状況をウォッチするRedmineMetricsPlugin - プログラマの思索
Jenkinsでプロジェクトの状況をウォッチするRedmineMetricsPluginが公開されていたのでメモ。 【元ネタ】 Jenkinsでプロジェクトの状況をウォッチする - mitoma_ryoの日記 mitoma/redmine-metrics-plugin RedmineMetricsPluginはJenkinsのプラグインで、Redmineのチケット情報を元にバージョン単位にステータスごとのチケット推移を表示してくれるらしい。 このプラグインを有効活用するには、バージョンをフィーチャないしビジネス要求単位に作る方がグラフが意味あるものになるだろう。 似たようなメトリクスとしてパーキングロットチャートがある。 パーキングロットチャートはバージョンをビジネス要求に対応付けて、バージョン単位にざっくり集計したメトリクスを出してくれる。 それに対して、RedmineMetricsPl
ドメイン駆動設計の感想～OOAは過ぎ去りDOAはもう一度舞台に上がるのか - プログラマの思索
【1】増田さんによるドメイン駆動設計の話は、「エリック・エヴァンスのドメイン駆動設計」の本の目次に従って説明してくれたので、とても分かりやすかった。 OOAに関しては「実践UML」「アナリシスパターン」「ストリームラインオブジェクトモデリング―パターンとビジネスルールによるUML」などを2000年代前半に勉強会で読みこなしていたから、ドメイン駆動設計では、オブジェクト指向設計をどのように生かしているのか、が理解できたからかもしれない。 増田さんの職歴を聞いた所、OracleのデベロッパーからJavaなどのオブジェクト指向設計へ転向したとのことなので、DOAの良さもOOAの良さもよく理解されているのだろう。 また、ドメイン駆動設計だけでなく、ICONIXやSpringによる実装も組み合わせたオブジェクト指向設計なので、要件定義から外部設計、実装に至るまでの経験が豊富なことは感じられた。 【2
Redmineチケットの階層化の実装方法 - プログラマの思索
Redmineチケットのテーブルissuesテーブルにlft, rgtというカラムがVer1.0からあって、何に使うのか分かっていなかったが、下記の記事を読んでようやく理解した。 ラフなメモ書き。 【元ネタ】 【Redmine】issuesテーブルのlft・rgtって？ | Roppi.net SQLアタマアカデミー：第5回 SQLで木構造を扱う～入れ子集合モデル （1）入れ子集合モデルとは何か ｜gihyo.jp … 技術評論社 SQLアタマアカデミー：第5回 SQLで木構造を扱う～入れ子集合モデル （2）入れ子集合モデルにおける検索 ｜gihyo.jp … 技術評論社 SQLアタマアカデミー：第5回 SQLで木構造を扱う～入れ子集合モデル （3）入れ子集合モデルにおける更新 ｜gihyo.jp … 技術評論社 SQLアタマアカデミー：第6回 SQLで木構造を扱う～入れ子区間モデル （1
分散バージョン管理の可能性 - プログラマの思索
InfoQに分散バージョン管理の可能性の記事があったのでメモ。 ラフなメモ書き。 【元ネタ】 InfoQ: エンタープライズ分野での分散バージョン管理システム (引用開始) DVCSは速度を重視して設計されている。新しい実装方式、新しい技術、苦労した獲得した知識の結集であり、前世代のSCMよりも高速に動作する。ローカルにリポジトリを持てるから速いというだけでなく、従来のSCMと同様の条件でも速い。また、ブランチ作成も得意でマージ機能も優れている。90年代後半から2000年代前半ではブランチ作成とマージは"悪"だった。その当時の主流のバージョン管理システムのブランチ作成機能とマージ機能が貧弱だったからだ。処理が遅く、エラーが頻発していた。その結果、若い開発者はブランチ/マージ嫌いとして育ってしまった。DVCSは高速に動作するブランチ作成機能と本当に使えるマージトラッキング機能を実装した。30
Jenkinsで静的コード解析を常時自動化する - プログラマの思索
Jenkinsで静的コード解析を常時自動化する手法が公開されていたのでメモ。 これは使い道があると思う。 【元ネタ】 Twitter / akipii: テスト自動化ができなくても静的コード解析を回帰テストのように使うのは効果的という指摘。ガラクタのレガシー資産プロジェクトで有効かもしれない。Jenkinsを使って継続的に静的コード解析をさせる - suzukijの日記 http://goo.gl/rpTq7 Jenkinsを使って継続的に静的コード解析をさせる - suzukijの日記 Twitter / akipii: Antのbuild.xmlをSonarが読み込んでソースの各種メトリクスを出力し、更にJenkinsと連携してCronのように使う手法。SonarがMavenだけでなくAntも使えると便利。Ant,Jenkins,Sonarの導入手順 http://goo.gl/wXJ
PullRequestは分散バージョン管理の利点を生かしたパッチ取り込み - プログラマの思索
PullRequestは分散バージョン管理の利点を生かしたコードレビューのパッチ取り込みなのだと下記の記事を読んでようやく分かった。 考えたことをラフなメモ書き。 【元ネタ】 「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とご飯と甘いもの @ sotarok Twitter / @obionekenobey: RT @akipii とても良い記事。Pull Requestの機能をRedmineで実現するのは可能なはず。「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とご飯と甘いもの @ sotarok 現在の開発では、trunk(マスター)に対して各開発者がブランチを作ったり、2次開発や大きめの機能の開発、別の顧客向けにカスタマイズする開発などでブランチを作るのはとても普通だ。 すると、マージ作業が発生し、そのマ
Mercurialの資料 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
コミットフックの強化方法 - プログラマの思索
コミットフックを強化する方法が公開されているのでリンクしておく。 「No Ticket, No Commit」を強化するための方法なのでチケット駆動開発ではとても重要な設定になる。 【元ネタ1】 hg commitと同時にRedmineのリポジトリ情報を更新する - いろいろな何か Mercurial のフックを利用して Redmine のチケット操作を自動化する (フェンリル | デベロッパーズブログ) 小技(0.9): コミットと同時にリポジトリの情報を取得する | Redmine.JP Blog Mercurialでコミットする時に、SVNコミットの時と同様にRedmineのWebサービス機能を使えば、コミットフックしたらコミットログに書かれたチケットNoに自動リンクさせることができる。 小規模なチームならこの方法が一番お手軽だろう。 【元ネタ2】 TurtleMineプラグインを導
チケット駆動開発のリズムとXPのリズムは似ている - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
エクストリーム・プログラミング入門を読み直す - プログラマの思索
今頃になって、XPエクストリーム・プログラミング入門(白本)を読み直してみた。 考えたことをラフなメモ書き。 【元ネタ】 Hot Heart, Cool Mind.: エクストリームプログラミング(XP) 邦訳(XP エクストリームプログラミング入門)へのコメント パターン、Wiki、XPは良書: プログラマの思索 【1】XPエクストリーム・プログラミング入門は第2版になって、原理・原則・プラクティスが覚えきれないほど大幅に増加している。 だから、以前の僕は第1版にあるプラクティスの方が分かりやすくて好きだった。 しかし、今になって見直すと、現在までのアジャイル開発の流れを予測しているかのような概念が出てくることに驚かされる。 応用プラクティスにある各プラクティスを考えてみる。 「インクリメンタル配置」は小規模リリースと同じ。インクリメンタルな開発、つまりイテレーション単位の機能改善による
@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を解読してみる #RxtStudy #47redmine - プログラマの思索
@daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を解読してみる #RxtStudy #47redmine @daipresentsさんのRxtStudyとshinagawa.redmineの講演資料を@sakaba37さんと読みながら、自分が理解してなかった点がたくさんあることが分かった。 気付いたことをメモ書き。 間違っていたら後で直す。 【shinagawa.redmineの講演資料】 【1】SVNリポジトリのスケールアップ チケット駆動開発の特徴は、ITSにSCM連携の機能があることで、トレーサビリティやソース変更履歴を即座に確認できる利点がある。 しかし、5人ぐらいの小規模開発チームから数百人以上の大規模な組織で運用する場合、SVNリポジトリがダウンしてしまうケースが出てくる。 そもそもRedmineのようなOSSのITSでは、大規模な運
ITSと開発プロセスのマッピング - プログラマの思索
@yusuke_kokuboさんが分かりやすい記事を書かれていたのでメモ。 【元ネタ】 Issue Tracking Systemの利用パターン - こくぼ＠Everything is the experience. 【1】RedmineやTracのようなITSは高機能でとても柔軟なため、いろんな状況で使い道がある。 チケット駆動開発の発端はTracのチケット管理であり、テスト工程のタスク管理をToDoリスト代わりに使う発想から生まれた。 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) 更に僕は、Redmineにチケット駆動開発を適用したらアジャイル開発が自然に運用できた経験をした。 そして、IT業界に限らず、営業・製造業・製薬業・情報システム部門などの色んな立場の人達がタスク管理だけでなく課題管理や要件管理
git-flow による構成管理とRedmineの関係 - プログラマの思索
「git-flow によるブランチ管理」という記事で、分散バージョン管理ツールを使った構成管理手法をとても分かりやすく書かれていた。 以前僕が書いた記事を見直して、理解が足りなかった部分があったと感じたので、もう一度まとめてみた。 【元ネタ】 git-flow によるブランチの管理 - O'Reilly Japan Community Blog A successful Git branching model を補助する git-flow を使ってみた - Twisted Mind 見えないチカラ: A successful Git branching model を翻訳しました A successful Git branching model: プログラマの思索 Mercurialで独立並行リリース管理: プログラマの思索 Mercurialによるチケット駆動開発は強力だ！: プログラマ
DevLove道場の感想 #agilesamurai #devlove - プログラマの思索
先日、DevLove関西でお会いした@papandaさんのご好意でアジャイルサムライDevLove道場に参加してきた。 「アジャイルサムライ」と同じく、ユーザストーリー洗い出し→バックログ作成→プラニングポーカーによる見積り→受入基準作成までのレシピで、とあるチームに途中参加させて頂いた。 感想を思いついたまま書く。 【参考】 ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索 ソフトウェア開発の工数見積もりが混乱しやすい理由: プログラマの思索 Scrumの見積りと計画づくりは何故優れているのか？: プログラマの思索 チームは加速するのか～Velocityの使い方 #agilesamurai: プログラマの思索 【1】途中参加したチームは、Androidで緩いタスク管理のツールを作るのが目的だったらしい。 ユーザストーリー洗い出しで、メンバーから案があまり出なかったので
redmineでナレッジを蓄積していく方法 - プログラマの思索
Redmineでナレッジを蓄積していく方法をメモ。 【1】Redmineにはチケット管理だけでなく、Wikiやフォーラム機能、リポジトリ閲覧機能などがあるので、チケット以外にも情報を蓄積できる仕組みがある。 情報を蓄積していくことができれば、新規メンバーへ説明しやすくなるし、作業の引継ぎも楽になる。 だが、情報を蓄積して保守していくコストをいかに感じさせないようにするか、という仕掛けが大事。 普通はWikiでプロジェクト内部の情報や技術ノウハウを蓄積していくだろうが、Redmineのプラグインで特定目的の情報を蓄積していくこともできる。 下記にあげたようなプラグインがあるようだ。 【用語集】 Redmine 用語集プラグイン: プログラマの思索 Redmine 用語集プラグイン Wiki - SourceForge.JP (引用開始) Redmine(プロジェクト管理システム)に用語集の機
redmineの作業分類から工数集計～活動基準原価計算 - プログラマの思索
Redmineによる工数集計について考えたことをメモ。 【1】工数集計の問題点 チーム運営する現場リーダーではなく、売上責任を持つマネージャがRedmineに期待する機能は工数集計だろう。 マネージャにとって、プロジェクトの成功とは、品質の良いシステムを確実に納品できるだけでなく、売上がコストよりも高くて利益が出ることだ。 ITプロジェクトは殆どが受託プロジェクトであるから、SEやPGの人月計算、つまり工数集計が重要になる。 特に運用保守のように、一定の金額で契約している場合、当初の予定工数よりも大幅に実績工数がオーバーしたら、ビジネスでない単なるサービスに過ぎない。 だから、予定工数よりも実績工数が上回らないように、もし上回ったとしても、多少の赤字に抑えるようにマネジメントしなくてはならない。 しかし、工数集計の作業は面倒極まりない。 従来のExcelの場合、メンバーに月末に指定のExc
Redmineの大規模化の壁 - プログラマの思索
昨日、meeting/17 - Shibuya.trac第12回勉強会～チケット管理システム大決戦 第二弾～Shibuya.trac Wiki - SourceForge.JPが開かれた。 UStreamで観戦して、とても面白かったです。 スタッフの皆さん、お疲れ様でした。 実際の議論を聞いて参考になったとともに、Redmine派の自分としては、@daipresentsさんの話がもっと聞きたかったな、と思っている。 今の僕の興味は、一プロジェクトでITSを使ってプロジェクト管理することよりも、1個の事業部、1つの会社全体へRedmineのようなITSを導入して運用して、ソフトウェア開発の基幹業務システムにしてしまいたいという思いに移っているから。 僕もRedmineを4年間使ってみて、一プロジェクトの事例はたくさん経験したし、ボトムアップで成功例を作ることで他チームへ影響させることができる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WF型開発にとらわれすぎたTiDDのアンチパターン #tidd - プログラマの思索