BT

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

寄稿

Topics

地域を選ぶ

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

  • チームの最適な構造

    アジャイルは7人に2人多いか少ないかくらいの大きさのチームについて話題にするが、一方で全体チームという考え方も推奨する。全体チームとは案件を遂行するための十分な技術をチーム全体に持たせるという考え方だ。つまり、中核となる開発技術とは別に、必ずやらなければならないテストの技術、データベースに関する技術、ユーザインターフェイスに関する技術もチームが持つという考え方だ。チームの構造を定義するのは簡単だろうか。

  • ふりかえりを改善するためのルール

    James Carr氏は最近、ふりかえりを改善するための5つのルールを公開した。これらのルールは、成功したものも失敗したものも含む、何百回にも及ぶふりかえりの経験に基づいている。

  • オーバラップそれとも同期化されたスプリント?

    スクラムプロジェクトが成長すると、チームメンバーも成長する。成長しているチームを管理する推奨される方法は、アジャイルに推奨されるチームサイズを保つようにチームを複数のチームに分割することである。けれども、それぞれのチームが各々のスプリントで作業し始めたときに、それらは複数のコミュニケーションと調整の問題になるかもしれない。

  • アジャイルプロジェクトが遅れる理由

    一般的に言えば、遅延とは作業の実施が予定よりも後になることであり、それによって不満や作業が苦しみが生まれ、関係者に迷惑をかける。同じように、アジャイルプロジェクトでも遅延という言葉は無駄と考えられている。遅延はプロジェクトの流れを断絶してしまうので、再学習やタスクの変更などの更なる無駄を生み出す。何人かのアジャイル実践者が一般的な遅延とその対処法について議論している。

  • アジャイルの成功が結局は失敗になるとき

    パイロットアジャイルチームが成功すると、アジャイル導入のプロセスが正しい方向に向いていると思い込みがちだ。Dave Nicolette氏が、試験的な試みが大成功した後で、導入に失敗した状況について興味深い洞察を示す。

  • アジャイルを導入するパイロットプロジェクトの選び方

    アジャイルの導入を成功させる最も重要な要因の1つは、アジャイルをパイロットプロジェクトに適用することで学んだことだ。ここで学んだことが、今後アジャイルを推進するのか、それとも従来のプロセスに戻すのか、組織に大きな影響を及ぼすことになる。パイロットプロジェクトに適していないプロジェクトを選んでしまうと、アジャイルという新しいプロセスをうまく宣伝できずに、失敗に終わるだろう。

  • 誰が私たちのプロジェクトのステークホルダーを動かしたのか?

    アジャイルなチームにとってのプロジェクトのステークホルダーはプロジェクトの成功に価値のある関係を持つ人である。その人はもしかするとプロジェクトに対する資金を持っている場合もある。しかし、いくつかのシナリオにおいてはプロジェクトのステークホルダーから時間を捻出してもらうことが非常に難しいことがある。ほかの極端な場合には、ステークホルダーは興味を持っていないか、完全に行方不明になってしまうようなこともある。

  • アジャイル開発を成功に導く26のヒント

    Keith Swenson氏は最近、アジャイル開発のための26のヒントを一覧にまとめた。氏は様々なトピックに関する知見を定期的に収集しているようで、この一覧はアジャイル開発について本当に考慮すべき点を抽出したものになっている。

  • すべてのプログラマが知っておくべき97のこと

    「97のこと」シリーズ続編。アーキテクト、プロジェクトマネージャに続いて、今回はすべてのプログラマが知っておくべきこと。 InfoQは編集者のKevlin Henney氏に話を聞いた。

  • 'アジャイルの三角形'によるアジャイルのパフォーマンス測定

    伝統的なソフトウェア開発チームは,ソフトウェアの'鉄の三角形(Iron triangle)'の領域内で活動すると考えられている。この三角形の3つの辺は,スコープ,スケジュール,費用である。Jim Highsmith 氏は,この鉄の三角形がアジャイルチームの柔軟性に対して多くの制約を課すものだとして,それに代わるアジャイルの三角形(Agile Triangle)を提案した。

  • スピードアップのためのスローダウン

    チームが最も生産的なのはそのチームのメンバが能力を最大限に発揮して活動している時である,と普通は考えられている。この常識に反してSteve Bockman 氏は,このような仮定が常に正しいとは限らない,ということを言っている。生産性を向上させるために時にはスローダウンし,最大限の能力以下で働くことが必要である,というのだ。

  • Ruby on Rails プロジェクトを救助する

    Ruby on Railsが世に出て5年ほどの間,開発者たちは数多くのアプリケーションを開発してきた。その多くがRubyないしRuny on Railsを習得しながら開発されたため,ベストプラクティスとは言いがたいが,それでもWebサイトとして製品にはなっている。これらのWebアプリケーションには問題もあるが,その解決方法を取り上げた本が新たに発行された。

  • アジャイルプロジェクトにおけるリソースマネジメント

    アジャイルプロジェクトは急激な変化という問題を解決するものとして知られている。これらは市場要因やシステム要件、実装技術における変化かもしれない。こうした変化の1つに、プロジェクトに取り組む人員の頻繁な変化があるが、これはアジャイルプロジェクトとは相性がわる���。このアイデアは、成果を上げているチームを乱さないようにすることで、高いベロシティを実現し続けることができるというものだ。

  • 組織内の政治をどうやって乗り切るか?

    政治は全ての組織に欠かせないものである。一般的に、技術的な人々は政治を嫌っている。なぜなら技術的に問題はほとんどの場合厳格で、白黒はっきりつけやすく、政治的な問題はいつも簡単に判断がつかないため、灰色の影を伴うからである。最近Scrum Development groupのメンバーの間ででは政治を扱う方法について議論されている。

  • 非常に高い生産性を測るのは時間の無駄か?

    Hyperproductivity and Shock Therapyというプレゼンテーションの中で、Jeff Sutherland氏は、非常に高い生産性とは少なくとも自動車業界平均の4倍の生産力があるトヨタほどのレベルがあることだと述べた。Scrum Development groupの最近の議論において、メンバたちは、スプリント中に生産性を正確に測ることが可能か、また成果があるかどうかを議論した。

BT