InfoQ ホームページ Agile に関するすべてのコンテンツ
-
デイリースタンドアップのコツ - まとめ
デイリースタンドアップが長い日次進捗報告以外の何ものでもなくなり、メンバに無視され始めるという話はよく耳にする。これを始めとしたスタンドアップの落とし穴を避けるために、どのようなテクニックがあるだろうか？
-
継続的デプロイのプラクティス
継続的デプロイは、リーン開発の"仕掛排除"運動で最近注目されている。多くの人が、これについて興味を持ち、価値のある目標を見出している一方、これが実際どのように達成されたかをなかなか可視化できていない。Ash Maurya氏は会社で起こった自身の経験を説明することで、このギャップを埋めようとしている。
-
アジャイルの"ルール"を"ガイドライン"に変えられるか？
一般的にルールとは，ある行動に関して定義された基準のことをいう。ルールには従わねばならない。法律の非公式な呼び方が "ルール" である，と言い換えてもよいだろう。これに対してガイドラインとは，決められた手順に従うことによって，特定のプロセスを合理化する目的のものだ。定義上は，ガイドラインは義務ではない。アジャイルチームはルールを語るべきだろうか，それともガイドラインで十分なのだろうか？
-
どのようにしてアジャイルを競争相手と比較するか？
チームや組織は仕事のやり方について、競争相手を使って評価したいと思うことがよくある。彼らは改善すべきところに注目して、よいフィードバックがあれば取り入れたいと思っている。Comparative Agilityアセスメントとはアセスメントツールであり、組織が次回のアジャイルの取り組みを計画するときに、その結果が役立つだろう。
-
リーン＋リアルオプション＝複雑さとリスクの低減
リアルオプションとは、金融オプション数学に基づく意思決定プロセスである。これは通称「白本」とよばれるExtreme Progamming Explainedにおいて、Kent Beck氏が1999年に言及しているものだ。近年ではアジャイル主義者たちがリアルオプションがアジャイルとどのように交わるのかについて調査してきた。現在はChris Matts氏とOlav Maasson氏が、特にリーンソフトウェアコミュニティに対して発言している。リアルオプションを採用することでリーン開発が改善するというのだ。
-
最近のテクノロジにおけるトレンドは？
ThoughtWorks 社は 4 つの主な領域である、技術、ツール、言語、プラットフォームにおける ThoughtWorks の技術戦略とトレンドを含んでいる、Technology Radar 2010 を今月リリースした。InfoQ は、ThoughtWorks によって提供されたアイデアと示唆をより理解するために、このホワイトペーパを深く調べた。
-
アプリケーションをDependency Injectionフレームワークから分離する
Dependency Injectionは、ずっと受け入れられるようになってきた。そして近年、SOA,TDDそして多くの他の要因が、人気を増してきていることを含んで、多くの要因に後押しされて、Dependency Injectionは、利用しやすい手法になってきた。こうしたことに伴って、Dependency Injectionフレームワークの使用が増えてきた。例を使って、Bob Martin氏は、自分のアプリケーションコードとDependency Injectionフレームワークの間で、疎結合化するアプローチの適用を勧めている。
-
技術的負債は技術的な問題か？
技術的負債は，リファクタリングやテストで直接アプローチできるような純粋に技術的な問題なのか，あるいはさらに大きな問題の兆候だろうか。TDD の適用はこの問題を解決できるのか，それともより大きな何かを覆い隠してしまうだけなのだろうか。
-
かんばんで「プル」を制止してもかまわない
かんばんでは、「プル」の心理学に非常に重点が置かれている。リーンの考え方に賛同するほとんどの人は、従来のプッシュ方式とは対照的に、パフォーマンスや生産性の面で優位とされているプル方式を好む。とはいえ、プルを制止したくなるような状況もあるのではないだろうか。
-
あと2か月でQCon London: Skype, Facebookのケーススタディ; QCon iPhoneアプリ
あと2か月でQCon Londonだ! スケジュールの75%が発表されており、Facebook, Skype, sky.comのケーススタディなどたくさんある。ディスカウント登録締切は明日までだ。今年のQConにはiPhoneアプリまである! AppStoreで'QCon Guide'を検索しよう。
-
考える人のコミュニティ
Jean Tabaka, Liz Keogh と Eric Willekeの３氏は、一緒になって "Lean Software and Systems Consortium"に何か貢献しようと考えた。それどころか、彼らは、ソフトウェア開発のコミュニティ(Lean, Agile, Kanban そしてその他)は、真のコミュニティの重要性と価値を思い出す助けが必要であることを認識した。
-
適応型再利用 - 土木工学に学ぶ
直線的な開発プロセスは土木工学の中核であると信じられているものだが、「なぜ橋を建てるのと同じようにソフトウェアを構築できないのか」というソフトウェア開発に対して時折向けられる批判に対する反応として、ソフトウェアエンジニアはこのような直線的な開発プロセスに対して異を唱えてきた。しかし実は、土木プロジェクトもアジャイル主義者が認めるような方法をしばしば採用しているのである。
-
本日のアジャイル レトロフレクション
レトロフレクションは自らを環境に置き換える概念である。例えば、他人にしたいことや他人にしてもらいたいことを自らに行う。内省（イントロスペクション）は、病気か健康となり得るレトロフレクションの一種である。同様の考えに基づき、は本日のアジャイル レトロフレクション プロジェクトを始めた。
-
オピニオン: アジャイルが成功するかはアジャイルテクニックに依存しない
過去、現在、そして将来も、アジャイルチームが驚くべき成功を収めているのは事実だ。しかし、失敗に終わることがあるのもまた事実だ。導入が「不十分」であったり、「イヤなものを削って」導入してしまったり。他にも、アジャイルチームがすばらしいソフトウェアを作れず、また全体として組織に影響を与えられなかったりすることは数多くある。これは解決できて「修正」できるものなのだろうか？ あるいは、アジャイル開発は一部のチームにだけ役に立つものなのだろうか？
-
オーバラップそれとも同期化されたスプリント？
スクラムプロジェクトが成長すると、チームメンバーも成長する。成長しているチームを管理する推奨される方法は、アジャイルに推奨されるチームサイズを保つようにチームを複数のチームに分割することである。けれども、それぞれのチームが各々のスプリントで作業し始めたときに、それらは複数のコミュニケーションと調整の問題になるかもしれない。