InfoQ ホームページ Agile in the Enterprise に関するすべてのコンテンツ
-
Agileプロジェクトでどうやって知識を伝達する方法
知識の伝達を特徴づけるのは、文脈についての理解を、1つの単位(個人や、チーム、部門、組織)からもう1つの単位へ転送することだ。Steve Bockman氏は一連の実験を行い、Agileプロジェクトで知識を伝える最適な方法を探り出そうとした。
-
ソフトウェアの負債には多額の費用がかかる
“Continued Delivery of High Values as Systems Age”(システムの年数を重ねながら、高い価値を提供し続ける)という最近の記事において、 Chris Sterling氏がソフトウェアの負債の概念について論じている。“ソフトウェアの負債は、長年にわたってシステムの変わりやすい性質を軽視し、急いで完成させることに注目し続けるときに蓄積していくものだ。”ソフトウェアの負債は技術的負債以上のものであり、価値を提供する能力に影響する様々な面を含む。
-
２タイプのアジャイル文書 ― ２種類しかない
アジャイルマニフェストには、「動くソフトウェアが、どんな文書よりも理解しやすい」、とある。このおかげで、アジャイルプロジェクトでは、文書は、要らないと多くのチームに信じられるようになった。アジャイルを批判する人たちは、その方法論の弱点を示すのに、アジャイルの少ない文書を指摘する。 Eelco Gravendeel氏は、アジャイルには、たった２種類の文書しかない、と言う。
-
EUソフトウェア責任訴訟－半数はユニットテストが対処法だという
Typemockの調査によると、52%の.NET開発者がユニットテストは会社がEUソフトウェア責任法案による訴訟を避けるのに一役買うと思っている。これはどういうことか？
-
PMIのアジャイルコミュニティ「PMI Agile Community of Practice 」
アジャイル と Project Management Institute (PMI)。長年、多くの人たちにとって、この言葉の組み合わせは混じり合わない"水と油"と同じ意味を持って知られている。しかし、これは正しいだろうか? Jesse Fewell氏、Dan Mezick氏らはこれに対して異議を唱え、新たなPMI Agile Community of PracticeとともにPMIにアジャイルを取り入れようとしている。
-
スクラムマスターインタビューのコツ
スクラムマスターやイテレーションマネージャはアジャイルチームにおける重要な役割であり、彼らがどの組織やチームと一緒に仕事をするか選ぶのは大事なことだ。新しいプロジェクトのスクラムマスターを引き受けるか検討するときには、成功するための環境を整えることが重要となる。この記事では、プロジェクトやチームを引き受けるか検討しているスクラムマスターのために、インタビューについてアドバイスする。
-
自己組織化したチームの成功を保証する
自己組織化とは、組織の内部組成が外的要因に導かれることも管理されることもなく複雑さを増す現象と定義される。しかし、成功した自己組織は適正な水準のサポートを、チームメンバからだけではなく、マネジメントや組織環境からも得る必要がある。
-
アジャイル文化への転換は容易ではない
多くの評論家が、組織のアジャイル文化への転換に関する課題について執筆してきた。Ken Schwaber氏は、スクラム実践の75%では期待する利益を実現できないと予想していた。本稿では、その原因の一部と成功率向上のためにすべきことに着目する。
-
Agile In a Flash（速解アジャイル）
多くの人々が冗談半分に３×５のインデックスカードを「アジャイリストのバッチ」と認めている。しかし、色々な意味でこれは不正確でも不適切でもない。山積みされたインデックスカードを見ていくことが、実際に多くのアジャイル的活動に対する品質保証になり得るのだ。しかし、インデックスカードを使ってアジャイルを学び、覚えるというのはどうだろうか？「Agile In a Flash」プロジェクトにおいて、Tim Ottinger氏とJeff Langr氏はまさにそういった人々の手助けをしようとしている。
-
進化論から見たソフトウエア開発
ミームとは、もとはRichard Dawkins氏の著書"利己的な遺伝子"で提示された概念で、遺伝子を使って文化を考えるためのものだ。ミームは人々の間に広がり、思考や行動に影響を与える。Julian Everett氏の考えでは、ソフトウエア開発の方法論や概念や文化はミームの集合と見なすことができるのではないか、ということだ。そしてそのように考えることで、方法論の効果とその理由はまったく逆になる。
-
アジャイルプロジェクトにおけるリソースマネジメント
アジャイルプロジェクトは急激な変化という問題を解決するものとして知られている。これらは市場要因やシステム要件、実装技術における変化かもしれない。こうした変化の1つに、プロジェクトに取り組む人員の頻繁な変化があるが、これはアジャイルプロジェクトとは相性がわるい。このアイデアは、成果を上げているチームを乱さないようにすることで、高いベロシティを実現し続けることができるというものだ。
-
IBMの新たなクラウド戦略とサービス
IBMは企業におけるクラウドコンピューティング活用のための３つの方法を発表した。標準的なIBMクラウド，(企業またはIBMが管理する)ファイアウォール内で稼動するプライベートクラウドサービス，そしてサービス要求の"オーバーフロー"をセキュアなパブリッククラウドにシームレスに接続する CloudBurstである
-
アジャイル組織は何を重視すべきか?
アジャイルを採用することは簡単ではない。多くの組織は、スクラムやXPのプラクティスを自分たちのやり方に無理やり当てはめようとして苦労する。そのような組織に対して、"どのように"アジャイルを行うかということを重視しすぎるのは誤ったアプローチかもしれないとMike Cottmeyer氏は助言する
-
組織内の政治をどうやって乗り切るか?
政治は全ての組織に欠かせないものである。一般的に、技術的な人々は政治を嫌っている。なぜなら技術的に問題はほとんどの場合厳格で、白黒はっきりつけやすく、政治的な問題はいつも簡単に判断がつかないため、灰色の影を伴うからである。最近Scrum Development groupのメンバーの間ででは政治を扱う方法について議論されている。
-
受入テストの自動化 - 理論にすぎないのか、それとも実践的なのか
要件を受入テストとして記述し、それを自動化することに成功したという報告がこれまでも時折見られている。しかし、これを実践しているのはコミュニティの中の少数派でしかない。各イテレーションの最初に自動化された受入テストを書くという主張は理論的なものに過ぎず、適用事例が少ないということが非効率であることの証明になっているのだろうか。