チケット駆動開発のFAQ - プログラマの思索
チケット駆動開発についてのFAQをまとめてみた。 他に聞きたい質問があれば、コメントして下さい。 チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) TiDD：チケット駆動開発: ソフトウェアさかば RedmineとTracの機能比較: プログラマの思索 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 Tracのワークフロー: プログラマの思索 ワークフロー機能のカスタマイズ方法 - かおるんダイアリー そろそろTracのワークフローについて語っておくか - almost nearly dead チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索
チームビルディング～現場リーダーの必須技術 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
TestLinkの運用例 - プログラマの思索
TestLinkの運用例を見つけたのでメモ。 【元ネタ】 TestLink使用レポート ― ありえるえりあ 記事から類推すると、かなりのテストケース数でテストしているのではないかと思われる。 下記にまとめてみた。 【従来】 ・テキストベースでテストケースを管理していたから、把握しにくい。 ・毎日メールでテスターから進捗を連絡してもらったが、進捗管理しにくい ・不具合が発生した場合のワークフローが曖昧 ・テストケースそのものが読みづらい 【TestLink運用後】 ・テストスイートごとにテストケースの数を表示してくれるので、テストの範囲や工数を把握しやすい。 ・テスト計画やテスターの単位で進捗率を表示してくれるので、進捗が分かりやすい ・テスト実行画面からケースを絞り込んでテストできる。 ・テスト結果画面から、不具合一覧を見れる ・テストケースが単体で存在し、文章に色や下線、箇条書きなどで装
XDDPと言う派生開発 - プログラマの思索
初めて、XDDPと言う派生開発の提唱者である清水さんの話を聞いた。 本は2冊読んでいたけれど、自分の理解が不十分だったことに気付いた。 以下、メモ書き。 【1】XDDPの最大の特徴は、SW開発の殆どは機能追加という保守開発である、という認識を前提としたアジャイルっぽい開発スタイルにある。 ソースからリバースエンジニアリングで要求仕様書を作り、ソースをダラダラと修正するのではなく、一気に修正してしまう。 駄目なプロジェクトでは、ソースに手を入れては修正漏れが出て、それを直してはまたバグが出る、といった症状が多い。 影響範囲や修正方法を確実に見極めれずに、ソースに手を入れてどんどん劣化させてしまう最悪なパターン。 清水さんのフレーズで面白いと思ったのは「移植作業は、ソフトウェアでも拒否反応を起こす」という内容。 人体でも、風邪を引いた場合、抗生剤を飲む。 しかし、抗生剤は人によっては免疫機能が
チケット駆動開発の運用例part2 - プログラマの思索
八朔さんによるチケット駆動開発の運用例をメモ。 【元ネタ】 チケット駆動開発 - Live a meaningful Life プロジェクトの作業をWBSの観点で、要件→成果物→作業のツリー構造へ分解している。 プロマネらしく、チケットの構造が上手だと思う。 このやり方ならば、ソース←【チケット(作業)】→【チケット(要件)】の観点で追跡可能だ。 【チケット(要件)】で集計すれば、顧客向けの進捗報告として、進捗率や工数を集計できる。 アジャイル開発の観点では、要件はストーリーカード、成果物や作業はタスクカードに割り当てられると思う。 顧客の観点でシステムの価値を表すのがストーリーカードであり、チケット駆動開発における成果物は、開発者の観点で捕らえるべきだろうと思う。 そうでなければ、開発者が作業するレベルにならないからだ。 後で、八朔さんに聞いたら、要件のチケットから実際のテストケースへ落
チケット駆動開発はツールによる改善か、プロセスによる改善なのか - プログラマの思索
チケット駆動開発を実践してプロジェクトが大きく改善された事実を話して、一番気になる質問がある。 「チケット駆動開発を運用したプロジェクトはツールで改善されたのですか？ それともプロセスで改善したのですか？」 質問の意図は、チケット駆動開発の話を聞くとBTSやらバージョン管理やらツールの使い方の話が多い。 そのプロセス改善はツールに依存しすぎではないか？ ツール無しの開発プロセスにできるのか？ チケット駆動開発は、BTSがなければ運用できないのか？ と。 この質問は今の僕が抱える問題点の一つを持っている。 それについては後でまとめる。 【1】チケット駆動開発の定義の一つは、BTSチケットをXPのタスクカードのように使うことだ。 すなわち、障害だけでなく要望なども取り扱う。 この方法は、Issue Trackingとも呼ばれている。 つまり、障害修正のワークフローをSW開発における全ての作業の
プロジェクト管理やテスト工程をクラウド化する - プログラマの思索
Hudsonの下記記事を読んだ感想をメモ書き。 【元ネタ】 Hudson Selenium PluginでHudsonクラスタをSelenium Gridに - 川口耕介の日記 近年、HadoopやSeleniumなど、複数のサーバ上で動作する事が前提のツールが増えてきており、マルチコア化・クラウド絡みで、このトレンドは今後も続くと予想されます。 ところが、こういったツールはセットアップと運用保守に手間がかかるという欠点があります。 Hudsonで僕がやろうと思っている事の一つは、Hudsonのクラスタ上にこういったツールをインストールするのを簡単にすることです。 Hudsonのクラスタはインストールがとても簡単ですし、プラグインのインストールも容易なので、この環境の上に他のツールをオーバーレイすることで、手間なく様々なツールを利用できるようになります。 「ThoughtWorksアンソロ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
