GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Vikas Hazrati , 翻訳者 吉田 英人 投稿日 2009年9月28日
スプリント計画にストーリーポイントと作業時間のどちらを用いるかについて,決着の付かない議論が長く続いている。どちらの陣営も,自分たちのアプローチが相手より優れているとする根拠をいくつも持っているようなのだ。Mike Cohn 氏が ユーザストーリーをタスクに分割して,それを元に時間見積を行う方法を好んで使用すれば,それに対して Jeff Sutherland 氏が 氏自身が関わった最高のチームでストーリーポイントを使ってバーンダウンを行った例をあげる。他にも多くのアジャイリストたちが,自らの好む方法とその理由について意見を表明している。
Mike Cohn 氏はスプリント計画でストーリーポイントを使用することを好んでいない。ストーリーポイントがどちらかと言えば長期的な測定基準であって,短期作業には向かないと考えているからだ。彼の意見では,
シーズン中盤のバスケットボールチームを想定してみましょう。チームはこれまで41試合で平均98得点をあげています。彼らが「今シーズンの残りゲームでも平均98点は得点できるだろう。」と思うのは適当かも知れません。でもある試合の前に「僕らの平均得点は98点だから,今夜も98点取れるさ。」と考えるのは間違っています。これが作業速度は長期的な予測因子としては使えるが,短期的な予測には不向きである,と私が考える理由です。
Tara Lee Whitaker 氏はこの意見に反対で,ストーリーポイントを短期的な測定方法であると考えている。彼女によれば,
個々のストーリーが‘正確に’見積するのに十分に小さく,かつテスト確認書を作成できるだけのテスト性を持っているならば,それをより小さな部品にブレークダウンしたり,時間単位で再度見積を行ったりしても,大した利益は得られないでしょう。
しかし,ストーリーを時間で見積ることに関して大きな懸念を持っている点では,意見が一致していて,
時間でバーンダウンするアイデアについて私たちが最初に議論したとき,私が心配に思ったことが主に2つあります。ひとつはバーンダウンが示す早期警告サインを利用できなくなるのではないか,という点,もうひとつは問題に気づくのが遅れたときに,あるストーリーが予想より多く時間を費やしたこと以外何も発見できないのではないか,という点です。
Jim Schiel 氏はストーリーポイントと時間の両方でスプリント計画を行うことは可能かも知れないと考えている。しかし時間単位での見積への投資に対する見返りは,それを重要な実行候補にするほど高くはない。彼の意見では,
2ストーリーポイントからなる PBI(Product Backlog Item) を10個処理する Scrum チームを考えてみましょう。作業がすべて完了すれば,彼らはスプリントあたり 20 ストーリーポイントの作業速度を達成したことになります。彼らは次のスプリントでも 20 ストーリーポイントを目指すでしょう。けれどもそのスプリント中に何かが起きて,多少大きくなったり小さくなったりするかも知れません。このようなことがスプリントごとに繰り返されて,チームの作業速度の平均は18~22あたりになるでしょう。時間見積でこれと同じことができるでしょうか? 答えはYESです。しかしそれを実現するには相当な費用が必要になるはずです。完成して動作するソフトウェアと非常に正確な見積,あなたならどちらにお金を払いたいと思いますか?
Jack Milunsky 氏もストーリーポイントの重要性を主張して,次のような利点をあげている。
Tomas Björkholm 氏はストーリーポイント方式を推進する理由として次のものをあげた。
さらに加えて,
Pomodoro Technique に関するスピーチで Staffan Nöteberg 氏は,多くの人々が見積を実時間で算出することを不快に感じていると語っています。私だってそうです。不快な気持ちの人の生産性は低いから,人日での見積もりは非生産的なのです。
Mike Cohn 氏はストーリーポイントと時間数の間に線形相関関係がないことを指摘している。氏によれば,各ストーリーごとに標準偏差の倍数を基本とした分布範囲があるという。
1ポイントは x の平均と標準偏差の倍数の分布に等価です。当然2ポイントのストーリーにもこれが当てはまりますし,それ以降も同じです。
そのために,ストーリーポイントで計測された作業速度が既知であったとしても,チームが仕事を完了する日を特定してステークホルダーに告げることはできない。範囲が必要なのだ。
ここで範囲と呼ぶのは,「プロダクトバックログのすべての項目を完了することができます。ただし完了するのは5月か6月頃でしょう。」というような日付範囲の場合もあれば,「ご希望どおり5月20日に完了します。それまでにプロダクトバックログのここからここまでにあたる,120~140の範囲内のどこかの数のストーリーポイントを獲得できるでしょう。」というスコープ範囲の場合もあります。
Mike Cohn 氏はまた,ある意味リーン主義の一種である comminent-driven sprint planning (責任駆動スプリント計画) とでも呼ぶべき別の手法を提唱もしている。このアプローチでは,チームはストーリーポイントや作業速度については議論しない。彼らは単にバックログタスクから高い優先度の項目を取り出し,彼らの生産能力ごとに時間で見積る。それから自身の責任を果たすのだ。
このようにスプリント計画については,どちらの技法にも賛否両論がある。結局はチームが納得できる方法に落ち着くことになりそうだ。あなたの好みはどちらだろう,そしてその理由は?
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
【ネクストスケープ】.NET、C#のアプリケーション開発者募集
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信