InfoQ ホームページ Agile in the Enterprise に関するすべてのコンテンツ
-
-
大規模なアジャイルプロジェクトで新しい人を入れる
Anand Vishwanath氏は、大規模なアジャイルプロジェクトでは、小規模の「シミュレーション・プロジェクト」の利用が、新しい人を決まったやり方に慣れさせるための最善の方法となるだろうと提案している。一言で言えば、「一回の研修の中で新たに入ってきた人たち４～６人のグループを作り」、経験のある数人のメンターの支援の下で彼らに１～２週間に渡って数回の小さなイテレーションを実行させるのである。
-
-
理想的なイテレーション期間
アジャイルの導入でよくある質問の1つは、理想的なイテレーション期間に関したものである。チームは、たいていイテレーションの期間は1週間から2ケ月を取っている。正しいイテレーション期間を選択することが重要であり、アジャイルの導入が成功するかは、適切なイテレーション期間にかかっている。
-
非常に生産性が高いチームをどうやって手に入れるか?
アジャイルソフトウェア開発がこれほど評判のよい主な理由のひとつであり、おそらく一番の理由だと言えるのは、非常に生産性が高いことに関して現場から数多くの報告があることだ。ソフトウェアを構築して1つの不具合も出さずにリリースしたチームは、顧客やかつて製品化までにかかっていた時間をごくわずかにまで減らしてきた人たちに知れ渡る。Joanna Zweig氏とCesar Idrovo氏は、非常に生産性が高いチームの働き方の理論、グループの一貫性について説明する4つの記事を書いた。
-
アジャイル・ガバナンス：経営とITを結ぶ橋
従来のプロジェクトガバナンスは、成功プロジェクトを確実にするために必要とされる、ルールやプロセスを述べるために使用されている。従来のガバナンスは、プロジェクトの作業をプロセスの作業として管理しようとしている。一見したところでは、ガバナンスの概念とアジャイルは両立しないように思われる。しかし大抵のアジャイリストは、過不足のないガバナンスが、アジャイルプロジェクトに悪いものよりも多くの良いものをもたらすかもしれないことに同意するだろう。
-
ソフトウェア職人マニフェスト:出撃命令
Pete McBreen氏は2001年に『Software Craftsmanship:The New Imperative』を書いた。昨年、Bob Martinおじさんは『Clean Code: A Handbook of Agile Software Craftsmanship』を書いた。そして彼はAgile2008の基調講演の中で、アジャイルマニフェストに「クズなコードを書かずにソフトウェア 職人気質を持つこと」を追加して修正することを提案した。
-
経営陣によるアジャイル導入へのサポートの三本柱
ひとたび自分達のチームに対してアジャイルが正当だと説明し、トレーニングにお金をかけると、経営陣の仕事は終わらない。移行を成功させるためには、経営陣が持続的なサポートをする必要がある。Esther Derby氏は少し時間を取り、この継続的なサポートの、３つの最も重要な側面であると彼女が考えていることを述べている。
-
従来のソフトウェア開発の役割をスクラムに対応させる
アジャイル採用の道に乗り出した多くの組織では、従来のソフトウェア開発の役割をスクラムが定める３つの役割に対応させるという課題に取り組まなければならない。一連の見解の中で、Mike Cottmeyer氏は従来の役割を効果的にスクラムに対応させようと試みている。
-
オピニオン：ビジネスとITの提携におけるパラダイム変化のとき
最新の記事において、EDS Fellowであり「Building the Agile Enterprise with SOA, BPM and MBM」の著者であるFred Cummins氏が、ビジネスとITの提携の探求におけるパラダイム変化のときだと論じている。
-
要件が二番目、では一番目は何か?
Allan Kelly sites an article from MIT's Sloan Management Review about why it is important to get a team's technical competence and ability improved before focusing on business-IT alignment. This, he claims, is one of the reasons Agile software development has been so successful. Allan's point indirectly touches on a recent community debate about successful, valuable, Agile adoption.
-
「ABetterTeam.org」でアジャイル度を評価しよう
Sebastian Hermida氏は自分たちがどれだけうまくアジャイルを採り入れているか、チームが理解を深めるのに役立つ無料で使えるオンラインのツールを作った。サイト「abetterteam.org」はJames Shore氏とShane Warden氏の本『アート・オブ・アジャイル デベロップメント(The Art Of Agile Development)』に出てくる「アジャイル度を評価しよう」というクイズに基づいたものだ。
-
分散アジャイルプロジェクトの早い段階での終焉を確実にする方法?
分散モードで作業している場合、アジャイルを導入して、実行するのがますます難しくなる。分散アジャイルは、地理的分離、異なる時間帯、文化の違いの観点から、独自の課題を突きつける。
-
プロダクトオーナーは一人であるべきか?
チームでもっとも重要といえるメンバの役割であるプロダクトオーナーに関して、ScrumDevelopmentメーリングリストで重要な話し合いが行われている。Jean Richardson氏が次の質問でこの話し合いを始めた。
-
アジャイルにすべてを導入する
2ヶ月前、InfoQはJim Shore氏の人気の記事を紹介した。それは、組織が「アジャイル」を名前だけで導入し、実際にアジャイルであるために本当に意味するものの導入に失敗するという、現在増えているコミュニティの傾向を強調するものであった。コミュニティリーダーとその他の人たちは、この状況で何が起きているのか彼らの考えを投稿し、Shore氏の最初の立場から、最近さらに数歩踏み出している。