求ム、障害分析アナリスト - rabbit2goのブログ
終了した開発プロジェクトの問題分析を行っている。「バグの源流をたどれ」の如く、なぜなぜ分析で問題の根本原因を探り、抜本対策案をまとめるのが目的だ。さすがに限られた時間内で全障害を検証するのは不可能なので、優先度の高い問題のみをピックアップしてから分析を行う。Tracのチケットに記載された情報を元に、仕様書の記載ミスなら変更前後の仕様書を見比べ、コーディングミスなら該当するコミット状況を確認し、テスト漏れならテスト手順書の記載を検証するといった感じだ。 開発対象も開発者も異なるプロジェクトを見ているけれど、いずれの開発でも共通の傾向があるので面白い。 障害は偏在する 全ての障害が一様に分布するのではなく、特定の機能、開発者、モジュール等に著しく偏って発生することが多い。パレートの法則ほどではないけれど、その偏り方は目に見えてはっきりと分かる程だ。 類似の障害は繰り返し発生する 一つのプロジェ
学ぶ方法をどうやって学ぶか？ - rabbit2goのブログ
その昔、社会人になって間もない頃、会社で机に向かってビジネス誌を読んでいる人がいた。自己啓発のためか、その雑誌を読むことがビジネスマンの常識なのかと思いつつ、なぜその雑誌を読むのか目的を聞いてみたところ、こんな答えが返ってきた。 この会社にいるとバカになる一方だから、バカにならないために読んでいる。 世間知らずだった当時は、そんな回答が返ってくるなんて想定外だったのでビックリ仰天したけれど、その言わんとしていることを実感できたのはずっと後になってからのことだった。もちろん、その時にはもう彼は会社を辞めており、社内に残っていたのはそんなビジネス誌なんか読まず、世間の動向にも疎い人たちばかりだったように思う。 考えて見れば、会社の仕事を続けていく上で何が必要であり、その知識はどのように学ぶべきなのか、と言った点については誰からもはっきり教わったことは無い感じがする。周りの人の様子を観察しながら
チケット駆動開発を導入しても変わらないこと - rabbit2goのブログ
Tracのようなツールを導入してチケット駆動開発を始めた人から必ず聞かれる質問の1つに、下記のようなものがある。 「チケットの数が多くて管理出来ません。やっぱりチケット駆動開発は無理です」 確かに、やること、やらねばならない事を片っ端からピックアップしてチケットへ放り込んでいくと、小さなプロジェクトでもあっという間にチケットの山が出来てしまう。沢山のチケットが並んでいるレポート画面を見るだけでも嫌になるし、ウンザリした気分にさせられるのは確かだから、このような拒否反応を示すのだろう。 でも、良く考えてみれば、これは少々変な話しだ。チケットで表現されている内容は、本質的にチケット駆動開発とは何ら関係の無く、従来からプロジェクトの中には存在していはずだ。今までの作業の中で、例えばWBSのような形でタスクの管理を行って来たのであれば、チケットは単にその形が変わっただけのものだから、チケットの数は
どの開発者に投資するのが効果的なのか？ - rabbit2goのブログ
先週のJaSST'11 Tokyoの最後のパネルディスカッションにて、正社員と派遣社員のどちらを教育すべきか？という意味の議論があった。有益な情報を社内に持ち帰ってきて横展開してくれれば誰でも良いと言う意見が出て、これはこれで正論なので特に反対意見は無く、では誰がその投資対象になるのか、具体的に言えばJaSSTのようなセミナーに行くのが望ましいのか？という話になるのだが、その時にこんな意見が出た。 自己研鑽に励んでいる人を会社としても応援すべきだ。 これはなかなか微妙な議論だと思う。JaSSTのようなセミナーに来ている人は目的意識の高い人たちばかりだから、このような主張に頷くことが多いようだ。確かに、何の問題意識も無い人より、色々考えてセミナー会場から多くの情報を持ち帰ってきてくれる人をセミナーに送り込んだ方が、会社としての費用対効果は高いだろう。 しかしながら、組織というものは複数の人間
私家版テスト駆動開発 - rabbit2goのブログ
テスト駆動開発(TDD)をやってみたいけど最初の一歩がなかなか踏み出せないという人が少なくないようだ。あまり形式張らずに出来るところから少しずつでも挑んでいくのがコツだと思うのだけど、教科書に出てくる「正しいやり方」に躊躇してしまうケースがあるらしい。そんな訳で、今回は我流のテスト駆動開発方法を紹介してみたい。 テスト戦略を決める 制限のある開発期間内に効率的にテストコードを作る必要がある以上、何を目標として何処までをテストすべきか目標を決めておくことは欠かせない。もちろん、カバレッジ100%のコード作成は望ましいものの、異常系を含めてそこまでの網羅率を実現するのは難しいことが多いし、GUI処理は時間をかけてマクロを作るより人間が目視で確認した方が手っ取り早かったりする。費用対効果を考えて、もっとも効果の大きい箇所を重点的にテストコードでカバーすることを考えたい。 テストコードは後付け 由
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
