Mercurialによるチケット駆動開発は強力だ！ - プログラマの思索
Mercurialを使ったチケット駆動開発の記事が非常に素晴らしいのでメモ。 このやり方を使いこなせれば、ソフトウェア開発の生産性は劇的に上がると思う。 【元ネタ】 mercurialでチケット駆動開発 - ろじぼ 上記の記事を理解できた範囲でまとめてみた。 【仮定】 ・SCMはMercurial。(Gitでも良い) ・BTSチケットでSW開発のタスクを管理する。 ・trunk、confirmブランチは中央リポジトリ(サーバー)にある。 ・チケットブランチ(トピックブランチ)は、ローカルとサーバーの2箇所にある。 常時同期されている。 ・作業の優先順位によって、チケットがリリース順≠開発順の状況はある。 【チケットAブランチ上の作業手順】 1・チケット担当時に、ブランチ作成。【チケットのステータス＝担当】 ↓ 2・チケットAブランチ上でガンガン開発する。【チケットのステータス＝担当】 →t
変更管理の基盤は構成管理が支えている - プログラマの思索
SW開発には、たくさんの落とし穴や地雷がある。 地雷原を走り抜けてゴールにたどり着くまでに慎重に進むと、時間切れになる。 アジャイル開発をRedmine上で実践して気付いたことは、変更管理プロセスを制御できるかどうかという観点がプロジェクト管理の殆どを占めていることだ。 仕様変更、タスクの優先度など、SW開発は路線変更が多く、それを制御するのが難しい。 顧客と合意した要件で開発してリリースしても、その後に膨大な改善要望がくる時すらある。 以下メモ書き。 【1】顧客要求を安易に受けてしまう人の良いSE－ ＠IT自分戦略研究所 スコープのずれがコスト増にすぐにつながる。 アジャイル開発の肝はスコープ管理だ。 スコープ、コスト、納期の3つのバランスのうち、スコープでしか調整しづらいのがSW開発の最大の特徴。 スコープ管理の一例としては、CCBなどの変更管理会議で変更管理プロセスを制御することがあ
ソフトウェア構成管理に至るまでの道のり - プログラマの思索
「何故、設計書をバージョン管理するのか？」という疑問から、ソフトウェア構成管理について考え直してみる。 ＃あくまでもメモ書き。 【元ネタ】 ■[development][trac]構成管理ツールをいかにして導入するか ■[システム開発][構成管理]構成管理ツールはどのようなタイミングで導入し、どのように活用すべきなのだろうか？ ■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理 ソフトウェア構成管理 【1】バージョン管理が無かった頃 今でも多いが、WordやExcelの設計書をバージョン管理していないプロジェクトは多い。 その時の最大の問題点は、■[構成管理]Subversion + TortoiseSVN + xdocdiffでドキュメント管理 にその理由が書かれている。 ほっておくと自然増殖してくるのが、下記のような形式のドキュメント
BTSを構成管理ツールとして使う - プログラマの思索
チケット駆動開発の戦略part1として、BTSを構成管理ツールとして使うアイデアをメモ。 #走り書きは後でまとめる。 元ネタは、下記の記事。 チケット駆動開発 ITpro Challenge のライトニングトーク Tracの最大の利点はSubversionとの連携にあり 【1】トレーサビリティ Redmineのチケット管理をずっと続けると、要件からソースコードまでのトレーサビリティをすごく意識する。 実際の運用は下記になっている。 要件・仕様書・テスト仕様書のリンク、説明書き、作業履歴 ←→チケット ←→SVNリビジョン 何度も思うことは、本番リリース後のシステム開発は、リアルタイムに保守されない仕様書よりも、バグ有りで動くプログラムが正しいことだ。 しかも、お客も、バグありの機能を知った上の運用フローを組んでいる。 設計者は、XPのように、動くプログラムを正として、プログラムから機能仕様
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
