タグ

ブックマーク / forza.cocolog-nifty.com (14)

  • Redmine運用例 - プログラマの思索

    Redmineの運用例をリンクしておく。 一つは、Ruby1.9の開発。 もう一つは、SKIP(RailsSNS)。 【SKIP】 SKIP ... 情報共有ソーシャルウェア SKIP - 概要 - SKIP - Redmine SKIP - ロードマップ - SKIP - Redmine SKIP - 変更記録 - Redmine SKIP - サマリ - Redmine SKIP - 経過時間 - レポート - SKIP - Redmine Redmineで最も重要な画面は、サマリの画面だ。 そこからバージョン項目の右にある虫眼鏡をクリックすると、ステータスごとのチケット集計数が表示される。 SKIP - サマリ(バージョン単位) - Redmine 面白いと思うのは「実装完了」というステータスがあることだ。 他のチケットの状態遷移の履歴を見ると、下記のフローが正常フローのように見え

    Redmine運用例 - プログラマの思索
    hagayu
    hagayu 2009/03/02
    Redmineの運用例へのリンク。Ruby1.9やSKIP(Rails製SNS)。
  • 【公開】XP祭り関西2009講演資料「チケットファーストでアジャイル開発!~チケットに分割して統治せよ」 - プログラマの思索

    【公開】XP祭り関西2009講演資料「チケットファーストでアジャイル開発!~チケットに分割して統治せよ」 XP祭り関西2009講演資料「チケットファーストでアジャイル開発!~チケットに分割して統治せよ」を公開します。 CC Attribution ライセンスとします。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) プログラマの思索: 【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」 まちゅさんはTracのチケット管理を元に「チケット駆動開発(Ticket Driven Development)」を提唱された。 僕は、Redmineによるプロジェクト運営でプロジェクト管理が劇的に改善した経験を昨年のKOFで話してみた。 KOF講演後、興味を持

    【公開】XP祭り関西2009講演資料「チケットファーストでアジャイル開発!~チケットに分割して統治せよ」 - プログラマの思索
    hagayu
    hagayu 2009/02/21
    XP祭り関西2009講演資料「チケットファーストでアジャイル開発!~チケットに分割して統治せよ」
  • Hudsonの使い道 - プログラマの思索

    Hudsonの面白い使い道についてメモ。 【1】Trac Lighting付属のHudsonをCI以外の目的で使ってみる - almost nearly dead HudsonをWindows上でバッチ処理として定期実行するやり方。 上記では、Tracのバックアップに使っている。 Unix上ならcronで行うやり方もあるが、Hudsonの利点は、GUI上で複雑な設定や管理ができること。 バッチ処理はCobol時代から存在するアーキテクチャだから、Hudsonをビルド以外にバッチ処理として使うやり方は、非常に興味深い。 更に興味を持つのは、検索エンジンHyperEstraier用のIndex作成処理にHudsonを使っていること。 昨今、SVNにソースだけでなくExcelやWordの仕様書もバージョン管理しているため、HyperEstraierでそれらをWeb検索できるなら、要件管理や設計工

    Hudsonの使い道 - プログラマの思索
    hagayu
    hagayu 2009/02/15
    Hudsonをバッチ処理として定期実行する方法。SVNコミットしたタイミングでHudsonをビルドさせる設定方法。Hudsonで分散ビルドするための方法。
  • アジャイルごっこ - プログラマの思索

    アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」で指摘した「アジャイルごっこ」についてメモ書き。 【元ネタ】 続・書評アジャイルな見積りと計画づくり』 - TECH-moratorium : テクモラトリアム DeclineAndFallOfAgile - アジャイルの衰退と凋落 【1】「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」の訳者あとがきに、こんな一節がある。 XPを代表とするアジャイル開発の技術的プラクティスは、開発現場の日々の作業を明らかに改善してくれる。 しかし、その効果はいずれ限界が来る。 結局、プロジェクトのスコープとスケジュールが固定されている状況では、最終的に開発者に様々なしわ寄せが来る。 このように、開発者だけがアジャイルなプラクティスを導入している状況を、木下さん(レビューワー)は「アジャイルごっこ」

    アジャイルごっこ - プログラマの思索
    hagayu
    hagayu 2009/02/14
    「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」での「アジャイルごっこ」という指摘についての考察。
  • プログラマの思索: TestLinkの可能性

    「塹壕よりScrumとXP」の「15.1. 多分受け入れテストフェーズは回避できない」を読んで、TestLinkを受入テストで使うアイデアをメモ。 以下メモ書き。 【元ネタ】 塹壕よりScrumとXP(日語訳PDF) 第1回:テスト設計の必勝テクニック:ITpro TestLinkJP - TEF有志によるテスト管理システムTestLink日語化プロジェクト 【1】TestLinkをSW開発のどの工程で使うべきか? TestLinkは受入テスト(あるいは結合テスト以降のテスト)で使う。 XPが生み出したテスト駆動開発によって、プログラムは単体テスト品質をクリアするようになった。 継続的インテグレーションによって、コミットしたコードラインは常時リリース可能になった。 しかし、それらのプラクティスだけで、開発したらすぐに顧客へ納品可能か? 答えはNo。 受入テストをクリアしなければ、納品可

    プログラマの思索: TestLinkの可能性
    hagayu
    hagayu 2009/02/10
    TestLinkを受入テストで使うアイデア
  • 複雑度と単体テストケース数の相関関係 - プログラマの思索

    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 on JRuby - プログラマの思索

    小川 明彦, 阪井 誠 : チケット駆動開発 日のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初のアジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

    Redmine on JRuby - プログラマの思索
  • TortoiseSVNからBTSと連携する - プログラマの思索

    小川 明彦, 阪井 誠 : チケット駆動開発 日のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初のアジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

    TortoiseSVNからBTSと連携する - プログラマの思索
  • Redmineインストールメモ - プログラマの思索

    Redmineのインストールや設定に関するメモ。 【1】Passengerをインストールすると、RailsをApache単独で稼動できる。 http://redmine.jp/tech_note/apache-passenger/ gem install passenger passenger-install-apache2-module 後は、httpd.confの設定だけすればいい。 Passengerの利点は、RailsPerlPHPと同じ感覚で運用できることだ。 今後のビジネスを考えると、RailsJRubyで動かすか、Apacheで動かすか、どちらかが重要になるだろう。 要注目の技術だと思う。 【2】Wikiを使うには、下記を実行。 gem install RedCloth 但し、活動欄に表示されるチケット内容は、Wikiのシンタックスがそのまま表示されてしまう。 【3】日

    Redmineインストールメモ - プログラマの思索
  • チケット駆動開発の本質はバージョン・ファースト - プログラマの思索

    チケット駆動開発(TiDD)について考えていることを書く。 ※注意:チケット駆動開発(Ticket Driven Develpment)の略語は、「TDD」だとテスト駆動開発(Test Driven Develpment)と間違えやすいので、「TiDD」と以降呼ぶことにする。(命名者:えと~さん) 【元ネタ】 チケット駆動開発は、まちゅさんによって提唱されている。 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) 【1】チケット駆動開発のプラクティス チケット駆動開発は定義そのものがあやふやなのだが、僕は下記4個ののプラクティスがあると思う。 ※注意・下記のプラクティスはあくまでも僕個人の考えであることを断っておく。 【1-1】チケット・ファースト(Ticket First) プロジェクト内部の作業は、チケットを受け取ってから始まる。 つまり、工数が発生す

    チケット駆動開発の本質はバージョン・ファースト - プログラマの思索
    hagayu
    hagayu 2008/12/18
  • TestLinkを運用して気付いたこと - プログラマの思索

    TestLinkをテスト仕様書代わりに運用し始めて、メーリングリストで使い方を聞いたり、自分で色々試してみた。 色んな気付きがあったのでメモ。 【1】数千、数万のテストケースをTestLinkへインポートするには、下記のExcelマクロでXML出力して、TestLinkのXMLインポート機能を使う。 このツールのおかげで、既存のテスト仕様書からTestLinkへテストケースをコンバートするのが非常に簡単になった。 TestLinkCnvMacro TestLinkへテストケースを全てインポートして一番驚いたのは、わずか数人のプロジェクトですら、テストケースが1千ケースを越えていることだ。 但し、ここでのテストケースは単体テスト、結合テストのどちらも含んでいる。 今の感触では、20人月規模のプロジェクトならば、TestLinkへインポートするテストケース数は1万ケースを越えるだろう。 つまり

    TestLinkを運用して気付いたこと - プログラマの思索
  • 【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」 - プログラマの思索

    関西Ruby会議01@関西-KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」を公開します。 CC Attribution ライセンスとします。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) チケット駆動開発は、まちゅさんが最初に提唱された。 しかし、チケット駆動開発の概念はまだ曖昧で、一部でしか注目されていない。 僕は、Redmineというプロジェクト管理機能を持つBTSがプロジェクト管理をIT化してくれて、プロジェクト運営が大きく変わったことを経験した。 その体験をチケット駆動開発(Ticket Driven Development)という概念へ昇華できないか、考えた内容が上記の資料です。 コメントがあれば嬉しいです。 【参考】 Rubyist

    【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する~チケットに分割して統治せよ」 - プログラマの思索
  • プログラマの思索: RedmineがExcelよりも素晴らしい点

    Redmineの使い方は下記を見よ。 http://www.redmine.org/projects/show/redmine 【1】以下、Redmineを使った感想を書いてみる。 1-0.ガントチャートがリアルタイムに表示される。 こいつに一番感動した。 プロジェクトリーダーは、ガントチャート保守に、彼の作業時間の殆どを費やす。 その理由は、プロジェクトのリスクがガントチャートでしか把握できないからだろう。 考えてみれば、作業の開始日と終了日、作業状態さえ入力すれば、リアルタイムにガントチャートは計算できるはず。 殆どのITプロジェクトガントチャートは、手作業でかなりの時間を浪費して作っているか、MSProjectのように保守しても理解しにくいか、どちらかだ。 ソフトウェア開発のプロジェクト管理で最もIT化されていない部分と言える。 1-1.SVNリポジトリとチケットが相互リンクできる

    プログラマの思索: RedmineがExcelよりも素晴らしい点
  • Excelのプロジェクト管理から脱却せよ~SW構成管理を見直そう - プログラマの思索

    RedmineやTestLink、Hudsonなどのツールは一体何を改善して、何を目指しているのか? 一言で回答するならば、これらのツールはいわゆるSW構成管理をIT化するツールなのだ、と考えればよい。 つまり、下記のイメージだ。 Excelで進捗管理していた →Redmineプロジェクト管理をIT化 ソースや仕様書を履歴共有できる仕組みが無くファイルを日付管理していた →Subversionで共同所有 Excelでテスト仕様書を管理していた →TestLinkでテスト仕様書をWeb化 手作業でビルドしていた →Hudsonでビルドを自動化(継続的インテグレーション) 我々IT技術者は、お客様がExcelやAccessで運用している業務をIT化、Web化するのが主な仕事なのに、肝心の自分たちのプロジェクト管理の殆どは、Excelで運用して四苦八苦しているだろう。 日の殆どのSIerで働

    Excelのプロジェクト管理から脱却せよ~SW構成管理を見直そう - プログラマの思索
  • 1