You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
_ テストコードを作らない文化が浸透している現場へRuby/Railsが導入された結果への対策を考えてみる まず、導入された結果は以下のようになっております。信じられないものもありますが、事実です。 1. マージが頻繁に行われる開発中はNoMethodErrorや文法エラーが続出。必要なコードのマージ漏れまで発生 2. 修正の度に人力テストが必要となり、コスト増大 3. これまで以上に責任論が追求される現場となる 4. コスト増加を恐れるあまりリファクタリングはおろか、巨大な迂回処理やコピペが横行する 本プロジェクトには、以下のようなテストコードを作(らない|れない)様々な原因があります。 問題分類 現場への影響
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel! Redmineでアジャイル開発を楽々管理 - @IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く