InfoQ ホームページ Agile に関するすべてのコンテンツ
-
FisheyeとCrucibleで「ソーシャルネットワーキング」が可能に
Atlassian社のFisheye 2(ソースコードリポジトリブラウザ)とCrucible 2(コードレビュア)の最新版は、完全に刷新されたUIを持ち、開発者が、作業に対するのと同様に、ある意味ソーシャルネットワーキングであるチームをフォローできるようになった。Crucible 2は、同時に反復的なコードレビューの概念もサポートする。
-
アジャイル/スクラムプロジェクトにおけるバグへの対応
よくされる質問がある。スクラムでは、チームがバグをどう処理することを推奨しているのか？プロダクトバックログに入れるべきなのか？それとも、別のバグリストに入れるべきなのか？もしバグがバックログにあるのなら、プロダクトオーナーが優先順位をつけるのか、それとも、自動的に最重要項目になるのか？別のバグ修正スプリントをするべきなのか？
-
PMIのアジャイルコミュニティ「PMI Agile Community of Practice 」
アジャイル と Project Management Institute (PMI)。長年、多くの人たちにとって、この言葉の組み合わせは混じり合わない"水と油"と同じ意味を持って知られている。しかし、これは正しいだろうか? Jesse Fewell氏、Dan Mezick氏らはこれに対して異議を唱え、新たなPMI Agile Community of PracticeとともにPMIにアジャイルを取り入れようとしている。
-
スクラムマスターインタビューのコツ
スクラムマスターやイテレーションマネージャはアジャイルチームにおける重要な役割であり、彼らがどの組織やチームと一緒に仕事をするか選ぶのは大事なことだ。新しいプロジェクトのスクラムマスターを引き受けるか検討するときには、成功するための環境を整えることが重要となる。この記事では、プロジェクトやチームを引き受けるか検討しているスクラムマスターのために、インタビューについてアドバイスする。
-
自己組織化したチームの成功を保証する
自己組織化とは、組織の内部組成が外的要因に導かれることも管理されることもなく複雑さを増す現象と定義される。しかし、成功した自己組織は適正な水準のサポートを、チームメンバからだけではなく、マネジメントや組織環境からも得る必要がある。
-
ベロシティは何のため？
最近、ScrumDevelopment Yahoo!グループでは、ベロシティの活用と誤用に関して様々な議論がなされている。ベロシティを生産性の基準として使うべきだろうか？イテレーション計画のために使うべきだろうか？もっと長期のリリース計画にはどうだろうか？
-
アジャイル文化への転換は容易ではない
多くの評論家が、組織のアジャイル文化への転換に関する課題について執筆してきた。Ken Schwaber氏は、スクラム実践の75%では期待する利益を実現できないと予想していた。本稿では、その原因の一部と成功率向上のためにすべきことに着目する。
-
日本のリーン活動を見る
リーン活動を見るために日本の「現場に行った」アジリストのグループは、何を見ただろうか? 日本への「Roots of Lean」ツアーは、Mary Poppendieck氏とTom Poppendieck氏に率いられ、この春実施された。ここに、プロガーやニュースグループのライターたちがツアーについて観察したことをまとめている。このツアーでは、Henrik Kniberg氏、Sune Gynthersen氏、Gabrielle Benefield氏等が、製造工場とソフトウェア会社の両方を訪れている。
-
Ruby on Rails プロジェクトを救助する
Ruby on Railsが世に出て５年ほどの間，開発者たちは数多くのアプリケーションを開発してきた。その多くがRubyないしRuny on Railsを習得しながら開発されたため，ベストプラクティスとは言いがたいが，それでもWebサイトとして製品にはなっている。これらのWebアプリケーションには問題もあるが，その解決方法を取り上げた本が新たに発行された。
-
Agile In a Flash（速解アジャイル）
多くの人々が冗談半分に３×５のインデックスカードを「アジャイリストのバッチ」と認めている。しかし、色々な意味でこれは不正確でも不適切でもない。山積みされたインデックスカードを見ていくことが、実際に多くのアジャイル的活動に対する品質保証になり得るのだ。しかし、インデックスカードを使ってアジャイルを学び、覚えるというのはどうだろうか？「Agile In a Flash」プロジェクトにおいて、Tim Ottinger氏とJeff Langr氏はまさにそういった人々の手助けをしようとしている。
-
進化論から見たソフトウエア開発
ミームとは、もとはRichard Dawkins氏の著書"利己的な遺伝子"で提示された概念で、遺伝子を使って文化を考えるためのものだ。ミームは人々の間に広がり、思考や行動に影響を与える。Julian Everett氏の考えでは、ソフトウエア開発の方法論や概念や文化はミームの集合と見なすことができるのではないか、ということだ。そしてそのように考えることで、方法論の効果とその理由はまったく逆になる。
-
チームのコード品質
Jaibeer Malik氏は、チームにおけるコード品質への取り組み方や導入方法を紹介する記事を投稿してきた。氏の一連の記事は、自身のさらなる学習や、そこで得た考えを第三者に伝えなければならない状況に置かれた場合に役立つだろう。一連の記事では、トピックの概要を簡単に述べ、学習をさらに深めるために進むべきさまざまな方向について助言している
-
ペアプログラミングの1ドルの価値
"なぜこの世界では1つの仕事を2人でするのか?" 初めてペアプログラミングの考え方を紹介されたとき、多くの人は最初にこのように反応する。本質的に、彼らは、ペアプログラミングとはある部分のコードを書くコストが2倍になることだと考える。Dave Nicollete氏が、ある計量的な考え方を示し、ペアプログラミングはお金を無駄にするのではなく、節約することを示している。
-
アジャイルプロジェクトにおけるリソースマネジメント
アジャイルプロジェクトは急激な変化という問題を解決するものとして知られている。これらは市場要因やシステム要件、実装技術における変化かもしれない。こうした変化の1つに、プロジェクトに取り組む人員の頻繁な変化があるが、これはアジャイルプロジェクトとは相性がわるい。このアイデアは、成果を上げているチームを乱さないようにすることで、高いベロシティを実現し続けることができるというものだ。
-
立ち止まってリファクタリングをする？
いつリファクタリングをするべきなのだろうか？単純に技術的負債（"technical debt"）を返済しなければならない時もあり、そこでは立ち止まってリファクタリングをするべきなのか。そうではなくて、ユーザストーリーに関わっている時だけしかリファクタリングするべきではないのか。どちらのアドバイスが正しいのだろうか？あるいは、もしかしたら第３の選択肢が存在するのだろうか？