BT

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

寄稿

Topics

地域を選ぶ

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

  • アジャイルにすべてを導入する

    2ヶ月前、InfoQはJim Shore氏の人気の記事を紹介した。それは、組織が「アジャイル」を名前だけで導入し、実際にアジャイルであるために本当に意味するものの導入に失敗するという、現在増えているコミュニティの傾向を強調するものであった。コミュニティリーダーとその他の人たちは、この状況で何が起きているのか彼らの考えを投稿し、Shore氏の最初の立場から、最近さらに数歩踏み出している。

  • オーバーコミット対オーバーデリバリ

    スプリント計画の主要な目的は、スプリントの終わりまでに「何をデリバリするつもりか」をコミットすることである。一度コミットされると、チームは目標を達成するために一丸となって働く。スクラムマスタは、チームのスピードを落とすであろう、あらゆる障害を取り除く。理想を言えば、チームはコミットしたことを守らなければならないが、もしチームが絶えずオーバーコミットしているか、あるいはオーバーデリバリしている場合は、心配の種がある。

  • チームの腐ったリンゴを扱う

    ここ数日間、Scrum Development Yahoo Groupでチームの1人の「働きが少ない」場合に何をするかについてとても活発な議論がなされている。Rotten apple in Scrum team(スクラムチームの腐ったリンゴ) の130以上のレスポンスの中で、最初の質問へのアドバイスから、チームのやる気や誰がそれを管理するかという話、個人を計測する昔からの論争、チームが本当に「チーム」であるかどうか見分けることなどへ議論が及んだ。

  • レイオフ後にアジャイルを行う

    Adrian Carr氏は、レイオフ後に自分のチームでのスクラムのインプリメンテーションを適合させることについて書いている。

  • スクラムのスクラム - 問題と価値

    Agile Estimating and Planningの著者のMike Cohn氏が「スクラムを大きなプロジェクトチームに適用させるのに重要な技術」と説明しているのが、スクラムのスクラムミーティング(the Scrum of Scrums)である。

  • スクラム導入時の課題

    新しいソフトウェア開発手法を導入することは、「変化を受け入れたがらない」といったものから「誤った導入方法」ようなものまで幅広く、いくつもの失敗へと繋がる課題がある。Cesario Ramo氏とEelco Gravendeel氏は、アジャイルジャーナルの連載記事の中で、スクラムで仕事をしている時であったり、さまざまな組織にスクラムを導入した時に気付いた課題について語っている。

  • プロダクトオーナーとスクラムマスタの組み合わせは可能か?

    多くの人手不足のチームや小さな組織では、スクラムマスタ (SM) とプロダクトオーナー (PO) の役割を1人に組み合わせることを考える。これは望ましいことだろうか? 他の人々はこうしただろうか? 選択肢は何だろうか?

  • Snake On The Wall : 壁に並べた付箋紙を使って障害を把握する

    Kevin Schlabach氏が、最近「Snake On The Wall」を使うことについてAgile Commentaryブログに投稿した。「Snake On The Wall」とは、開発プロセスを遅らせるものをチームで把握するのに役立つSchlabach氏が使っていた手軽なアプローチである。

  • スクラムのスクラムをせずにスクラムをスケールする

    スクラムは、開発チームのメンバ間のコミュニケーション促進において効果的であることを証明してきた。この高帯域のコミュニケーションを、特に大きな組織において、どのようにしてチームを越えてスケールするかという問題は、活発に調査・議論される領域に残っている。

  • スクラムにおける変更要求の運用

    変更管理というのは、昔ながらのプロジェクトマネジメントで使われる変更を運用するための手法だ。昔ながらのプロジェクトの変更管理は典型的に、変更内容の詳細、プロジェクトへの影響、リスク、代替案などの属性を持った変更要求の詳細を書き込むことで成り立っている。

  • Article: 事例研究:Dutch Railwaysのプロジェクトにおける分散拠点でのスクラム・プロジェクト

    この記事では、私達がどのようにして大規模(240人月、10万行強)でインドとオランダの開発者も参加したスクラム・プロジェクトを成功させたのかを示しています。

  • James Shore氏「アジャイルの衰退と凋落」

    James Shore氏はアジャイルは衰退していくと断じている。多くのチームが、長期間にわたって高品質なソフトウェアを生産するために必要とされる技術的なプラクティスを適用することなく、「スプリント」と朝会だけ行っていることを例に挙げている。

  • 「スプリント」は適切な呼び方ではない?

    アジャイル開発における最も根本的な概念の1つとしてあげられるのは「反復」しながら仕事をすすめるということだろう。繰り返し暫定的なマイルストンを設定しながら、繰り返し改良されたバージョンの製品を納品することで、プロジェクトを運営していくのである。アジャイルな手法では、このやり方を何かに喩えた名前を付けている。有名なもので言えば、XPの「イテレーション」であり、スクラムの「スプリント」である。

  • スクラム認定テスト

    アジャイルコミュニティの様々なメンバが、スクラム認定には意味がないことに何度も不満を漏らしている。なぜなら、スクラム認定の講座を受講する人は、ほとんど誰でも認定証を受け取るからだ。Danube technologiesのMichael James氏は、2009年1月1日よりこのケースはもはやあてはまらないと書いた。

  • Scrumでの非機能的な要求の対処

    非機能的な要求は、振る舞いよりもシステムの質を説明する。Scott Ambler氏は、Dr. Dobb氏のポータルの記事にある「Scrumの製品バックログの概念は、単純な機能的な要求には適切に動作するが、非機能的な要求やアーキテクチャ上の制約には足りない」ということを主張したとき、白熱した議論を巻き起こした。

BT