チェックリスト信仰 - rabbit2goのブログ
開発現場で問題の再発防止策を検討すると、その結論として出てくるものの一つにチェックリストが有る。曰く、このチェックリストに従って確認を行えば、同じような問題の発生を防ぐことができるし、誰でも同じレベルで作業を行うことが出来る。チェックリストは素晴らしい、是非ともチェックリストを作るべきだ、チェックリストに従わないのはけしからん等々。 確かにその指摘は正しくで、実施すべき有力な対策の一つではある。優秀な開発者が自分の作業を終えて、万が一のミスが無いか確認する程度の使い方なら充分に有効だと思う。しかし、チェックリストの有効性を信じて疑わない人の姿を見ると、ちょっと待って欲しいと言いたくなってしまう。現場の人なら既に知っているように、チェックリストは同時に問題も多い存在だ。例えば、開発現場でこんな状態を見かけることは少なくないだろう。 確認作業の形骸化 「チェックリストで確認する目的は？」と聞か
チケット駆動開発を導入しても変わらないこと - rabbit2goのブログ
Tracのようなツールを導入してチケット駆動開発を始めた人から必ず聞かれる質問の1つに、下記のようなものがある。 「チケットの数が多くて管理出来ません。やっぱりチケット駆動開発は無理です」 確かに、やること、やらねばならない事を片っ端からピックアップしてチケットへ放り込んでいくと、小さなプロジェクトでもあっという間にチケットの山が出来てしまう。沢山のチケットが並んでいるレポート画面を見るだけでも嫌になるし、ウンザリした気分にさせられるのは確かだから、このような拒否反応を示すのだろう。 でも、良く考えてみれば、これは少々変な話しだ。チケットで表現されている内容は、本質的にチケット駆動開発とは何ら関係の無く、従来からプロジェクトの中には存在していはずだ。今までの作業の中で、例えばWBSのような形でタスクの管理を行って来たのであれば、チケットは単にその形が変わっただけのものだから、チケットの数は
Amazon EC2でBitNamiのTracを利用する - rabbit2goのブログ
Amazon EC2のAMIリストを見ていたらTrac導入済みのものを見つけた。最近は単なるLAMPだけではなく、目的に応じてTracやRedmineがインストール済みのAMIがいろいろ公開されているらしい。このAMIはBitNamiが提供しているもので、UbuntuにTracが既に導入済みとのこと。AMIなので直ぐさま利用可能な状態にあるわけだ。 Trac Cloud Hosting, Trac Installer, Docker Container and VM http://aws.amazon.com/articles/Community/4382 試しに利用料金が最も安いMicro Instance*1を選んで起動させてみた。 Announcing Micro Instances for Amazon EC2 Tracのバージョンは0.12。プロジェクトリスト画面は "http:
私家版テスト駆動開発 - rabbit2goのブログ
テスト駆動開発(TDD)をやってみたいけど最初の一歩がなかなか踏み出せないという人が少なくないようだ。あまり形式張らずに出来るところから少しずつでも挑んでいくのがコツだと思うのだけど、教科書に出てくる「正しいやり方」に躊躇してしまうケースがあるらしい。そんな訳で、今回は我流のテスト駆動開発方法を紹介してみたい。 テスト戦略を決める 制限のある開発期間内に効率的にテストコードを作る必要がある以上、何を目標として何処までをテストすべきか目標を決めておくことは欠かせない。もちろん、カバレッジ100%のコード作成は望ましいものの、異常系を含めてそこまでの網羅率を実現するのは難しいことが多いし、GUI処理は時間をかけてマクロを作るより人間が目視で確認した方が手っ取り早かったりする。費用対効果を考えて、もっとも効果の大きい箇所を重点的にテストコードでカバーすることを考えたい。 テストコードは後付け 由
やっぱりベテランは使えない - rabbit2goのブログ
ソフトウェア開発の現場にいるベテランには、他の人の手本となるような達人もいるけれど、その一方で見習ってはいけない悪い見本の人も少なからずいる。その一例。 開発資料を作らない 「ソースコードを読めば分かる」「資料を書くのは労力の無駄」と豪語して資料を何も作らない。後からフォローする人は、そもそも何をやっているコードなのか？などコードの設計思想や背景を読み取れないので苦労する。 自分の立場を分かっていない 開発チームを良い方向へ導くとか、若手の指導を行うという積極的な態度に欠ける。チームへの協力的な姿勢が無く、組織のあり方とか、ビジネスの方向性といった視点を持っていない。 知識を共有しない 「自分の持っている知識は大したことない」と謙遜するそぶりを見せながらも、自分からは決して情報発信を行わない。他人の情報には文句を付けるのに、自分からは何も出そうとしない。 新しい技術に挑戦しない 歳をとって
開発プロジェクトの教材としてTracを使ってみた - rabbit2goのブログ
新人君が配属されたので、ソフトウェア開発現場でどのような形で作業を行っているのか説明するために、昨年の開発プロジェクトで実際に使用したTracを使ってみた。普通はプロジェクト完了報告書などの資料を参照するのかも知れないけれど、これはあくまでも結果論なので、開発当時の雰囲気などがなかなか分かりにくい。代わりに仕様書の山や打合せの議事録を見せても断片情報でしかないので、それらが相互にどう結びついているのか、これも理解しにくい。 今回、Tracを使ったのは、これらの情報が時系列で記載されており、しかも互いにリンクされているので相互関係が明確になっているからだ。例えば「一つの障害（チケット）を発端にして、打合せを行って方針の検討を行い（議事録）、ソースコードの修正を行った（コミットログ）」という一連の流れを辿ることが容易で、非常に分かりやすい。仕様書や障害管理と言った縦割りな情報も必要だけど、この
Trac0.12の便利な機能 - rabbit2goのブログ
前回はTrac 0.12の更新を行ったので、今回は新しい機能を紹介してみたい。メジャーバージョンアップなので新機能が多数含まれている。詳細は本家の情報を参照してもらうとして、ここではユーザーにとって嬉しい改善点をピックアップしてみた。 Highlights Translation of Trac in your language, using Babel. Multiple Repository Support per environment Improved Wiki, more powerful syntax and nicer user interface with automatic preview in side-by-side editing mode Improved Ticket user interface, with editable comments and auto
開発プロジェクトの見える化 - rabbit2goのブログ
様々な開発プロジェクトを横断的に見ていると、情報共有という面で大きく2つに分類されるようだ。 プロジェクトに自信が有るところは「情報を見せる」 プロジェクトの進捗、問題等が一目で分かるようにTrac等で公開されている。 Trac等を参照することにより、現時点の状況がすぐに分かる。 プロジェクトの状況について、担当者全員が同じ認識を持っている。 資料や情報の在処が明確にまとめられているので、あちこちを探し回る必要がない。 事前の情報共有が出来ているので、打合せでも本題に関する議論が直ちに始まる。 プロジェクトに自信が無いところは「情報を隠す」 プロジェクト管理は誰かのメモか頭の中で行われており、部外者には全く分からない。 手作業で進捗をまとめているので、現時点の状況が分かるのは次の日だったりする。 プロジェクトの状況について、各担当者間で認識が異なる。 資料や情報の在処が不明確。各担当者が自
求ム、障害分析アナリスト - rabbit2goのブログ
終了した開発プロジェクトの問題分析を行っている。「バグの源流をたどれ」の如く、なぜなぜ分析で問題の根本原因を探り、抜本対策案をまとめるのが目的だ。さすがに限られた時間内で全障害を検証するのは不可能なので、優先度の高い問題のみをピックアップしてから分析を行う。Tracのチケットに記載された情報を元に、仕様書の記載ミスなら変更前後の仕様書を見比べ、コーディングミスなら該当するコミット状況を確認し、テスト漏れならテスト手順書の記載を検証するといった感じだ。 開発対象も開発者も異なるプロジェクトを見ているけれど、いずれの開発でも共通の傾向があるので面白い。 障害は偏在する 全ての障害が一様に分布するのではなく、特定の機能、開発者、モジュール等に著しく偏って発生することが多い。パレートの法則ほどではないけれど、その偏り方は目に見えてはっきりと分かる程だ。 類似の障害は繰り返し発生する 一つのプロジェ
品質を考える読書〜「技術にも品質がある」 - rabbit2goのブログ
モノ作りの品質というと、どうしても製造現場にフォーカスしたもの（品質管理）が多いけど、この本は開発現場での品質（品質工学）を取り上げている。品質工学を毛嫌いする人は少なくなく、知名度や普及度は今ひとつのような感じがする。でも、この本に難しい理屈は無く、品質工学の基本的な考え方やその必要性が平易な言葉で説明されており、初心者でも容易に読み進められるはずだ。 TQM活動は、生産分野から始まり経営分野へと広がりを見せているが、技術開発分野への展開はまだ不十分である。それは、技術そのものに対する理解がボトルネックになっているからである。品質工学は、そのボトルネックを克服し、品質を根本から改善するためのツールの一つである。どのような視点から技術を理解すべきか、製品をどう設計すべきかを追求する方法である。 実績データを活用して信頼性を予測する信頼性工学とは異なり、品質工学は、実績データが存在しない場合
勉強会に参加しない理由は？ - rabbit2goのブログ
社内で勉強会を開催。どういうわけか、出席者の顔ぶれはいつも決まっているように思う。もちろん、内容に当たり外れがあるのは仕方ないけど、勉強会を10回やって1度も出てこないのは何か特別な理由があるのではないだろうか。聞いてみたことは無いけれど、勉強会に参加しない人の気持ちはどのようなものなのだろうかと勝手に想像してみた。 自分の仕事には関係ないと思っている（思いこんでいる）。 新しい技術に興味がない。 目先の仕事に忙しくて他のことに関わる余裕がない。 自分の利益に結びつかないことには関わりたくない。 内容のレベルが高すぎて理解できない。 内容のレベルが低すぎて面白くない。 既に熟知している内容なので、今さら聞くまでもない。 こんな奴の話なんか聞きたくない。 さて、本当のところはどれでしょう？
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
