BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ Value & Metrics に関するすべてのコンテンツ

  • #NoEstimatesを使って価値を提供する

    Vasco Duarte氏は#NoEstimatesを学び、予算内で価値を提供するのに役立てる方法を探すのが良い、という。氏は#NoEstimatesについての本を書き、見積もりがなぜうまくいかないのか、#NoEstimatesを使ってどのようにプロジェクトを管理するのかを説明している。

  • 見積もりなしの意思決定戦略

    Debbie Madden氏とVasco Duarte氏が見積もらないことに関する意見を述べている。

  • スライシング・ヒューリスティックによるサイクルタイムの経験則的測定

    見積を使用しない(NoEstimates)アジャイルチームは,スライシング・ヒューリスティックを使うことによって,実作業に先立って経験則的にサイクルタイムを計測し,作業量予想に役立てることができる。

  • チームの改善のためにベロシティを計測することへの懸念

    アジャイルチームは自分たちのスプリントごとのベロシティを��測する。そうすることで彼らは、計画をたて、進捗をトラッキングし、プロダクトオーナーにプロダクトのリリースプランを作るための手がかりを与えることができるようになる。チームは、自らを改善したいときに、ベロシティのデータを利用できるのだろうか? 何人かの著者がベロシティについて書いており、チームの生産性を高めることを目的としてベロシティを計測することについての懸念を伝えている。

  • アジャイルチームが正しい方向にスタートするのを助ける「Scrum Kickoff Planner」

    「Scrum Kickoff Planner」がAdam Weisbart氏によってリリースされた。このガイドの目的は、新しいアジャイチームやプロジェクトを始めるときに、重要なポイントに関するチームのディスカッションをうまくファシリテートすることだ。

  • VelocityによってAgileは死んでしまうのか?

    チームによって完遂され、完遂するまでにかかった時間で分割される仕事の尺度であるVelocityは、チームの生産性を管理するためやチーム間の比較の尺度として用いられるようになっている。Jim Highsmith氏、Mark Levison氏、そしてScott Ambler氏は生産性の尺度としてのVelocityの間違った使い方に関して議論する。

  • Agile採用を計測するときの疑問

    Agileコミュニティは、組織におけるAgile採用の効果を計測するためのベストな方法を決定するために、数年にわたりいくつもの試みをしている。最近の記事で、最も便利なメトリックについて議論が再燃している。

  • ベロシティにバグ修正を入れるべきか?...に依る。

    過去、バグ修正をベロシティに加えるべきか多くの議論や論争があった。「1つの」正しい答えは、なさそうである。しかしアジャイラには、どのような状況でバグ修正を追加すべきか、どのように追加すべきか、どこで追加しなくてよいかを提案している人達がいる。

  • アーンドバリュー (Earned Value) はアジャイルメソッドを活用できるか

    アーンドバリュー・マネージメント(EVM) の価値と,それをアジャイルに統合することに関して,激しい議論が巻き起こっている。アジャイルが EVM を必要とするほど大規模な IT プロジェクトに進出し始めたことがその原因だ。意見はさまざまだが,単にアジャイルが EVM に適用可能であるというだけではなく,アジャイルを適用した EVM がそうでないものより優れている,という考えもある。

  • 繰り返しタスクはアジャイルの臭い?

    ストーリーを水平方向のタスクに分割することは「アジャイルの臭い」か?これはスクラム/アジャイル計画会議によく見られ、チームの顧客価値へのフォーカスを損なう悪習なのか?代わりに提案されているのはどんなことなのか?

  • よいアジャイルなメトリクスとは何か?

    適切でアジャイルな計測とは何だろうか?もし伝統的な計測方法である、アーンドバリュー、労働時間、コード行数、テストによるコードカバレッジがアジャイルなプロジェクトにはあまり適さないのであれば、どういう方法があるのだろうか?よりよいアジャイルなメトリクスを選ぶ上で助けとなる、私たちが決められるルールは何だろうか?

  • デマルコ、ソフトウエアエンジニアリングの40年間を振り返る

    NATOのソフトウエアエンジニアリング会議から40年経ち、トム・デマルコはソフトウエアエンジニアリングの信念の進化において、自身が支持したメトリクス指向の方法論が、"変革を起こすこと。世界を変えるソフトウエアを作ること。"を目的にする現実の開発現場では、本当は邪魔になっていたのではないかと、振り返った。それとも、彼の当初の助言はやはり有効なのだろうか。彼自身は、"有効ではなかった"と、Software Engineering誌の"時代はやって来て、そして過ぎ去ってしまったのか"と題した記事で書いている。

  • 価値とベロシティ、そしてバリューベロシティの比較

    多くのアジャイルチームでは'価値'とチームの'ベロシティ'は正比例すると、暗黙的に前提している。幾つかのケースにおいては本当にそう見られる。しかしながら、多くの場合はチームのベロシティが本当に価値を提供できたかはほとんど示されない。

  • アジャイルが「チームの5つの機能障害」に取り組む

    ITマネージメント・ソリューションの大手プロバイダにおける部長である、Tathagat Varma氏は、アジャイルの生産性改善がチームワークの改善に繋がるのではないか、と思った。彼は、アジャイルの価値と実践をPatrick Lencioniのビジネス物語「チームの5つの機能障害」と対比させて、分析している。

  • アジャイルの生産性をドルで測る

    以前Scott Ambler氏は、加速度を利用してアジャイルチームの生産性を測る方法に関する記事を投稿した。最近、彼は引き続き別の記事を投稿したが、そこではアジャイルの生産性と加速度に関係のある、いくつかのよくある質問(FAQ)に答えている。

BT