WF型開発にとらわれすぎたTiDDのアンチパターン #tidd - プログラマの思索
チケット駆動開発を運用してみて、悪いWF型開発のアンチパターンを頻繁に見かける。 考えたことをメモ。 【1】WF型開発がうまくいっているプロジェクトは、手戻り作業をできるだけ減らすように、前工程の品質チェックに力を入れる。 過去の経験値が生きる場合、いわゆるフロントローディングのやり方は有効に作用する。 しかし、僕はWF型の開発スタイルで上手くいった経験はあまりない。 ソフトウェア開発では、技術革新のスピードが早いため、過去の経験値が有効に作用せず、試行錯誤する回数がとても多い。 WF型開発が前提とする手戻り作業を減らす手法は、あまりにも綺麗過ぎる。 試行錯誤やリスクをあまりにも恐れている気がする。 Redmine・Trac・Mantisでチケット駆動開発をやってみると、リリースに至るまでの作業はいつも初めての問題にぶつかって試行錯誤して、どのイテレーションでも同じようにはならない。 チケ
Redmineを活用するためのtips - Qiita
一人で案件を回すことになったため、RedmineとGitHub周りの機能を試しながら使い倒して気づいたことのメモ。（他のプロジェクトであまりRedmineが活用されていなくて、ただひとりのヘビーユーザになってしまった...） 1.バージョンを切ろう どんな仕事にも〆切があるはず。なくても暫定の〆切をつくって、そこまでの作業をバージョンして区切れば、そのときまでやるべきことがはっきりする。 2.タスクが見えたらチケット化しよう 作業・タスクはどんどんチケットにする。やるべきこと、やったことが見える化される。見える化されてないものがたくさんあると、何で時間がかかっているのか、問題があるのかわからなくなってしまう。 3. チケットに担当者を割り当てる どのタスクが、誰がボールを握っているのかをはっきりする。野球の「お見合い」みたいなことでタスクをとりこぼすことを防げる。個々人の負荷や進捗率も見え
決めておいた方が良いRedmine運用ルール - Qiita
これまでWeb・DTP制作／システム開発の両方で日常的にRedmineを使用してきた中で生まれたプラクティスをまとめます。 「いやそれは違う」という箇所もあるかもしれないので、もし指摘があればコメントをお願いします! 基本方針 情報の集約度を高める ガチガチの設定を沢山定義するのではなく、シンプルな設定で柔軟に運用する アクセス解析を入れる チケットが増えてくるとRedmineは重くなります。この重さを改善するために色々な施策が必要になるタイミングがいつかやってきますが、サーバの応答速度などのデータがないと改善策がどれくらいの効果だったのかが分かりません。 ほかにも色々な測定ができるので、とりあえず入れておいて困ることはないでしょう。Google Analyticsの導入はプラグインで簡単に可能です。 チャットサービスとの連携を考える Redmineの欠点の1つは、チャットなどでのリアルタ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
講演１ Redmine導入のアンチパターン
