TortoiseHgはSVNクライアントとしても優秀 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
チケット駆動開発にPSPの概念を持ち込む - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
チケットの親子関係が持つ意味 - プログラマの思索
さかばさんのBlogを読んで考えたことをメモ。 【元ネタ】 [TiDD] RedmineのWBS: ソフトウェアさかば プロジェクトの初期にタスク洗い出しとして作られるWBSは普通、5階層までが良いと言われている。 WBSの階層が深いと管理しにくいが、階層化しなければ、タスクの見通しが悪い。 Ver0.8までのRedmineでは 「プロジェクト－サブプロジェクト－バージョン－チケット」 の構造を持つので、4階層になるようにWBSを作ればいい。 しかし、実際はもっと深く作りたい時もあるから、その場合は階層を省略するなど無理するしか無かった。 Ver0.9では、プロジェクトの階層が無制限へ機能改善されたので、 「プロジェクト－サブプロジェクト1－サブプロジェクト2－バージョン－チケット」 のように、5階層のWBSを簡単に作ることができる。 ここで、さかばさんの指摘のように、下記のように対応付け
Sonarでソースの品質をチェックする - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Redmine on JRuby part2 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
TiDDを実践して気付いたことpart7～繰り返し開発を制する者はSW開発を制す - プログラマの思索
先日、S-OpenでRUPで有名なクールシュテン博士によるアジャイル開発の講演があった。 Agile開発は大規模プロジェクトでは難しい、アーキテクチャを重視するプロジェクトでは難しい、などの話を聞いて、そんな話は昔から聞いていた、と正直聞き飽きた。 そんな違和感を感じながらも、チケット駆動開発を実践して、アジャイル開発の難しさが何となく分かってきた気がする。 考えたことをメモ。 【元ネタ】 TiDDを実践して気付いたことpart6～TiDDでAgile開発を実践して分かってきたこと: プログラマの思索 TiDDを実践して気づいたことpart4～TestLinkによるテスト戦略: プログラマの思索 以前書いたように、Agile開発が難しい理由は、その最大の特徴である「超短期間の繰り返し開発」を実現するハードルが高いことにある。 その内容は次の3つに言い換えられる。 １・繰り返し開発はイテレー
Redmineのプラグインが充実している - プログラマの思索
昨年に比べると、Redmineのプラグインがすごく充実している。 いろいろ試してみてメモ。 【コードレビュー】 r-labs - Code Review - Redmine Redmineリポジトリ画面からコードレビューのチケットを発行できる。 UIも使いやすいし、チケットでレビュープロセスを管理できるから、ReviewBoardでわざわざコードレビューしなくても良い気がしてきた。 それぐらい素晴らしいプラグイン。 【Hudson】 r-labs - Hudson - Redmine RedmineからHudsonと連携できる。 以前は、Redmine - PluginSimpleCI - RedmineでしかCIツールと連携できなかったが、このプラグインの方がはるかに高機能。 Hudsonを使っているなら、このプラグインは必須。 このプラグインのおかげで、ビルド管理をチケット駆動開発に含
チケット単位に並行開発する事例 - プログラマの思索
分散バージョン管理Git、Mercurialを絡めたチケット駆動開発で、興味深い事例があったのでメモ。 【事例1】 gitだからこそできるチケット駆動開発のやり方 - kunitの日記 今やっている方法は、作業するなら作業用のブランチを切れ！それにはチケット番号を付けろ！という方式にしている。 たとえば会員管理の機能に追加したい場合は以下のような手順になる。 1. 会員管理を拡張したいなぁ 2. じゃRedmineでチケットを切るぞ 3. チケット番号が振られた(たとえば #567 だとする) 4. さぁ、ブランチ切るか(members_567) 5. そのブランチで作業開始！ 濱野さんがWEB+DBでも入門Gitでもかかれている「トピックブランチ」というものの良さが本当に現れてくる。 【事例2】 Mercurialを使った俺々バージョン管理ノウハウまとめ(2009年夏編) - 文殊堂 t
TestLinkの要件管理機能 - プログラマの思索
TestLinkの要件管理機能についてメモ。 【元ネタ】 要件のテスト - watawata日記 TestLinkの可能性: プログラマの思索 要求管理(要件管理)ツール RaQuest 要求管理ツールRaQuest・要求項目の作成 要求管理ツールRaQuest・ツリーと一覧を駆使した要求項目の効率的な管理 要求管理ツールRaQuest・要求の追跡 TestLinkの機能とV字モデルの関係 (Testlinkjp-users) - TestLink日本語化 - SourceForge.JP テスト管理ツールTestLinkには不十分だが、要件管理機能が付いている。 TestLinkCnvMacroを使えば、TestLink要件をTestLinkキーワードを経由して、TestLinkテストケースとN対Nの関係に持ち込むことができる。 この紐づけによって、要件カバレッジが可能になり、キーワード
チケット駆動開発のベストプラクティスを収集したい - プログラマの思索
チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。 理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。 僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。 但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。 １・チケット・ファースト(Ticket First) 【説明】 基本は、プロジェクトの作業はチケットを受け取ってから始める。 チケット無しで作業はしない。 また、SVNコミット時に、チケット無しのコミットも不可。 【効用】 チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。 進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアル
TestLinkの運用例part2 - プログラマの思索
allpair法をTestLinkに使う方法が書かれた記事があったのでメモ。 【元ネタ】 TestLinkメモ - 科学と非科学の迷宮 AllPair法で作成したテストケースをTestLinkにテストケースとして読み込むツールallpairs2testcase.rb - Rubyの魔神 - はてな？Rubyグループ allpair法は、組み合わせテストのテストケース作成技法の一つで、同じ値のペアが最低1回現れるように組み合わせてテストケースを作成する方法。 直交表に比べると、テストケース数を少なくできる。 実際のテストケース作成時は、複数の入力項目の組合せテストが非常に多い。 例えば、組込製品やパッケージ製品ならば、ドライバやOSのバージョンを組み合わせたテストケースを作っているだろう。 業務システムならば、業務のパターンや状態を組み合わせてテストケースを作りこんでいるだろう。 実際の現場
チケット駆動開発のFAQ - プログラマの思索
チケット駆動開発についてのFAQをまとめてみた。 他に聞きたい質問があれば、コメントして下さい。 チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) TiDD：チケット駆動開発: ソフトウェアさかば RedmineとTracの機能比較: プログラマの思索 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 Tracのワークフロー: プログラマの思索 ワークフロー機能のカスタマイズ方法 - かおるんダイアリー そろそろTracのワークフローについて語っておくか - almost nearly dead チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索
TestLinkを運用して気付いたことpart6～テスト工程のプロジェクト管理 - プログラマの思索
TestLinkでテストケースを作りこんで、テストしていくと、色んなことに気付く。 TestLinkでテストしていきながら感じたことをメモ。 【1】ウォーターフォール型開発では、下流工程にテストが来る。 単体テスト、結合テスト、システムテスト(総合テスト)、受入テストの違いをきちんと使い分けているだろうか？ テストは基本的に、V字モデルの左側の工程の検証作業になる。 単体テストは開発工程の検証だが、結合テストの違いは何だろうか？ 単体テストは、最低限動作することを保証すること。 Exceptionが発生するようでは話にならない。 ホワイトボックステストで、最低限、分岐網羅(C1)を検証する。 だから、コードカバレッジが非常に重要になる。 結合テストは、複数のモジュール同士を結合して動作するのを検証する。 普通のプロジェクトでは、結合テストで火を噴くことが多い。 理由は、結合テストになって初
TestLinkを運用して気付いたことpart10～テストの制約条件 - プログラマの思索
TEF関西のNakaさんの話を聞いて考えたことをメモ。 【元ネタ】 ソフトウェアテスト標準用語集 日本語版Ver 1.3 普通のプロジェクトは結合テストで火を噴く。 理由は、結合テストで初めて、システムが稼動するのを顧客も開発者も見れるから。 そこで、初めて、要件漏れ、認識相違、仕様漏れに気付く。 でも、それだけの理由だけではないという指摘を受けた。 ソフトウェアテスト標準用語集 日本語版Ver 1.3には「プロダクトリスク」「プロジェクトリスク」の用語解説がある。 プロダクトリスクとは、「テスト対象に直接関係するリスク」。 プロジェクトリスクとは、「（テスト）プロジェクトの管理（マネジメント）と制御（コントロ－ル）に関係するリスク。例えば、スタッフの不足、厳しい締め切り、変更管理などがこれに当たる。」 実際のテスト、特に結合テスト、システムテスト、受入テストのようにプロジェクト後半になる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
