メールアドレスの正規表現でユーザグループを自動設定するプラグインredmine_auto_assign_group - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
WindowsのRubyのバージョン管理はuruを使う - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Redmineがいくら良くても会社の上司や経営者が見なければExcelがはびこってしまう事例 - プログラマの思索
Redmineのようなチケット管理ツールがとても威力があっても、上司や経営者が見なければExcelがはびこってしまう事例を見かけたのでメモ。 チケット管理ツールに限らず、営業支援システム、日報システム、経営状況の見える化の為の情報系システムでも同様の症状がよく発生する。 【参考】 golangでRedmineの情報をExcelにするコマンドラインクライアントを作った - write ahead log Big Sky :: コマンドラインからredmineを扱える「godmine」作った。 【1】(引用開始) SIerに所属している方ならわかると思いますが(あんまりわかって欲しくもないですが),体質の古い会社だとRedmineを使っていても「Excel表がない」と文句を言われたりします. 面倒なのが「プロジェクト一覧表がない」とか「課題管理表がない」とか「バグ一覧表がない」とか....et
CSV形式のデータをSQLを使って解析する方法 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
もう一つのテスト管理ツールTestopia - プログラマの思索
BugzillaのアドオンにTestopiaというテスト管理ツールがあるらしい。 TwitterでTestLinkを検索していたら、たまたま見つけた。 【元ネタ】 Twitter / Search - testlink Questions on TestLink Tool - Software Testing Club - online QA & Software Testing Community Bugzilla Main PageからのTestopiaデモサイト Extension:Testopia Reports - MediaWiki Testopia:Documentation - MozillaWiki Testopia_Manual.pdf もう一つのテスト管理ツールRTH: プログラマの思索 TestLinkの隠れ機能～工数集計とステータス設定: プログラマの思索 Tes
障害を故意に起こさせるツールで耐障害性を高める - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
リーマンの法則～ソフトウェアもエントロピー増大の法則を避けられない - プログラマの思索
森崎さんのBlogを読んで、ソフトウェアもエントロピー増大の法則を避けられないのだなあと思った。 だが、ソフトウェアはハードウェアとは違う特徴がかなりあると思う。 考えたことをメモ書き。 【元ネタ】 ソフトウェア保守の法則（リーマンの法則）、ご存知ですか？：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ バグ修正のための変更の40%が新たなバグを混入するという研究結果 - Googleのバグ予測方法との共通点：森崎修司の「どうやってはかるの？」：ITmedia オルタナティブ・ブログ Googleのバグ予測アルゴリズム: プログラマの思索 リーマンの法則とは、上記記事にもある通り、ソフトウェア保守に関する経験則。 元々は5つあるそうだが、「ソフトウェア工学・システム工学ハンドブック―エンピリカルアプローチによる法則とその理論」によれば次の3つにまとめられると言う
【告知】「チケット駆動開発」ハンドブックを出版します - プログラマの思索
2012/8/24に@sakaba37さんと「チケット駆動開発～プロジェクトを成功に導くための「現場からの改善」提案を完全網羅」を出版します。 前作「Redmineによるタスクマネジメント実践技法」に続くチケット駆動開発の解説本になります。 過去5年間、チケット駆動開発とは如何なるもので、一体何ができるのか、という根本的な問題をずっと考えてきた結果を全て書きました。 元々は@machuさんがTracのチケット管理から提唱したアイデアを参考にして、故意にそのアイデアを拡張して、Redmine上でアジャイル開発を実践できるように、自分なりのノウハウを詰め込みました。 その後、チケット駆動開発について講演したり、コミュニティで議論しながら、アジャイル開発だけでなく、技術や開発プロセス全般、ソフトウェア工学など色んな観点で分析するように努めてきました。 そして、チケット駆動開発に関する技法や適用方
アジャイル開発が重視する品質特性～保守性と移植性 - プログラマの思索
ソフトウェアで出てくる品質はとても掴みどころがなく、測定できたとしても意外に役立たない。 そして、従来のWF型開発が重視する品質に対し、アジャイル開発は別の観点の品質特性を重視することによって、ソフトウェア開発のあり方を変えようとしているように思える。 考えたことをラフなメモ書き。 【元ネタ】 Agile開発が指摘したソフトウェア開発の特徴: プログラマの思索 【1】アジャイル開発の本質は小規模リリースだと思う。 いきなり大きな物を作るのではなく、実際に動くものを小さく作り、小刻みなVerUpによって機能拡張も品質も改善していく手法。 その利点は、顧客やマーケットに対し、不完全であってもいち早くリリースできることで、インパクトを与えることができること。 仕様が完全に固まって作るプロダクトアウトの製品よりも、マーケットの動向に合わせて柔軟に計画や方針を変えていくマーケットインの製品に向いてい
モデリング再復習DOA編part1～情報無損失分解と結合の罠 - プログラマの思索
DOAに関する技法で理解できた内容をまとめるために今後いくつか書き留める。 1回目は、情報無損失分解についてラフなメモ書き。 【1】DOAの基本はテーブルの正規化だ。 第1～5正規化まであるが、どのDOA本も無味乾燥で、本質的なことを書いていないように思う。 第3正規化で十分とか、関数従属性からどのように正規化していけばいいのかという手法まできちんと説明した本はあまりない。 また、正規化しすぎると良くないので、あえて正規化を崩す技法を勧める時もあり、正直分かりにくい。 特に思うのは、ほとんどのDOAの本の内容が20年前の時代のまま変わっていない気がすること。 そもそもDBサーバーの性能や価格も大幅に変わったし、DBMSも高機能化してオープンソースDBMSも業務系システムに十分に使える時代になったのだから、DOAの技法もどんどん進化していいはずだ。 OOAですら、UMLと絡めたモデリング手法
アジャイルの概念を取り入れたCMMI - プログラマの思索
岡本 隆史さんが、アジャイルの概念を取り入れたCMMIの記事を公開されていたのでメモ。 ラフなメモ書き。 【元ネタ】 徹底検証！ CMMIはアジャイルの改善にも役立つか？－ ＠IT情報マネジメント CMMI | CMMI Solutions | Translations | CMMI 日本語翻訳版 上記の記事を読むと、スクラムを例として、アジャイル開発のワークフローにCMMIの概念をマッピングして整合性を取ろうとしているように思える。 ScrumとCMM/CMMIの親和性については、「スクラム入門-アジャイルプロジェクトマネジメント」の一番最後の付録で既に書かれてる。 「スクラム入門-アジャイルプロジェクトマネジメント」では、ScrumのプラクティスはCMMMIのレベル2、3のKPAをほぼ網羅しており、不足しているKPAは、プラクティスの制度化とソフトウェア外注管理だけだという指摘がある。
定量的プロジェクト管理ツールはIT企業の基幹システムを目指す - プログラマの思索
IPAが出版していると思われる雑誌にチケット駆動開発の記事を見つけたのでメモ。 【元ネタ】 SEC journal_No28 IPAの定量的プロジェクト管理ツール #redmine: プログラマの思索 Redmineを業務システム化するアイデア～メトリクス集計の本質は集計バッチ処理: プログラマの思索 「定量的プロジェクト管理ツール(IPF)の紹介」の記事で、IPAが作った定量的プロジェクト管理ツールがどのような目的で作られて、どの範囲を適用しようとしているのか、を解説している。 その記事の中で、このツールがRedmineやTracを元ネタとして、プロジェクトの状況を各種のメトリクスで出力する時に、チケット駆動開発のアイデアを適用していると書かれている。 本来、チケット駆動開発は軽量なプロセスであり、チケットをタスクカードとして扱うという簡単な発想から発展してきた。 だが、このアイデアを突
分散バージョン管理はバージョンではなくリビジョンを管理する - プログラマの思索
InfoQの分散バージョン管理の記事を読んだ後に、もう一度、JoelがMercurialについて書かれた記事を再読して、ようやく分散バージョン管理が従来のバージョン管理ツールと何が違うのか分かったのでメモ。 ラフなメモ書き。 殴り書きの部分は後で直す。 【元ネタ】 分散バージョン管理で間違いないって、ベイビー - The Joel on Software Translation Project JoelもMercurialを使っている: プログラマの思索 InfoQ: エンタープライズ分野での分散バージョン管理システム 分散バージョン管理の可能性: プログラマの思索 (前略) 分散バージョン管理で実際のところ一番重要なのは、「分散」という部分ではないのだ。 重要なのは、このシステムが「バージョン」ではなく「変更」(注釈：リビジョン)で物事を捉えているということだ。 (中略) Subvers
分散バージョン管理の可能性 - プログラマの思索
InfoQに分散バージョン管理の可能性の記事があったのでメモ。 ラフなメモ書き。 【元ネタ】 InfoQ: エンタープライズ分野での分散バージョン管理システム (引用開始) DVCSは速度を重視して設計されている。新しい実装方式、新しい技術、苦労した獲得した知識の結集であり、前世代のSCMよりも高速に動作する。ローカルにリポジトリを持てるから速いというだけでなく、従来のSCMと同様の条件でも速い。また、ブランチ作成も得意でマージ機能も優れている。90年代後半から2000年代前半ではブランチ作成とマージは"悪"だった。その当時の主流のバージョン管理システムのブランチ作成機能とマージ機能が貧弱だったからだ。処理が遅く、エラーが頻発していた。その結果、若い開発者はブランチ/マージ嫌いとして育ってしまった。DVCSは高速に動作するブランチ作成機能と本当に使えるマージトラッキング機能を実装した。30
ドメイン駆動設計は設計のアジャイル化～オブジェクト指向設計の先祖返り - プログラマの思索
エリック・エヴァンスのドメイン駆動設計の本を一通り読んでみて、何かすっきりしない感想を持っていた。 @sakaba37さんや@jp_watanabeさんと議論して、すっきりしない原因がようやく分かったのでメモ。 ラフなメモ書き。 【元ネタ】 ドメイン駆動設計: プログラマの思索 ドメイン駆動設計よりもパターン本が好き: プログラマの思索 ドメイン駆動設計はソフトウェアプロダクトラインとオブジェクト指向分析のミッシングリング: プログラマの思索 DOAとOOAの違い: プログラマの思索 Agile開発に足りないもの～モデリング技術: プログラマの思索 ドメイン駆動設計の本の違和感は二つある。 一つは、分析と設計を区別せず、設計中心の技法ばかり説明していること。 もう一つは、過去のオブジェクト指向設計との違いがはっきり理解できていなかったこと。 前者は、「ドメイン駆動設計」というタイトル通り「
Redmine1.4におけるNo Ticket, No Commitの強化 - プログラマの思索
Redmine1.4の機能改善において、No Ticket, No Commitの強化につながる機能があったのでメモ。 【元ネタ】 Redmine 1.4新機能紹介: チケットとリビジョンの関連づけの追加・削除 | Redmine.JP Blog Twitter / @mkinside82: ほんとにCommit Relation Editor Pluginそっくりですね/Redmine 1.4新機能紹介: チケットとリビジョンの関連づけの追加・削除 | Redmine.JP Blog Twitter / @mkinside82: Commit Relation Editor - Plugins - Redmine Twitter / @mkinside82: @akipii もともとチケットが上がっていたようですね ⇒ http://bit.ly/HPLVM5 @haru_iida さん
エクストリーム・プログラミング入門を読み直す - プログラマの思索
今頃になって、XPエクストリーム・プログラミング入門(白本)を読み直してみた。 考えたことをラフなメモ書き。 【元ネタ】 Hot Heart, Cool Mind.: エクストリームプログラミング(XP) 邦訳(XP エクストリームプログラミング入門)へのコメント パターン、Wiki、XPは良書: プログラマの思索 【1】XPエクストリーム・プログラミング入門は第2版になって、原理・原則・プラクティスが覚えきれないほど大幅に増加している。 だから、以前の僕は第1版にあるプラクティスの方が分かりやすくて好きだった。 しかし、今になって見直すと、現在までのアジャイル開発の流れを予測しているかのような概念が出てくることに驚かされる。 応用プラクティスにある各プラクティスを考えてみる。 「インクリメンタル配置」は小規模リリースと同じ。インクリメンタルな開発、つまりイテレーション単位の機能改善による
パターン、Wiki、XPは良書 - プログラマの思索
「パターン、Wiki、XP」を読んだ。「ThoughtWorksアンソロジー」のようにエッセー風だが、本質的なことがたくさん書かれているような気がした。 感想をラフなメモ書き。 【元ネタ】 パターン、Wiki、XP - 第1部：建築 - Li:d tech パターン、Wiki、XP - 第2部：ソフトウェア開発 - Li:d tech パターン、Wiki、XP - 第3部：Wiki - Li:d tech Smile Experience: パターンランゲージの会 404 Blog Not Found:時を超える創造の原則 - 書評 - パターン、Wiki、XP 書評リンク集 - 『パターン、Wiki、XP』サポートWiki 『パターン、Wiki、XP - 時を超えた創造の原則』感想、少しばかりの余談 - antipop 『パターン、Wiki、XP』と「協働＝お互い様」のマーケティング |
Redmineでチケット駆動開発をAgileに運用するための4つの方法 - プログラマの思索
Redmineでチケット駆動開発をAgileに運用するための方法をもう一度まとめておく。 あくまでも僕の一意見なので参考までに。 【参考】 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 Agile開発の肝はイテレーションにあり: プログラマの思索 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 【Redmineでチケット駆動開発をAgileに運用するための4つの方法】 (1)RedmineチケットをXPのタスクカードのように扱う (Ticket
チケット駆動開発を日本発のアジャイル開発へ発展させるには？ - プログラマの思索
さかばさんの記事を読んで考えたことをメモ。 【元ネタ】 [TiDD] 小規模開発の難しさを考える: ソフトウェアさかば チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) アジャイル開発は元来、小規模で変化の激しいプロジェクトが向いていると言われてきた。 しかし、XPが出現して10年も経つというのに、現場の実践例は非常に少ない。 ネット上でアジャイル開発の情報がこれだけ溢れていて、開発者も興味を持っているのに、事例になかなかお目にかからない。 情報処理試験の勉強でも、プロセス改善のセミナーでも、繰り返し型開発の重要性が叫ばれているのに、事例は非常に少ない。 その原因は、単純にアジャイル開発を実践できる技術力が足りないからだと思っている。 テスト駆動開発を実践するには、JUnitを使いこなさねばならない。 常時統合
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
