Redmineで要件管理、リスク管理ができるプラグイン - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Mercurialによるチケット駆動開発は強力だ！ - プログラマの思索
Mercurialを使ったチケット駆動開発の記事が非常に素晴らしいのでメモ。 このやり方を使いこなせれば、ソフトウェア開発の生産性は劇的に上がると思う。 【元ネタ】 mercurialでチケット駆動開発 - ろじぼ 上記の記事を理解できた範囲でまとめてみた。 【仮定】 ・SCMはMercurial。(Gitでも良い) ・BTSチケットでSW開発のタスクを管理する。 ・trunk、confirmブランチは中央リポジトリ(サーバー)にある。 ・チケットブランチ(トピックブランチ)は、ローカルとサーバーの2箇所にある。 常時同期されている。 ・作業の優先順位によって、チケットがリリース順≠開発順の状況はある。 【チケットAブランチ上の作業手順】 1・チケット担当時に、ブランチ作成。【チケットのステータス＝担当】 ↓ 2・チケットAブランチ上でガンガン開発する。【チケットのステータス＝担当】 →t
更にもう一つのAll In OneRedmine～RedmineLE - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Redmineの日本語マニュアル - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Redmineの最新動向 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
TiDDをRubyで補強するアイデア - プログラマの思索
RubyとRailsを触り始めた。 とても書きやすい。 Rubyに色んな可能性を感じている。 TiDDをRubyでサポートするアイデアをメモ。 【1】BTSチケットのFS関係から、ネットワーク図を作成し、クリティカルパスを自動計算する チケット駆動開発にPMBOKの概念を導入してみる: プログラマの思索に書いた。 やりたいのは、開発中にクリティカルパス上にあるチケットを調べたい。 それらのチケットを管理するのが、プロジェクトマネージャの最重要な仕事だから。 できれば、バージョン毎にクリティカルパスを計算したい。 1個のバージョンに含まれるチケット数はせいぜい10個ぐらいなので、すぐに計算できるはず。 多分バックトラックのアルゴリズムを使えば、計算できるだろうと想像している。 Redmineのプラグインとして作れるはず。 【2】チケットの予定・実績工数から、プロジェクトのEVMを計算する チ
クラウド時代のSW開発スタイル - プログラマの思索
「Twitterの衝撃 140文字がビジネスからメディアまで変える」を立ち読みした。 TwitterがRuby on Railsをフロントエンドで使っているのは知っていたが、メッセージの非同期処理(MQ)でScalaを使って性能改善したという説明があった。 気になったのでメモ。 【参考】 まだブロ: [Scala] Twitterの移行について twitterがrubyからscalaへスイッチ - huixingの日記 第7回 関数脳のつくり方 First Season - 刺激を求める技術者に捧げるScala講座：ITpro ScalaはJavaVM上で動く関数型言語。 TwitterがScalaをどこでどのように使っているのか、正直理解できていない。 しかし、大量のデータをさばく処理に対し、関数型言語を使ってMapReduceアルゴリズムで高速化を図っているのではないか、と推測している
モデル検査ツールLTSAのメモ - プログラマの思索
モデル検査ツールLTSAについてのメモ。 LTSAについてのリンク一覧は、garyoさんのはてぶから辿ればいい。 はてなブックマーク - Junk☆Bookmark臥龍 - LTSA 【他の参考資料】 LTSAによる組み込みソフトウエアのモデリングと動作検証 →これが一番分かりやすい。 LTSAというツールが状態遷移図のモデリングに大変有効である理由と例が説明されている。 特に組込み機器のように、デッドロックや並行性、セマフォなどを考慮する必要がある時に役立ちそう。 LTSA Tutorial ― Yamamoto Lab. Web Site →LTSAのツールの使い方が説明されている。分かりやすい。 Concurrency スライド →LTSAの英語本を大学の講義録として公開されている。読みやすい。 LTSA - Labelled Transition System Analyser →
第13回名古屋アジャイル勉強会発表資料『チケット駆動開発入門』 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
クラウドコンピューティングとKey-Valueストア - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
プロジェクト管理やテスト工程をクラウド化する - プログラマの思索
Hudsonの下記記事を読んだ感想をメモ書き。 【元ネタ】 Hudson Selenium PluginでHudsonクラスタをSelenium Gridに - 川口耕介の日記 近年、HadoopやSeleniumなど、複数のサーバ上で動作する事が前提のツールが増えてきており、マルチコア化・クラウド絡みで、このトレンドは今後も続くと予想されます。 ところが、こういったツールはセットアップと運用保守に手間がかかるという欠点があります。 Hudsonで僕がやろうと思っている事の一つは、Hudsonのクラスタ上にこういったツールをインストールするのを簡単にすることです。 Hudsonのクラスタはインストールがとても簡単ですし、プラグインのインストールも容易なので、この環境の上に他のツールをオーバーレイすることで、手間なく様々なツールを利用できるようになります。 「ThoughtWorksアンソロ
Redmineの運用例その2 - プログラマの思索
Redmine運用例の記事があったのでメモ。 【元ネタ】 [Think IT] 第2回：ProjectKeeperに見る開発方法論 （1/3） [Think IT] 第2回：ProjectKeeperに見る開発方法論 （2/3） [Think IT] 第3回：SIOS Applicationsの過去未来 （1/3） [Think IT] 第3回：SIOS Applicationsの過去未来 （2/3） [Think IT] 第3回：SIOS Applicationsの過去未来 （3/3） 【特徴】 プロジェクト管理ソフトウェアProjectKeeperのタスク管理にRedmineを使っているらしい。 WebSphere＋DB2で動作するから、IBM系列と思われる。 記事を読むと下記の運用ルールがあると思われる。 1・Redmineには、製品ロードマップ、顧客要望、バグ情報などが一元管理され
Web2.0の本質はデータマイニングにあり - プログラマの思索
レコメンドエンジンの話を知りたくて、「集合知プログラミング」という本を買ってみた。 内容はいわゆるデータマイニング。 全て読めてないけど、すごく面白かったので、考えていることをメモ書き。 ＃後でロジカルに書く。 【1】僕が「集合知プログラミング」を読んで思ったことは「Web2.0の本質はデータマイニングにあり」。 【元ネタ1】 プログラマーに最適なデータマイニングの教科書 『集合知プログラミング』 - 図書館情報学を学ぶ 集合知プログラミングが凄すぎる件について - プログラマになりたい オープンソースのレコメンドエンジン Taste - プログラマになりたい オープンソースのレコメンドエンジン Taste Web2.0の成功例としては、Amazonの関連商品、iTunesのお勧め曲表示、はてなブックマーク、GoogleのpageLankによる検索エンジンなどがあげられるだろう。 これらの
All In One Redmineの作り方 - プログラマの思索
Fedora10上でTestLinkとBugzillaのVMwareイメージがあったので、更にRedmineをインストールしてみたら、正常動作できた。 このVMイメージさえあれば、All In One Redmine(正しくは、All In One Redmine＋TestLink)として使える。 作成方法をメモ。 【必要なもの】 ダウンロードURL-Fedora7にTestLinkとBugzillaをインストールしたVMwareのイメージ-PukiWiki - TEF有志によるテスト管理システムTestLink日本語化プロジェクト VMware Player 【戦略】 上記のFedora10には、既に下記がインストールされている。 Java 1.6.0_0(但しJREであってJDKではない) php 5.2.6 perl 5.10.0 python 2.5.2 MySQL 5.0.67
チケット駆動開発の論文 - プログラマの思索
さかばさんがチケット駆動開発の論文を書かれたのでリンクしておく。 【元ネタ】 ソフトウェアさかば: TiDD：チケット駆動によるアジャイル開発法 さかばさんの論文の主張を抽出すると下記になる。 １・TiDD(Ticket Driven Development)は、古くからある障害管理ツールなどを包括的な構成管理ツールへ拡張し、それらのツールに合わせた開発プロセスである。 例： バージョン管理(ソース管理)→Subversion 障害管理→Redmine 単体テスト→テスト駆動開発 自動ビルド→継続的インテグレーション ２・アジャイル開発を運用する上での難点の一つである進化的保守は、TiDDでは、プロジェクト管理をチケット管理で置き換えることで解決しようとする。 ３・二つ目の難点である並行開発は、メインラインモデルとチケット管理の組み合わせで解決しようとする。 ４・３つ目の難点である頻繁なリ
チケット駆動開発の本質はバージョン・ファースト - プログラマの思索
チケット駆動開発(TiDD)について考えていることを書く。 ※注意：チケット駆動開発(Ticket Driven Develpment)の略語は、「TDD」だとテスト駆動開発(Test Driven Develpment)と間違えやすいので、「TiDD」と以降呼ぶことにする。(命名者：えと～さん) 【元ネタ】 チケット駆動開発は、まちゅさんによって提唱されている。 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) 【1】チケット駆動開発のプラクティス チケット駆動開発は定義そのものがあやふやなのだが、僕は下記4個ののプラクティスがあると思う。 ※注意・下記のプラクティスはあくまでも僕個人の考えであることを断っておく。 【1-1】チケット・ファースト(Ticket First) プロジェクト内部の作業は、チケットを受け取ってから始まる。 つまり、工数が発生す
Web2.0時代のプロジェクト管理 - プログラマの思索
「Trac入門 ――ソフトウェア開発・プロジェクト管理活用ガイド」を読んでインスピレーションを得たこと、下記のBlogで得たヒントを書く。 【元ネタ】 Trac入門というより、新しい時代のプロジェクト管理入門 Trac入門 ――ソフトウェア開発・プロジェクト管理活用ガイド Web2.0時代のバグ管理ツールを作る 【1】Excelによるプロジェクト管理は、紙を使った前近代の管理とBTSを使うWeb2.0時代の管理の過渡期の手法 本番リリース後にお客から障害発生が通知されたら、その履歴をきちんと管理するために、バグ管理するだろう。 そういう管理すらないプロジェクトでは、障害の事象や、その修正状況を共有するインフラが無い。 「今問題となっている障害は、障害管理番号XXX番のことですよ！」と一言言えば済むのに、一意に降られた番号が無ければ、最初から逐一説明しないといけない。 つまり、バグ管理IDを
Redmineインストールメモ - プログラマの思索
Redmineのインストールや設定に関するメモ。 【1】Passengerをインストールすると、RailsをApache単独で稼動できる。 http://redmine.jp/tech_note/apache-passenger/ gem install passenger passenger-install-apache2-module 後は、httpd.confの設定だけすればいい。 Passengerの利点は、RailsがPerlやPHPと同じ感覚で運用できることだ。 今後のビジネスを考えると、RailsをJRubyで動かすか、Apacheで動かすか、どちらかが重要になるだろう。 要注目の技術だと思う。 【2】Wikiを使うには、下記を実行。 gem install RedCloth 但し、活動欄に表示されるチケット内容は、Wikiのシンタックスがそのまま表示されてしまう。 【3】日
Retrospectivaをインストールしてみる - プログラマの思索
Ruby on Railsで作られたBTSで最も有名なのは、おそらくRedmine。 しかし、他にもRetrospectivaというBTSが存在するらしいのでインストールしてみた。 その時のインストールのログと感想をメモ。 【1】詳細は、QuickInstallを見よ。 環境は、Linux。Windowsでも同様でOK。 http://retrospectiva.googlecode.com/svn/trunk からSVNエクスポート ↓ database.ymlへ変更 ここではMySQLを使う。 ↓ MySQLでDB作成 drop database retrospectiva; CREATE DATABASE IF NOT EXISTS retrospectiva; GRANT ALL PRIVILEGES ON retrospectiva.* TO "retrospectiva"@"l
ソフトウェア構成管理に至るまでの道のり - プログラマの思索
「何故、設計書をバージョン管理するのか？」という疑問から、ソフトウェア構成管理について考え直してみる。 ＃あくまでもメモ書き。 【元ネタ】 ■[development][trac]構成管理ツールをいかにして導入するか ■[システム開発][構成管理]構成管理ツールはどのようなタイミングで導入し、どのように活用すべきなのだろうか？ ■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理 ソフトウェア構成管理 【1】バージョン管理が無かった頃 今でも多いが、WordやExcelの設計書をバージョン管理していないプロジェクトは多い。 その時の最大の問題点は、■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理 にその理由が書かれている。 ほっておくと自然増殖してくるのが、下記のような形式のドキュメント
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
