InfoQ ホームページ Best Practices に関するすべてのコンテンツ
-
合衆国政府のクラウドコンピューティングの評価認定に関する提案
2週間前、合衆国のCIO協議会のオフィスは合衆国政府のクラウドコンピューティングに対するセキュリティの評価認定に関する提案と題した90ページの提案書を発表した。この提案書は18ヶ月にわたるNIST、SA、ISIMC、CIO協議会の間で行われた作業の成果であり、合衆国政府のクラウドコンピューティングに対するセキュリティ管理と複数の評価認定モデルを審査するために作成されたものだ。
-
RESTfulサービスにおいて部分的更新を実装する
Alex Scordellis氏は、リソースの部分的更新についてのクライアントとRESTfulサービスのインタラクションがどのようにモデル化され、デザインされ得るかについての記事を投稿した。リソースを適切にモデル化すれば、問題は容易に解決するようだ。多くの場合、ただリソースをCRUDをサポートするエンティティとして考えることによってそれは問題となる。リソースを"リソース"とサービスとしてモデル化することだ。
-
ゲーム理論とアジャイルソフトウェア開発
ゲーム理論はもともと経済学の分野で企業や市場，消費者の行動などを理解するために開発されたものだ。その後さまざまな分野に応用範囲を広げ，政治学や社会学，心理学，さらにはアジャイルソフトウェア開発にも適用されている。
-
効率的なアジャイルミーティング
ミーティングは高価だ。ミーティングに関わるすべての人のコストをオーバーヘッドも含めて算出すれば、1日のチームミーティングのコストは数千ドルにもなる。したがって、実際にアジャイルのミーティングを可能な限り効率的にするためには、かなりの準備をする必要がある。
-
スクラムにプロダクトマスタの役割はない
様々なフォーラムでよく聞かれる質問は、スクラムマスタとプロダクトオーナーの役割の組み合わせは受け入れられるかということだ。アジリストのほとんどはこれらの役割は水と油のようなものだと信じている一方で、これらの組み合わせが避けられない状況もある。
-
チームの変更に対応する
変更は普遍的なものであるにもかかわらず、人は変更に対して不安を抱く。この場合、未知への不安や安心感の喪失に対して抱くことがほとんどで、変更の受け入れを難しくする。アジャイル・チームは変更に対して十分な態勢が整っているとはいえ、彼らの大部分は変更の影響がチームに及んだ場合、それを快くは思わない。
-
モチベーション 3.0：McGregor氏のY理論が有効
McGregor氏のX理論が示唆しているのは、従業員とは先天的に怠惰な存在で、可能であれば仕事を避けるし、また先天的に仕事が嫌いだということだ。したがって、従業員は念入りに監視される必要がある。それに対してY理論が示唆するのは、従業員には志があり、自発的で、セルフコントロールができるというものだ。従業員は、仕事という精神的身体的な義務を楽しむのである。ほとんどのアジャイルチームはY理論と結びつきたいと考える。Mike Griffiths氏はこのことを容易に達成するにはどうすればよいかについて提言する。
-
バックログ・グルーミング: 誰が、いつ、どのように行うか
バックログ・グルーミング(バックログの手入れ)とは、その名前が示すとおり、プロダクトバックログを定期的に気にかけ、注意を払い、雑草だらけの手入れされていない庭のように、バックログが醜く手におえないものにならないようにすることだ。スクラムの正式なプロセスではないが、Ken Schwaber氏は、各スプリントの5%をこの活動のために割くように推奨している。Scrum Developmentグループでの最近の議論では、このプロセスの利点と欠点、どの程度時間をとるべきかといったことに焦点があてられていた。
-
チームの最適な構造
アジャイルは7人に2人多いか少ないかくらいの大きさのチームについて話題にするが、一方で全体チームという考え方も推奨する。全体チームとは案件を遂行するための十分な技術をチーム全体に持たせるという考え方だ。つまり、中核となる開発技術とは別に、必ずやらなければならないテストの技術、データベースに関する技術、ユーザインターフェイスに関する技術もチームが持つという考え方だ。チームの構造を定義するのは簡単だろうか。
-
ふりかえ��を改善するためのルール
James Carr氏は最近、ふりかえりを改善するための5つのルールを公開した。これらのルールは、成功したものも失敗したものも含む、何百回にも及ぶふりかえりの経験に基づいている。
-
オーバラップそれとも同期化されたスプリント？
スクラムプロジェクトが成長すると、チームメンバーも成長する。成長しているチームを管理する推奨される方法は、アジャイルに推奨されるチームサイズを保つようにチームを複数のチームに分割することである。けれども、それぞれのチームが各々のスプリントで作業し始めたときに、それらは複数のコミュニケーションと調整の問題になるかもしれない。
-
アジャイルプロジェクトが遅れる理由
一般的に言えば、遅延とは作業の実施が予定よりも後になることであり、それによって不満や作業が苦しみが生まれ、関係者に迷惑をかける。同じように、アジャイルプロジェクトでも遅延という言葉は無駄と考えられている。遅延はプロジェクトの流れを断絶してしまうので、再学習やタスクの変更などの更なる無駄を生み出す。何人かのアジャイル実践者が一般的な遅延とその対処法について議論している。
-
アジャイルの成功が結局は失敗になるとき
パイロットアジャイルチームが成功すると、アジャイル導入のプロセスが正しい方向に向いていると思い込みがちだ。Dave Nicolette氏が、試験的な試みが大成功した後で、導入に失敗した状況について興味深い洞察を示す。
-
アジャイルを導入するパイロットプロジェクトの選び方
アジャイルの導入を成功させる最も重要な要因の1つは、アジャイルをパイロットプロジェクトに適用することで学んだことだ。ここで学んだことが、今後アジャイルを推進するのか、それとも従来のプロセスに戻すのか、組織に大きな影響を及ぼすことになる。パイロットプロジェクトに適していないプロジェクトを選んでしまうと、アジャイルという新しいプロセスをうまく宣伝できずに、失敗に終わるだろう。
-
誰が私たちのプロジェクトのステークホルダーを動かしたのか？
アジャイルなチームにとってのプロジェクトのステークホルダーはプロジェクトの成功に価値のある関係を持つ人である。その人はもしかするとプロジェクトに対する資金を持っている場合もある。しかし、いくつかのシナリオにおいてはプロジェクトのステークホルダーから時間を捻出してもらうことが非常に難しいことがある。ほかの極端な場合には、ステークホルダーは興味を持っていないか、完全に行方不明になってしまうようなこともある。