BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ Lean に関するすべてのコンテンツ

  • 学習のためのアジャイルゲーム

    Agile 2008でDon McGrealとMichael McCulloughの両氏はセッションを行い、アジャイルの原則やプラクティスに対するわれわれの理解を深めるために、どのようにゲームや実習を利用するかを示した。

  • 「アジャイル状況」調査でさらなるアジャイルの採用が明らかになる

    Version One社の今年3年目の「アジャイル状況」調査の結果が話題になっている。この調査によると、アジャイルプラクティスはさらに幅広く使用され、目覚しい結果をもたらしている。半数以上の回答者が、彼らの組織のアジャイルプロジェクトの 90 - 100%は成功しているとし、93%はアジャイルプラクティスによって優先順位の変更に対応する能力を強化している。

  • サーバントリーダーシップを問う

    Agile管理者の役割は、サーバントリーダーの役割だけなのか?従来の命令や制御ツールを使うべきなのか?Agile管理者は、権力を行使してチームの要求をするべきなのか?メンバー内に変化を起こすべきなのか?

  • Article: ソフトウェアのリーン思考入門

    これは、InfoQ Chinaのアジャイル編集者、Jacky Li氏によるリーン思考とリーン思考をどのようにソフトウェア開発に適用するかについての入門です。

  • Fowler氏:Agile対Leanの的外れ

    最近のブログ投稿で、Martin Fowler氏は「AgileではなくLeanソフトウェア開発を使用すべきか?」という質問が誤った前提に基づいていることを説明している。Agile とleanは、非常に深く織り込んでいるので、agileをおこなっているときは、leanをおこなっているし、その逆も同様のことが言える。こうした検討されているプロセスの変更は、興味を起こさせ、啓発的な相関の解説を見出す。

  • SCRUMバン - SCRUM用のかんばん

    Corey Ladasは「SCRUMバン」という興味深い論文の中で、リーンのプラクティスである「かんばん」をSCRUMで利用する方法を紹介した。論文で述べられているのは、進化的なプロセスである。

  • カムリ・ハイブリッドのチーフ・エンジニアの死亡に対して、過重労働であるとの判決が出た。

    先月、日本の裁判所で、カムリ・ハイブリッド・プロジェクトのチーフ・エンジニアの死亡は『過労死』(働き過ぎが原因の死)であるとの裁定がおりた。そのチーフ・エンジニアは、最後の数ヵ月は、1ヵ月につき80時間以上も時間外労働をしていた。彼は、デトロイトの自動車ショーへ飛んで行く前日に、心臓発作で亡くなった。

  • アジャイルプロジェクトにおけるトレーサビリティ・マトリックス

    形式ばったトレーサビリティ・マトリックスは、しばしばアジャイルコミュニティから強い反応を引き起こしている。Agile Testingグループでの激しい議論の中で、Jorge Argus氏はアジャイルプロジェクトにおけるトレーサビリティ・マトリックスの必要性に関する興味深いスレッドを立てた。

  • VersionOneがV1チームエディションを発表

    VersionOneが最近、V1: Agile Teamを発売した。V1: Agile Teamは、ライトウェイトなアプリケーションで、アジャイルソフトウェア開発を始めたばかりの比較的小さなプロジェクトやチームに、アジャイルプロジェクトの計画とトラッキングを始める方法を提供する。

  • 2008年度のアジャイル採用に関する調査結果

    2008年2月に、Dr. Dobb'sではアジャイルソフトウェア開発技術の採用に関する調査を行い、642名の回答者から統計を集めた。採用率が昨年と同じく69%であったのは、驚くべきことである。他の統計では、しかしながら変化を見せている。

  • バリューストリームの妨げとなるもの

    スクラムでは「より生産的であろうとすることを妨げる何らかのもの」を障害として定義している。チームができるだけ継続的に、障害を取り除く手段を確立することを、スクラムでははっきりと重視している。Joe Little 氏は、障害のスコープについて、「組織が価値を提供することを妨げる何らかのもの」とした方がよいのではないか、と提案している。

  • 8aweekからのアジャイルコミュニティへの教訓

    InfoQは最近、8aweek共同設立者のDave Fowler、Zachary Garbowの両氏に、ユーザーとの連絡方法や、仕事の優先順位のつけ方、物事の達成方法について質問する機会を得た。

  • Article: 3つのM - リーンの3要素

    リーン主義をソフトウェア開発に適用することについての議論では、主にムダ(無駄:Muda)なものを特定して排除することに関心が向けられてきました。リーン思考は同様に、ムリ(無理:Muri)とムラ(ばらつき:Mura)を削除することも目指しています。

  • イテレーションやスプリントはアジャイルチームにとって無駄か、有用か

    アジャイルなソフトウェア開発を行う上で、イテレーションは基本的な特徴であると考える人は多いが、中には、果たして重要なのか、アジャイル方式に価値を加えているのか、余分ではないのか、はたまた無駄ではない���とさえ疑う者もいる。イテレーションがアジャイルチームにとって重要か否かの決定に役立ててもらおうと、InfoQではこの問題の論点を総括した。

  • オピニオン: リファクタリングは必要な無駄

    リファクタリングは、アジャイル開発者のツールキットにおいて、キーとなる技術的なプラクティスの一つだ。リファクタリングはまた、顧客にとっての価値としては目立ったものではない。それはまさしく、リファクタリングの定義自体によるものだ - 振舞いを変えずに、構造 (設計) の変更を行う、と言うものだ。リーン・ソフトウェア開発の世界では、顧客にとっての価値を持たないものは全て無駄であり、そして、顧客は振舞い/機能だけを知覚する。構造ではない。

BT