ノウハウは縦横の軸で管理する - rabbit2goのブログ
Tracには「wiki」しかなかったのに、Redmineでは他に「フォーラム」なる仕組みも用意されていてややこしい。目的に応じて使い分けよ、とは確かに一つのアドバイスだとは思うけど、初めて使う人にそんなことを言っても通じないだろう。そんな訳である程度の指針や具体例が必要になるわけだが、今のところ、次のように使い分けている。 フォーラム 一度掲載したら変更しない文書用。具体的には、メールの共有保管場所だ。一度送ったメールはもう2度と変わらない（変えようが無い）し、スレッドごとにまとめて掲載できるので、後からの参照も容易だ。これで、チーム内に「情報共有」と称した無駄なメールの展開を減らせるようになる。 Wiki 何度も情報を更新する文書用に使っている。具体的には、チーム内の作業手順や障害の発生例と対策事例、ツールの手順や仕様書の類だ。これは一度書いたら終わりというものでも無いし、その履歴が実は
チームのためにナンバー2を育てよ - rabbit2goのブログ
開発の現場では毎日様々な問題が発生するし、対外的な打合せや非定型業務、割り込み作業も多くて、リーダと言えども、開発チームの進捗状況を必ずしも全て把握出来ているとは限らない。自分が逐次作業指示を出してメンバを動かすのが仕事とはいえ、指示を受けないと自ら動いてくれないという人はいるし、各作業間の優先順位付けや方針を決めるのはやっぱりリーダの判断に基づくものだから、どうしても自分の存在が不可欠になってしまう。 そんな時に考えるのが「自分がもう一人欲しい」という願望だったりする。決して2倍の仕事量をこなしたいという意味ではないのだけど、自分自身の仕事を進めつつも、チームの面倒を見ることが出来るのなら、それは有り難いことだ。何と言っても判断するのはあくまでも自分自身だから、期待通りの結果に導くのは容易なはずだ。他人任せにしたばかりに、予期せぬ結果になってしまったという悲惨な状況を避けられるのはかなり
仕様変更を言い出すのは誰か？ - rabbit2goのブログ
ソフトウェア開発時の仕様変更は頭が痛い問題だ。限られた時間とリソースの中で開発を進めているのに、仕様変更に伴う追加作業は「既存工程の中で吸収する」なんて言う、いかにも日本人的な対処を余儀なくされることが多い。工程が延びても、コードを書き上げテストを行って動作確認までした成果物に再び手を入れなければならないという精神的なダメージも大きいと思う。 「お客さんの要望だから仕方ない」という理由は分かるし、「仕様変更しなければ製品が売れない」という理屈も納得できる。それは正論だ。しかし、だからと言って、何度も仕様変更を続けて、開発現場に負荷をかけるやり方が正しいとは到底思えないような気がする。モノには限度というものがあり、それを越えた仕様変更は然るべき理由と共に拒否するのが当然ではないかと思う。 そんな度重なる仕様変更に腹を立てて、仕様変更の要求が来る度にTracのチケットを起票したことがある。記載
負の連鎖を断ち切れない開発者 - rabbit2goのブログ
ソフトウェアの開発現場では、正しいことばかりではなくて、正しくないことも何故か平気で行われている。行われているどころか、問題を指摘する人がいないと、あたかもそれが正しいかの如く脈々と受け継がれていたりする。その一例。 正しくないAPIの使い方を続けている そのような使い方をしている開発者に理由を聞くと、「もともとそのような使い方をしている箇所が有ったので真似をした」とのこと。その更に元の開発者をSubversionの履歴で調べていくと、実はもう既に退職した人だったりする。 開発プロセスが形骸化している 仕様書レビューやコードレビューがまともに行われない。リーダに理由を聞くと「忙しいから」「この案件は急ぐから」とのこと。でも、いつも同じ返事が返ってくるし、それを見聞きしているメンバもそんなリーダを見習ってしまうので、悪しき慣習は決して途切れない。 同じ問題を繰り返し発生させている 興味深いも
私家版テスト駆動開発 - rabbit2goのブログ
テスト駆動開発(TDD)をやってみたいけど最初の一歩がなかなか踏み出せないという人が少なくないようだ。あまり形式張らずに出来るところから少しずつでも挑んでいくのがコツだと思うのだけど、教科書に出てくる「正しいやり方」に躊躇してしまうケースがあるらしい。そんな訳で、今回は我流のテスト駆動開発方法を紹介してみたい。 テスト戦略を決める 制限のある開発期間内に効率的にテストコードを作る必要がある以上、何を目標として何処までをテストすべきか目標を決めておくことは欠かせない。もちろん、カバレッジ100%のコード作成は望ましいものの、異常系を含めてそこまでの網羅率を実現するのは難しいことが多いし、GUI処理は時間をかけてマクロを作るより人間が目視で確認した方が手っ取り早かったりする。費用対効果を考えて、もっとも効果の大きい箇所を重点的にテストコードでカバーすることを考えたい。 テストコードは後付け 由
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
