RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
Subversionを見直せ - プログラマの思索
SW構成管理の概念の中心は、バージョン管理。 バージョン管理こそが我々SW開発に従事する者にとって、背骨であり血液に当たる最重要なインフラ。 デスマーチに陥るプロジェクトは、バージョン管理に何かしらの欠点や弱点がある。 おそらく殆どのSW開発では、Subversionをバージョン管理に使っているが、Subversionは実は数多くの機能を持ち、従来のプロジェクト管理を根本的に変える可能性を秘めている。 もう一度、Subversionの機能を見直してみた。 【1】ムービー企画「Subversionによるバージョン管理入門」 WEB+DB PRESS Vol.39誌面連動ムービー｜gihyo.jp … 技術評論社 最近のバージョン管理は、trunkとbranchの2系統のバージョン管理戦略を持つ傾向がある。 メインラインモデルと呼ばれる。 メインラインモデルの手法を使って、本番運用中の保守br
プログラマの思索
「世界一流エンジニアの思考法」を読んでみた。 気づきをラフなメモ書き。 【1】試行錯誤は悪であること。 本番障害の原因調査でも、手当たり次第、ログから調べて探すのは生産性が悪い。 事実から仮説を1つずつ立てて、その仮説を1つずつ検証して可能性を潰していく。 試行錯誤が良くない理由は、後で得られる経験知がないからだ。 やみくもにモグラ叩きのように潰して、ああ終わったというだけ。 障害解決した一つの経験が後で活用できない。 事実から推測して、起きそうな仮説を複数パターンで立ててみる。 そこから1つずつ潰していくことで、自分のロジックを検証していることにもなる。 どこに原因があったのか、後で振り返るときにも役立つ。 すぐに手を動かさない。まず仮説を立ててアプローチを選択して一つずつ動かす。 分かっていれば当たり前なのだろうが、納期に迫られて焦っているときほど忘れやすい気はする。 【2】コードリー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
