請負契約がソフトウェア開発者を苦しめている - プログラマの思索
IT業界で仕事していて、何故かデスマーチプロジェクトに数年に1回はぶち当たる。 デスマーチに陥る原因は技術力の不足やプロジェクト管理の能力不足などがあるけれども、IT業界で一般的な請負契約そのものに根本原因があるような気がしている。 請負契約が日本のソフトウェア開発者を苦しめているのではないかという仮説について考えたことをラフなメモ書き。 【元ネタ】 Twitter / @akipii: 日本のソフトウェア開発者を苦しめている根源に請負契約があるという仮設を考えてる。平鍋さんや倉貫さんが試しているアジャイルな契約は請負契約のアンチテーゼと考えると分かる気がする。 Twitter / @akipii: @mr_amichan 請負契約の制約条件は開発者の想像以上にソフトウェア開発者に厳しいのです。請負契約である限り本当のアジャイルな開発でないと体験してます。それをうまく説明したい。 Twit
SVNのコミットログの書き方 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
HudsonのSubversion Tagging Plugin - プログラマの思索
ビルド管理ツールHudsonのSubversion Tagging Pluginがとても使いやすいのでメモ。 CVSにも同様のプラグインがある。 【元ネタ】 Subversion Tagging Plugin - hudson - Hudson Wiki CVS Tagging Plugin - hudson - Hudson Wiki HudsonのSubversion Tagging Pluginの使い方は下記を想定している。 SVNでタグ付け 例：yyyyMMdd＋連番3桁 ↓ Hudsonで、指定したSVNタグをチェックアウトして、ビルドモジュールを作成 ↓ リリース後、RedmineのバージョンをSVNタグでリネームする。 又は、TracのマイルストーンをSVNタグでリネームして、完了ステータスへ更新する。 又は、Mantisの修正予定・修正済みバージョンをSVNタグでリネームし
TortoiseHgの気になるExtension - プログラマの思索
TortoiseHgは、mercurial.iniの[extension]へコマンドを追加すれば機能拡張できる。 その中でコードレビューに関する機能があったのでメモ。 【元ネタ】 8. Extensions ― TortoiseHg v1.1.3 documentation UsingExtensions - Mercurial 【元ネタ1】CodeReview * This extension allows you to manage reviews for your code in any project you like. * It helps to keep the review management inside the mercurial. * One can add files to the review or remove them. * The reviewer can
複雑度と単体テストケース数の相関関係 - プログラマの思索
garyoさんから、ソースの複雑度と単体テストケース数について有益なアドバイスを示唆してもらったので、メモしておく。 ◆SourceMonitor Version 2.4 SourceMonitorはフリーで、以下の言語のソースのソフトウェア複雑度（McCabeのサイクロマチック数）を測定できる。 例：C++, C, C#, VB.NET, Java, Delphi, Visual Basic (VB6) or HTML ◆McCabe's cyclomatic complexity SourceMonitorで求められる複雑度（McCabeのサイクロマチック数）は、モジュール内の分岐の数（＋ループの数）で計算される。 複雑度の数値は、下記の意味を持つらしい。 10 以下であればよい構造 30 を越える場合，構造に疑問 50 を越える場合，テストが不可能 75 を越える場合，いかなる変更も
プログラマの思索: RedmineがExcelよりも素晴らしい点
Redmineの使い方は下記を見よ。 http://www.redmine.org/projects/show/redmine 【1】以下、Redmineを使った感想を書いてみる。 1-0.ガントチャートがリアルタイムに表示される。 こいつに一番感動した。 プロジェクトリーダーは、ガントチャート保守に、彼の作業時間の殆どを費やす。 その理由は、プロジェクトのリスクがガントチャートでしか把握できないからだろう。 考えてみれば、作業の開始日と終了日、作業状態さえ入力すれば、リアルタイムにガントチャートは計算できるはず。 殆どのITプロジェクトのガントチャートは、手作業でかなりの時間を浪費して作っているか、MSProjectのように保守しても理解しにくいか、どちらかだ。 ソフトウェア開発のプロジェクト管理で最もIT化されていない部分と言える。 1-1.SVNリポジトリとチケットが相互リンクできる
アート・オブ・プロジェクトマネジメントを読み直してTiDDを補強する - プログラマの思索
「アート・オブ・プロジェクトマネジメント」を読み直して、チケット駆動開発を運用した経験から、そうだよ！と何度も頷くところがあった。 ラフなメモ書き。 【元ネタ】 「 アート・オブ・プロジェクトマネジメント」の検索結果1 - 脱・下流エンジニア (仮) 「 アート・オブ・プロジェクトマネジメント」の検索結果2 - 脱・下流エンジニア (仮) 【12章 リーダーシップが信頼に基づく理由】 「表明」とはコミットメント、約束を意味する。 メンバーが表明することによって、小さな約束が積み重ねられて、一つのシステムが完成する。 チケット駆動開発では、チケットファーストの原則に表明の概念が組み込まれている。 プロジェクトで発生する全ての作業は、チケットに起票してから開始する。 WBSから起こされたタスクも、突発的な事件によって発生したタスクも、まずチケットに起票する。 そのチケットには、開始日と終了日、
Redmineのニコニコカレンダー・プラグイン - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
【公開】XP祭り関西2010発表資料「チケット駆動開発のプラクティス集」 - プログラマの思索
昨日、ＸＰ祭り関西２０１０が無事に終了した。 多分150人近い参加者だったと思うので、大成功だった。 東京から長瀬さん、AgileJapanのebackyさんやミルズさん、日経BPの井上さん、XPJUGの倉貫さん、岡山からてつさん、福井から岡島さん。 東京や名古屋など遠方から結構な数の人が来てくれた。 関西はアジャイル開発のマーケットが十分にある手応えを感じた。 チケット駆動開発セッションも、懇親会で感想を聞くと評判が良かったみたい。 TiDDの事例や試行錯誤を聞けて興味深かったらしい。 実際にBTSを使っている人もいれば、今から試そうとしている人もいて、色んな観点で聞いていたようだ。 僕はWeb系開発でRedmine、さかばさんはパッケージ製品開発でTrac、小枝さんは組込製品開発でManitsを使って、TiDDを実践した事例を三者三様で話した。 僕も、二人の話は既に聞いていたけど、改め
Excelのプロジェクト管理は何故良くないのか - プログラマの思索
XP祭り関西2010のTiDDセッションの感想を読んでメモ。 【元ネタ】 [TiDD] BTSがチケット駆動開発に向いている理由: ソフトウェアさかば 2010-02-07 - winplusの日記 XP祭り関西2010に参加してきた - Basic XP祭り関西2010でアジャイルとチケット駆動開発について考えてきた #xpjugkansai - Pragmatic Style 【1】2010-02-07 - winplusの日記の感想について、倉貫さんの事情は色々あると思うけど、僕の意見を一言。 (前略) それと、倉貫さんが「Redmine でも重い」「Googleのスプレッドシートでタスク管理している」という発言に、あきぴーさんが「僕は納得していない」と。 この日に目撃したほとんど唯一の衝突だったのですが、それ以上の展開がなかったので、すごく残念でした。 倉貫さんの Excelならダ
派生開発プロセスXDDPの講演メモ - プログラマの思索
SQIP2009で清水吉男さんのXDDPの講演を聞く機会があった。 アジャイル開発や並行開発、要求仕様と機能仕様の違いについて、とても勉強になったので、メモを公開しておく。 なお、メモ書きなので、分かりにくい部分は、下記の著書を読んで理解してください。 【講演メモ】 ◆派生開発の特徴と問題点 保守開発 JISで定義されている 派生開発とは似ているが異なる 例：携帯電話は、電話以外の機能が次々と追加されている 保守ではない →是正保守プロセスで改良保守を行うと問題が発生する 派生開発特有の混乱が生じている まずい作業で品質が劣化する 派生開発にはアーキテクチャ設計がなくても開発できる 仕様は設計しないと出てこない 衝突は仕様レベルで出る 派生開発は新規開発よりも複雑 追加機能と変更は異なる 機能追加は、新しい機能の仕様やレビューしかない 追加と変更の2本立てにしなければならない ソースも移植
要求管理プロセスのポイントは要件カバレッジとトレーサビリティマトリクス - プログラマの思索
要求管理プロセスについて良い記事があったのでメモ。 【元ネタ1】 ＠IT：みんなが悩む要求管理（8） 最終回 要求管理ツールの賢い使い方 まず、要求をWordのような文書ソフトで管理すると、要求の属性や履歴の管理が難しく、要求間でトレーサビリティが設定できないという欠点があります。 一方、要求を表計算ソフトで管理すると、要求を文脈の中で表現することが難しく、要求間でトレーサビリティを設定するのが難しいという欠点があります。 いっそのこと、要求を管理するためにデータベースをカスタマイズしたツールを使うケースがありますが、この場合でも、要求を文脈の中で表現することが難しく、ツールの保守にコストがかかります。 ある程度、大規模なシステム開発の場合は、市販の要求管理ツールを用いた方がメリットの出るケースが多いと思います。 IBM Rational RequisiteProを使った要求管理の事例。
Redmineに入れたプラグイン一覧 - プログラマの思索
RedmineのVer0.8.4、0.8.6に入れたプラグインのうち、使っているものを公開してみる。 1年前に比べると、プラグインが充実していて楽しい。 結局10個以上も入れていた(^^;) 【コードレビュー】 r-labs - Code Review - Redmine Redmineのプラグインが充実している: プログラマの思索 リポジトリ画面からコードレビューのチケットを発行して、レビューをワークフロー管理できる。 お手軽にコードレビューできるのがいい。 レビューもチケットにするから、ワークフローのカスタマイズも可能。 【Hudson】 r-labs - Hudson - Redmine Redmineのプラグインが充実している: プログラマの思索 Hudsonと連携して、ビルド管理する。 SimpleCIプラグインよりもはるかに機能が充実している。 【Wiki拡張】 r-labs
Redmineで要件管理、リスク管理ができるプラグイン - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
チケット駆動開発のアンチパターン - プログラマの思索
チケット駆動開発のFAQ、プラクティス集以外にも、アンチパターンを考えてみた。 以下メモ書き。 【元ネタ】 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】チケットのアンチパターン 【1-1】乱発されたチケット よくある最悪なパターンは下記2ケースがあるだろう。 設計、開発、単体テストまでは穏便なものの、結合テストで火を噴き、たくさんのバグ報告があがる。 あるいは、リリース直後には、たくさんの障害報告や問合せが殺到する。 そのままチケットに登録すると、チケットが乱発される。 そして、それらのチケットを精査する工数が開発チームの許容量を超えると、チケットは放置される。 こういう状況はもはや、アジャイルだろうがTiDDだろうがCMMIだろうが、手に負える状況ではない。 【1-2】有効期限切れのチケット・放置されたチケット 終了予定日を過
ドキュメントも構成管理すべきだ - プログラマの思索
SVNで構成管理する時の良い記事が公開されたのでメモ。 【元ネタ】 Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所 SVNの使い方の記事はネット上にいくらでもある。 しかし、上記の記事で重要と思われる内容は、構成管理や変更管理の考え方を初心者向けに分かりやすく説明している点と、ドキュメント管理に構成管理の考え方を入れるべきだという主張だ。 CMMIの観点では、ソフトウェア構成管理は「変更管理を含むソフトウェアの構成を制御・管理できていること」と定義されている。 この考え方に基づくと、バージョンとは実はプロセスのベースラインを意味する。 つまり、リリース時にバージョン(又はタグ)を付けるタイミングは、開発者から顧客へ、あるいは営業チームから顧客へ、などのように、他者へ成果物を手渡すタイミングと同一なのだ。 構成管理が変更管理と密接に関係する理由は、上記のような
TortoiseHgでExcelの差分を見る方法 - プログラマの思索
TortoiseHgでExcelの差分を見る方法を見つけたのでメモ。 【元ネタ】 スィンプロ (sinproject) Windows Vista 環境で TortoiseHG（Mercurial）を利用してバージョン管理とバックアップを行う (3) WinMerge 日本語版 xdocdiff WinMerge Plugin -Word、Excel、PowerPoint、pdfの比較・差分を見る- TortoiseHgで差分表示ツールにWinMergeを指定し、xdocdiff WinMerge Pluginを入れると、Word、Excel、PowerPoint、pdfをテキスト化した後に比較・差分表示してくれる。 このおかげで、TortoiseSVNと同様に、分散バージョン管理ツールTortoiseHgでも、ExcelやWordの仕様書の差分比較ができる。 実に素晴らしい。 最近思うの
プロジェクトファシリテーションはIT企業の中間管理職研修みたいだ - プログラマの思索
随分前だが7月初めにPFP関西WS#19が開かれた。 ワークショップの内容は「ファシグラ」。 【1】ファシグラはファシリテーショングラフィックの略語で、議論の見える化を目的として、A4用紙又は模造紙へプロッキーを使って議論を描いていく手法。 ワークショップでは西河さんの解説がとても分かりやすく、実際に描きながら試すことができた。 議論の内容を議事録にまとめたり、内容をまとめて更に議論を深彫りしていくのは難しい。 議論が白熱すると、あらぬ方向へ議論が行って本来の問題解決につながらなかったりする。 アイデアを出しながら企画を組み立てようにも、アイデアがなかなか出ない雰囲気だったり、アイデアが散発的でつながりが見えにくかったりする。 そんな時にファシグラはすごく有用だ。 僕が改めてファシグラの威力を感じたのは、えと～さんが実際にファシグラを使っている場面を見た時だ。 ミーティングで到達すべきゴー
プログラマの思索: CIツールHudsonを使いこなす
XPのプラクティスの一つが常時統合(CI・Continuous Integration)。 別名、デイリービルドと言われる。 第2世代CIツールと言われるHudsonを使って運用して、常時統合の概念について改めて書く。 #Hudsonの全機能はまだ使いこなせてないので念のため。 【1】バージョン管理(SCM)＋常時統合(CI)＋テスト駆動開発(TDD)で、初めてアジャイル開発が可能になる 【元ネタ】 バージョン管理と常時結合 豆蔵：継続的インテグレーション（CI）をしましょう Subversionでbranches/tags/trunkでソース管理したら、次に行うべき環境構築はビルド環境。 Javaなら、Ant/Mavenでワンクリックでビルドできるようにスクリプトを作る。 今でもビルドする時に、Eclipseから手作業でビルドしているプロジェクトもままある。 ローカルマシンで手作業でビル
TestLinkのテスト実績からメトリクス出力 - プログラマの思索
TestLinkに溜まったテスト実績を下記ツールで分析してみたら、面白い傾向に色々気付いた。 以下メモ書き。 【EXCEL試験書からのXMLファイル変換マクロ】 v37b_TestLinkCnvMacro.tar.gz ダウンロード - TestLinkTools - SourceForge.JP 【主な機能】 (中略) ６ テスト結果の統計データのエクスポート ・指定された期間のビルド単位の試験結果の推移をグラフ化できます。 ・試験者を指定した試験結果の推移をグラフ化できます。 ・試験結果の累計数は、各テストケースでの最後に実施した結果の累計数です。 ７ 要件カバレッジのエクスポート ・プロジェクト内の全要件のカバレッジを、EXCELシートに取込めます。 ・要件カバレッジは、指定されたビルドの各テストケースでの最後に実施した結果より求めています。 ・要件カバレッジは、要件にアサインされて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
