タグ

ブックマーク / szk-takanori.hatenablog.com (6)

  • 品質管理・進捗管理に質問表を活用する - 現場のためのソフトウェア開発プロセス - たかのり日記

    「要件や仕様が正しく伝わっているか?」ということを把握するのは難しい、と感じます。 自分は当たり前に思っていても、相手はそうでない 打ち合わせで説明したつもりが、相手には意図した通り伝わっていなかった 仕様書はレビューしたけど、理解が違っていることに、受入になってから気付いた などなど、問題の事例を挙げたら、キリがないでしょう。 要件定義のやり方や、レビューのやり方で、ある程度は改善できるモノの、大抵の場合、問題に気付くのは試験や受入段階になってから。 それがプロジェクトの遅延や失敗に繋がることにもなります。 アジャイルなら、早期に問題に気付ける、というのはあるかもしれませんが、それでも手戻りが多ければ、イテレーションはうまく回らなくなるでしょう。 そのような状況に対し、質問表(Q&A表)を分析すると、プロジェクトの傾向が良く分かると感じ出しています。 現在、こんな感じで、質問表の分析を行

    品質管理・進捗管理に質問表を活用する - 現場のためのソフトウェア開発プロセス - たかのり日記
  • 品質を上げたいなら、「レビュー」よりも「検討会」に力を入れよ - 現場のためのソフトウェア開発プロセス - たかのり日記

    以前に、以下の記事を書きました。 進捗管理は「遅れ」か「残り」か これは、今までのやり方を少し変えるだけで、プロジェクトマネジメントの効果を向上させられる良い例でしょう。 ソフトウェア開発プロセスの中では、同様のことが言えるケースがたくさんあると思っていますが、私がこれまでに気付いたノウハウをまとめてみたいと思います。 今回は、まず、レビューについて。 レビューは、大抵のベンダー/SIerでは実施されていると思います。 レビューの目的は、上流工程における不具合の除去、要件の明確化などだと思いますが、なかなか効果が上がらないと感じている人は多いのではないでしょうか? レビューのやり方については、議論されることも多いですが、そもそもレビューだけで問題を解決しようというのに、無理があると感じています。 そのため、私は、設計工程の最初で「設計検討会」を行うようにしています。 これは、 要件は十分に

    品質を上げたいなら、「レビュー」よりも「検討会」に力を入れよ - 現場のためのソフトウェア開発プロセス - たかのり日記
  • 分散型バージョン管理システムは実際の開発現場でどれだけ普及するか? - 現場のためのソフトウェア開発プロセス - たかのり日記

    バージョン管理ツールは、「集中型」と「分散型」に分類できますが、OSSのバージョン管理ツールには以下のようなものがあります。 集中型 CVS、SVN 分散型 Git、Mecruial、Bazaar 最近は、分散型のツールへの注目が高くなってきていますが、「実際の開発の現場でも普及するか?」というと、あまり普及するとは思わない。 OSSの開発コミュニティなど、ある程度スキルが高い開発者が集まる開発では、ブランチ管理が簡単といった分散型の効果が活きてくると思うのですが、実案件の開発現場となると、残念ながら、必ずしもそのような開発者だけではない。 数人程度の小規模プロジェクトならまだしも、大規模プロジェクトになると、レベルもバラバラな人が集まることは必至です。 そのようなプロジェクトでは、できるだけブランチは避けた方が、間違いなく混乱が少ない。 少し前のマーチン・ファウラー氏の記事ですが、バージ

    分散型バージョン管理システムは実際の開発現場でどれだけ普及するか? - 現場のためのソフトウェア開発プロセス - たかのり日記
  • Javaコーディング規約 & Ecliseの設定ルールを公開 - 現場のためのソフトウェア開発プロセス - たかのり日記

    4/25(日)から仕事中国に出張に行っていたのですが、その間に、当社のJavaコーディング規約が公開されました。 このコーディング規約は、開発者自身の経験、および、最近のJavaの動向を踏まえ、 現場で当に役に立つノウハウをまとめたものです。 そのため、Eclipseで自動でフォーマットできるような簡単なスタイルの規約については 記述を省略し、より重要となるコーディングテクニックや考え方について記述しています。 Javaコーディング規約/WEBワークショップ Acroquest Technology 株式会社 コーディング規約を提示されても、内容が古いことが多い フォーマット的なルールは、Eclipseの設定ルールがあれば十分 という想いから、今回、私から社内に相談を持ちかけ、公開に至りました。 内容についても、単にコードの書き方のルールをまとめるだけでなく、 コーディングテクニックや

    Javaコーディング規約 & Ecliseの設定ルールを公開 - 現場のためのソフトウェア開発プロセス - たかのり日記
  • EclipseからWindowsエクスプローラーを開くプラグインの最新事情 - 現場のためのソフトウェア開発プロセス - たかのり日記

    Eclipseから、Windowsのエクスプローラーを開くプラグインは地味に便利。 以前は、以下の3つがありました。 Open External Eclipse Platform Extensions Easy Explorer 個人的には、コマンドプロンプトも開ける「Eclipse Platform Extensions」を使っていたのですが、Eclipse3.5になってから使えなくなってしまったので、乗り換えを検討。 しかしながら、 「Open External」はリンクが死んでおり、ダウンロードできず、 「Easy Explorer」は、更新サイトで公開されているモノはVer1.0.1までと古く、最新Ver1.0.4は、SourceForgeからダウンロードして、手動でインストールする必要があります。 そこで、最近のプラグインをいろいろ探してみたところ、他にもプラグインがありました。

  • OKを出せない品証やPMに価値はあるのか? - 現場のためのソフトウェア開発プロセス - たかのり日記

    問題点を指摘するだけで「どうすれば良いか」「どうなったら良いのか」、OKを出さない人の品質分析には価値がないと感じます。 それだけか、そのような人の指摘に応えるために、無駄に時間だけが取られるため、マイナスの効果と言えるかもしれません。 ここ数年、「なぜなぜ分析」「カイゼン」という言葉が流行ったせいか、その名の基に、形式的な指摘・分析を求める人が増えたような気がします。 具体的に言えば、OKを出さない人は、品質分析をした結果の文章だけしか見ず、その文章の内容にだけ指摘をします。 肝心の仕様書やソースコードは見ないのです。 その結果、当に品質を満たしているのか、という質的な議論にならず、文章の書き方だけの議論になってしまいがち。 これでは、意味がない。 「悪魔の証明」という言葉がありますが、バグがないことを証明するのは、不可能と言えます。 当然、品質を保証するために、バグがないこと(正確

    OKを出せない品証やPMに価値はあるのか? - 現場のためのソフトウェア開発プロセス - たかのり日記
  • 1