▼ [Software]辞めていった人達が作ったシステムの保守を楽しいものにする はてなは「絶対すべきでないこと」をやらかしたのか？ nabokov7; rehash : ライブドアという会社の話をしよう - Q12. 次世代ブログサービス(になるはずだった) nowaの撤退をどうみた？(下) この辺りの話題を眺めていて思うところあったので少し書いてみる。 別にはてな社やライブドア社がどうだって話ではなくて、システムやソフトウェアを開発する仕事の話です。 まず、大前提として、 新しくスクラッチから書き起こす 既にある機能と互換性を保ちながら改修する プログラマにとっては、前者の方が圧倒的に楽しい仕事だと思ってます。（最近無くなったらしいけど）グーグル社の20%ルールは、開発者の創造性を巧く引き出せるよう上手に設計された制度です。 ただ、現実問題として、IT業界では後者の仕事を行う機会の方が
TiDD(チケット駆動開発)が何故、アジャイル開発と密接に関係するのか、経験を思い出して考えてみたことをメモ。 ＃下記はロジカルでないので注意。 【元ネタ】 裏プロセスは並行プロセス: プログラマの思索 チケット駆動開発のモチーフ: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 ツールが開発プロセスを改善する: プログラマの思索 【1】Redmineでチケット駆動開発を実践して、これがアジャイルだ！と気付いた瞬間は、イテレーションと言うリズムに気付いた時だ。 Redmineのロードマップ画面で、バージョン毎にチケットをアサインした後、バージョンの進捗率が100％になり次第、随時リリースしていった。 すると、開発メンバーはリリース予定のバージョンを直近のゴールと見なして、自然に頑張るようになった。 そして、リリース後にK
ここ数ヶ月の成果。やっぱり中心にはgitがある。 チケット駆動開発の良さはわかっていたが、なかなかうまくいかないなぁと思っていたが、gitをちゃんと使うようになってそれができるようになってきた。 チケット駆動開発を実践するにはまずはチケットをきらないといけない。けど、それができない。やっぱりいきなり手をつけちゃうんだよね。それってなんでそうなっちゃんだろうと常々思っていた。 それをある意味抑制するやり方。今やっている方法は、作業するなら作業用のブランチを切れ！それにはチケット番号を付けろ！という方式にしている。 たとえば会員管理の機能に追加したい場合は以下のような手順になる。 会員管理を拡張したいなぁ じゃRedmineでチケットを切るぞ チケット番号が振られた(たとえば #567 だとする) さぁ、ブランチ切るか(members_567) そのブランチで作業開始！ 濱野さんがWEB+DB
「Shibuya.trac第4.5回勉強会 〜チケット駆動開発とTestLinkによる開発プロセスの改善〜」に参加しました。 テーマ的に開発者というより管理側なのか、時々参加している開発者向けセミナーと違った雰囲気でした。 机の上に出ているPCは Thinkpad:Let's Note:Mac = 6:3:1 くらい。 Shibuya.trac を Redmine ユーザーが乗っ取りか！ …と思ったんですけど、そんな感じでもなかったです。 ここで発表の動画が見れます http://www.ustream.tv/recorded/2141591 Trac + SVN + Hudson + TestLink の活用事例／かおるん Hudson と TestLink は興味があったのですが、使ったことありませんでした。試しに使ってみようかと思いました。 Trac0.12の事と翻訳に関して、宣伝他
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
