Redmineに複数SCMリポジトリ表示が必要な理由 - プログラマの思索
Redmineに複数SCMリポジトリを表示するパッチについてメモ。 【元ネタ】 Twitter / yusuke-kokubo: #redmine #redmine Multiple SCM per Projectの本体側へのマージに動き出した感じがする。JPLもrake testを追加してる。 Twitter / yusuke-kokubo: 社内Redmineをアップデートする過程でMultiple SCM per Projectも直さないといけなくなったので半泣きになりながらも頑張ってアップデートした。 Redmine - Feature #779: Multiple SCM per project - Redmine Redmineは元々、1プロジェクト1リポジトリの発想。 つまり、Redmineプロジェクトには、一つのSCMリポジトリからビルドされるリリースモジュールと1対1に対
【続】TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン - プログラマの思索
工程単位のBTSプロジェクトやBTSバージョンが何故よくないのか、再考してみた。 ラフなメモ書き。 【元ネタ】 TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン: プログラマの思索 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 Agile開発の肝はイテレーションにあり: プログラマの思索 頻繁なVerUpがソフトウェア開発の本質: プログラマの思索 【1】WF型開発に染まっているPMやPGは、どうしても工程単位にBTSプロジェクトを作ったり、BTSバージョンにアサインしたりする。 自分たちの開発スタイルが、滝の流れのように成果物を下流工程の人へ渡して、最終成果物を作っていくからだ。 例えば、設計プロジェクト、結合テストプロジェクト、本番障害プロジェクト。 機能Aの設計バージョン、機能Aの開発
TiDD初心者が陥りやすい罠part2～工程単位のRedmineプロジェクトやリリース予定バージョン - プログラマの思索
TiDD初心者が陥りやすいアンチパターンを更に見つけたのでメモ。 【参考】 バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 Agile開発の肝はイテレーションにあり: プログラマの思索 【1】WF型開発のプロマネとしてバリバリ腕を鳴らしている人がRedmineでタスク管理を運用していると、共通した特徴がある。 それは、工程単位にRedmineプロジェクトやRedmineバージョンを割り当てていること。 例えば、プロマネが1個のプロジェクトだけを抱えているなら、Redmineプロジェクトは1個だけだが、Redmineバージョンを設計、開発、テスト障害、本番障害のように工程単位にアサインしている。 大規模プロジェクトで、プロマネが複数チームをマネジメントしているなら、Redmineプロジェクトを課題、設計、開発、テスト障害、本番障害のように工程単位
段階リリースとアジャイルリリーストレイン - プログラマの思索
チケット駆動開発の肝の一つは、リリース予定バージョンとイテレーションを同一視する点にある。 イテレーションの扱い方がチケット駆動開発の重要な運用ノウハウの一つ。 大規模プロジェクトではイテレーションの扱い方に更に一工夫がいる。 考えたことをメモ。 【元ネタ】 開発プロセスの最適化手法 システムを小さく作って段階的にリリースすることが重要な理由 - 極北データモデリング 【1】小規模プロジェクトでチケット駆動開発を運用している場合、リリース予定バージョンがリリースモジュールのバージョンあるいは納品モジュールのバージョンに一致し、更にAgile開発のイテレーションと同一視できる。 だから、小刻みにリリースしながら機能も品質も拡張していく戦略が取りやすい。 小規模リリースを実際に運用するのはとても楽しい。 しかしながら、大規模プロジェクトになると、小規模リリースを実現するのが難しくなってくる。
チケットがプロジェクトを駆動する #tidd - プログラマの思索
さかばさんの記事を読んで、チケット駆動の意味を改めて考えさせられた。 以下メモ書き。 【元ネタ】 [#TiDD] チケット駆動開発がもたらすプロセス: ソフトウェアさかば [#TiDD] チケット駆動開発がもたらすプロセス その２: ソフトウェアさかば 僕の考えでは、アジャイル開発プロセスの基本は小規模リリースであり、その特徴が頻繁なリリースであり、そこにチケット駆動開発が当てはまると思っていた。 つまり、イテレーションありきでプロジェクトが開始すると思っていた。 その意味では、リリース計画駆動であり、本来のXPとは多分違ってくるのだろう。 さかばさんの指摘では、チケットでタスク管理を始めると、チケットに依存した開発スタイルから、チケットを中心とした開発スタイルに変わり、リアルタイムの見える化、スコープのコントロール、プロセス改善、頻繁なリリースが実現されるようになる、という流れ。 多分、
BTSを制する者がソフトウェア開発を制する - プログラマの思索
Redmine、Trac、Mantisを使ってみて、ソフトウェア開発はバグ管理が最も基本のプロセスだと改めて感じた。 「BTSを制する者がソフトウェア開発を制する」という気がする。 以下、BTSについて経験したこと、考えたことをロジカルでないメモ書き。 ウォーターフォール型開発でよくあるパターンは、要件定義、設計、開発、単体テストまで順調に進むが、結合テストでたくさんのバグが噴出して、初めて問題が現れる時が多い。 その時、障害管理のためにBTSを使って、見つけたバグを一つずつ潰していく。 アジャイル開発であろうとも、イテレーション期間中に見つけたバグは、BTSで管理しているだろう。 ソフトウェア開発では、障害管理のプロセスが重要な気がしている。 いくら設計しても、単体テストをやっても、ユーザの観点で動かさなければ、開発者も自分が作ったシステムの全貌を知ることはできない。 1回のリリースは1
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タグでリネームし
チケット駆動開発から発生したチームの変化 - プログラマの思索
さかばさんの記事とyusuke-kokuboさんのつぶやきを読んで思ったことをメモ。 【元ネタ】 [#TiDD] チケット駆動開発はプロジェクト成功の3C(Commitment、Communication、Collaboration)を実現する: ソフトウェアさかば Twitter / yusuke-kokubo: 社内Redmineのチケットに「後で振り返る？:Boolean」というカスタムフィールドを追加した。 僕もRedmine導入前は、Excelで課題管理、タスク管理をやっていたし、Excelのテスト仕様書でテストして、Excelで障害管理もやっていた。 プロジェクトをどう進めればよいか、は自分では見えていたけれど、制御するのは非常に難しかった。 Redmineでチケット駆動開発を運用し始めて、色んな事に気づいた。 単にAgile開発を初めて実際に運用できただけでない。 従来からや
イテレーションはSW開発で何故重要なのか？ - プログラマの思索
バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠が思いのほか評価されていたので、理由を再考してみる。 以下、ラフなメモ書き。 【元ネタ】 アジャイルはなぜ失敗するのか？～教科書には載っていない反復型開発の3つの掟（1/4）:企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ) バージョンのないRedmineプロジェクト～TiDD初心者が陥りやすい罠: プログラマの思索 チケット駆動開発の本質はバージョン・ファースト: プログラマの思索 牛尾さんが書いているように、イテレーションはAgile開発で最も特徴的な概念だ。 その発想はすぐに理解できるが、実際に実践してみると、そんなに簡単に運用できるものではない。 何故、イテレーションを実際のSW開発に運用するのが難しいのだろうか？ 僕の数少ない経験上、イテレーションを実際の開発プロセスに実装
ハードなプロセス、ソフトなプロセス - プログラマの思索
さかばさんの記事を読んで思ったことをラフなメモ書き。 【元ネタ】 [#TiDD] チケット駆動開発の開始タイミング - 良いプロダクトはふさわしいプロセスが生む -: ソフトウェアさかば システム開発から属人性を排除しようとして失敗する: プログラマの思索 さかばさんが書かれているように、製造業の会社から派生したSIはハードウェアの開発に憧れて、ソフトウェア工場によるソフトウェア開発の工業化を目指していたように思える。 属人化を廃し、信頼性重視の開発スタイル。 (前略) ソフトウェア開発の歴史を振り返ると、ソフトウェアはハードウェアの開発にあこがれていたと思います。各社が「ソフトウェア工場」を作り、ソフトウェア開発の工業化を目指していました。 工業化における品質とは主に信頼性です。計画された仕様が満たされたかどうか、設計どおりに実現されているか、それが求められます。当初定められた計画通りに
リリース履歴の重要性 - プログラマの思索
Redmineには、変更履歴と言うリリース履歴の機能がある。 この機能がいかに重要か、ラフなメモ書き。 【1】チケット駆動開発では、バージョンをリリースしたら、自然にリリース履歴が残る。 SVNコミットに必ずチケットをリンクさせれば、終了チケットがリリース履歴になる。 リリース履歴は何故重要か？ いつ何をリリースしたのか、という記録だから。 手作業でリリース履歴を作ろうとすると作業漏れがおきやすい。 RedmineのようなBTS、Hudsonのようなビルドツールを使っていないチームでは、リリース履歴を自動作成することができないので、リリース履歴をExcelのリリース台帳で管理しているだろう。 例えば、開発者が修正したソースにタグを付けてリリース台帳に記載して、ライブラリアンはリリース台帳を見てビルド＆デプロイを実施するワークフローにしているだろう。 このワークフローはExcelのリリース台
いつテストを終わらせるか？ - プログラマの思索
信頼度成長曲線の使い方について、フジハラさんのBlogによいリンクがあったのでメモ。 【元ネタ】 Redmine プラグイン開発 - テストレポートプラグイン開発中 - フジハラボ -- 目指せ！スーパーエンジニア どこでテストをやめるのか？ 日本電気株式会社 川村真弥さん オープンソースソフトウェアにおけるコードの 安定性予測に向けたゴンペルツ曲線の適用 成長曲線（ゴンペルツ曲線とロジスティック曲線） つれづれなる技術屋日記: バグカーブ 対数曲線や二次曲線での近似のお勧め テスト消化曲線とバグ発生曲線の7パターン診断 － ＠IT MONOist プログラムバグの成長曲線とプログラム品質の判定 テスト消化曲線とバグ発生曲線のパターン診断: プログラマの思索 信頼度成長曲線の使い道は、テストでソフトウェアの品質が歩溜りに達したかどうかを判定するのに使う。 つまり、テストの止め時は、信頼度成
現代のAgile開発が抱える課題 - プログラマの思索
チケット駆動開発でAgile開発を初めて実践できて、Agile開発の長所や短所が色々分かってきた気がする。 今の時代にAgile開発はとても優れていると思っているが、乗り越えるべき課題はまだまだある。 その課題も、時代の変化によって、より難しいレベルまで要求されているように思う。 2000年代に現れたXPを代表とするAgile開発は、その利点は広く知られてきたが、適用の限界や短所について従来から指摘され続けてきている。 その課題についてまとめてみる。 #考えたことをラフなメモ書き。書きかけもある。 【1】Agile開発はプロジェクト管理が弱い アジャイル開発でプロジェクト管理、そしてプロセスを管理する部分が弱いという指摘は従来から言われていた。 確かに、PMBOK、CMMIなどの観点から見れば、Agile開発はプログラミング重視で全体的なプロセス設計がなされていないように思える。 だが、S
チケット駆動開発のアンチパターン - プログラマの思索
チケット駆動開発のFAQ、プラクティス集以外にも、アンチパターンを考えてみた。 以下メモ書き。 【元ネタ】 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】チケットのアンチパターン 【1-1】乱発されたチケット よくある最悪なパターンは下記2ケースがあるだろう。 設計、開発、単体テストまでは穏便なものの、結合テストで火を噴き、たくさんのバグ報告があがる。 あるいは、リリース直後には、たくさんの障害報告や問合せが殺到する。 そのままチケットに登録すると、チケットが乱発される。 そして、それらのチケットを精査する工数が開発チームの許容量を超えると、チケットは放置される。 こういう状況はもはや、アジャイルだろうがTiDDだろうがCMMIだろうが、手に負える状況ではない。 【1-2】有効期限切れのチケット・放置されたチケット 終了予定日を過
レビュープロセスを効率化するには？ - プログラマの思索
ReviewBoardとコードレビューに関するメモ。 【元ネタ1】オンラインコードレビュー支援ツール「Review Boad」 これまで自分がやっていたソースコードのレビューは紙に印刷して、赤ペンでガリガリ書いていくというスタイルだったので、ちょっと目から鱗でした。そんな感じでコードレビューをやっていくと手間がかかる割には、使い終わった後はゴミ箱に捨てられていたりしたわけですが、これを使うとレビュー結果が蓄積されていくので便利ですよね。 そう考えると初等プログラミング教育用としても使うのも面白いのかなと思っています。先生をやっていて、その辺りが一番やりきれない部分だったので。。。。 昔も今もコードレビューする場合、大量の紙を印刷して、赤ペンでガリガリチェックするのが普通だろう。 パソコン上で差分表示しながらレビューしてもいいが、レビューコメントを残したりするのが面倒だから。 モニタでは目が
マネジメントのスピードが開発のスピードに直結する - プログラマの思索
倉貫さん(XPJUG代表)の記事を読んで、システム開発に関する洞察が優れている点についてメモ。 【元ネタ】 アジャイル開発のボトルネック - Social Change! (中略) つまり、発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。 これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。 アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないS
【公開】SQIP2009の論文資料 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
【公開】第4.5回Shibuya.trac発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」 - プログラマの思索
第4.5回Shibuya.trac に参加して発表してきた。 スタッフの皆さん、ありがとうございました。 その発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」をCC Attribution ライセンスで公開します。 今回の発表は、昨年のKOFで発表したRedmine＋TiDDから続く一連のチケット駆動開発のまとめになります。 SQIP2009では、大手SIの経営者や管理職が多いせいか、チケット駆動開発の発表はプロセス改善というよりもツールに依存した運用改善と捉えられがちで、あまり反響がなかった。 でも、第4.5回Shibuya.tracはまるでホームのような雰囲気で、聴衆はTrac使用者がRedmine使用者よりもやや多かったけれど、チケット駆動開発に興味のある人達ばかりだったので、熱く語ることができた。 関西から八朔さんや小枝さんも来てくれて心強かった。 最後のパ
チケット駆動開発を日本発のアジャイル開発へ発展させるには？ - プログラマの思索
さかばさんの記事を読んで考えたことをメモ。 【元ネタ】 [TiDD] 小規模開発の難しさを考える: ソフトウェアさかば チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) アジャイル開発は元来、小規模で変化の激しいプロジェクトが向いていると言われてきた。 しかし、XPが出現して10年も経つというのに、現場の実践例は非常に少ない。 ネット上でアジャイル開発の情報がこれだけ溢れていて、開発者も興味を持っているのに、事例になかなかお目にかからない。 情報処理試験の勉強でも、プロセス改善のセミナーでも、繰り返し型開発の重要性が叫ばれているのに、事例は非常に少ない。 その原因は、単純にアジャイル開発を実践できる技術力が足りないからだと思っている。 テスト駆動開発を実践するには、JUnitを使いこなさねばならない。 常時統合
TestLinkのFAQ - プログラマの思索
TestLinkを運用する時のFAQをまとめたみた。 TestLinkは癖があるために運用しにくいと思うので是非参考にして欲しい。 【元ネタ】 【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」: プログラマの思索 簡易マニュアル - TEF有志によるテスト管理システムTestLink日本語化プロジェクト 連載：きちんと学びたいテストエンジニアのためのTestLink入門｜gihyo.jp … 技術評論社 TestLinkCnvMacro 【テスト計画】 【1】TestLinkをインストールしましたが使いこなせません。TestLinkはSW開発のどの工程で運用すれば効果的ですか？ 【回答】 TestLinkを運用する場合、結合～受入テストで導入するのが良いでしょう。 TestLinkは手動のテストを管理するためのツールなので、自動化しやすい単体テストよりも、業
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
