InfoQ

InfoQ

エディタ毎の記事の表示

Deborah Hartmann Preuss

Deborah Hartmann Preuss is an Agile Effectiveness Coach, Life Coach and Open Space Facilitator living in Karlsruhe, Germany. Deb is passionate about making teamwork valuable and rewarding, and has mentored colleagues and improved software teams throughout her 25-year journey from programmer to coach. She injects excitement and laughter into everything she does. Deb developed and led the InfoQ/Agile editorial team until 2009, and continues to provide active leadership in local and international Agile communities.

全ての Deborah Hartmann Preussに関するすべてのコンテンツ


Deborah Hartmann Preussが書いた最新の記事

生産性のためのコラボレーティブなスペースを設計する

トピック
Collaborative Technologies,
コラボレーション,
リーダーシップ,
チームワーク,
Agile,
マネジメント,
ヒューマンリソース

アジャイルを用いて作業をする場合、つまり、互いに接近して遮るものもなく作業を行う場合、人として健全で効率的な作業スペースを求め、それを主張することはこれまでよりいっそう重要なことになります。そこで、本稿ではチームに関して数多く集められた見識を共有します。これは何人かの経験豊富なアジャイル・コーチたちによって集められたものです。

チームがキュービクルと引き換えにコミュニケーションスキルを得る手助けをせよ

トピック
Collaborative Technologies,
Self-organizing Team,
コラボレーション,
Scrum,
リーダーシップ,
チームワーク,
Agile,
マネジメント

アジャイルの「自己組織化チーム」のパラダイムでは、チームのメンバに新しいスキルが要求されます。この記事では、発展しつつあるチームの自己組織化を壊さずに、新たなスキルを伝えるためのいくつかの戦略を提案します。そして、新しいスキルを身につけるのに役立つ資料のありかを提示しています。

AgileAdvert Video Winners Announced

トピック
VersionOneSoftware,
Story Testing,
Lean,
Agile in the Enterprise,
Google,
InfoQ,
Agile2007,
Agile,
カンファレンス,
コミュニティ,
Fun,
テスト

At Agile2007's Google reception, the audience voted to make the (very sad) clip "Developer Abuse" the number 1 video, thereby making "Matthew" (name changed to protect the innocent) this year's AgileAdvert famous Agilist. Five more videos were also recognized, sporting singing, dancing, a beating, "outside the box" thinking, expletives (deleted), and charming children (not all in one video!)

Deborah Hartmann Preussが書いたNews

リーン+リアルオプション=複雑さとリスクの低減

トピック
顧客要求,
アジャイル技術,
Lean,
Agile,
Risk,
BDD

リアルオプションとは、金融オプション数学に基づく意思決定プロセスである。これは通称「白本」とよばれるExtreme Progamming Explainedにおいて、Kent Beck氏が1999年に言及しているものだ。近年ではアジャイル主義者たちがリアルオプションがアジャイルとどのように交わるのかについて調査してきた。現在はChris Matts氏とOlav Maasson氏が、特にリーンソフトウェアコミュニティに対して発言している。リアルオプションを採用することでリーン開発が改善するというのだ。

ティーチングゲーム-遊びか、まじめなビジネスか?

トピック
Agileの採用,
Agile in the Enterprise,
Agile,
教育,
トレーニング/認証

Tasty Cupcakesティーチングゲーム・ウェブサイトの創始者であるMichael McCullough氏とDon McGreal氏が「楽しみ駆動開発("Fun Driven Development")」に関する記事を公開した。景気は低迷しているが、こういったゲームがトレーニングプログラムから締め出されることはなく、実際、ティーチングゲームはアジャイル実践者が集まって考えを交換する上でのかすがいとなっている。ここではその歴史と、チームにおいてゲームを用いる上でのスタート地点を紹介する。

ScrumBanは進化か、それとも矛盾か?

トピック
Scrum,
Lean,
方法論,
アジャイル技術,
批判,
Agile,
プログラミング

カンバンのワークショップやコース、カンファレンスが現れ、アジャイル実践者たちは、リーンから適用されたこの手法がチームに提供するものを調査している。ボトルネックを明らかにすることから、より多くの"動き"を経験し満足するチームまで、魅力的な利点が挙げられている。しかし、指導者たちは、カンバンののんびりしたアプローチが直ちに障害を取り除くというスクラムの呼び掛けに対する「クリプトナイト」であることを警告する。

自己組織化を導くことは、オーケストラを指揮するようなものか?

トピック
Self-organizing Team,
リーダーシップ,
ケーススタディ,
Scrum,
チームワーク,
Agile,
批判,
マネジメント

伝統的なマネジメントモデルは、自己組織化を妨げることなくどうやってアジャイルチームをサポートするのかということについて、リーダに教えてはくれない。音楽の演奏と「オーケストラの指揮」に喩えられることも多いが、それが適切であると誰もが合意している訳ではない。「指揮者」モデルは優れたプラクティスなのか、それともアンチパターンなのか?TEDトークにおいて指揮者のItay Talman氏が示したのは、これは指揮者が何をしていると考えるかによるということだった。

フォレスターがビジネス向けリーンに関する無料の調査報告を公開

トピック
Business Process Modeling,
顧客要求,
Business Process Management,
Delivering Value,
SOA,
ビジネス,
エンタープライズアーキテクチャ,
Lean,
Agile,
Architecture

フォレスターリサーチは来週のビジネス・テクノロジフォーラムに先んじて、アナリストによる調査報告”リーン、新たなるビジネス・テクノロジ規範”を無料で公開した。リーンをビジネス全体の規範として管理者向けに書かれており、ITへの影響にも触れている。”価値の創造と柔軟性の増加を忘れて、無駄の排除に没頭してはいけない”との注意もある。

女性の皆さん、何か提案をお願いいたします。

トピック
リーダーシップ,
Agile,
Diversity in Teams,
コミュニティ,
カンファレンス,
批判

多様性がイノベーションと優れた業績を生み出していくことは広く受け入れられているが、ITコミュニティのリーダーシップは多くの場合、コミュニティ自身の多様性を表していない。ハイテクコミュニティの多様性をリーダーシップに反映するために、できることは何だろう。例えば、もっと様々なコミュニティがカンファレンスで話ができるように積極的に支援することはひとつの有効な手段ではないか。

ふりかえりについてのふりかえり

トピック
リーダーシップ,
ガバナンス,
Agile,
マネジメント,
エンタープライズアーキテクチャ,
Retrospectives,
補完実践

組織内のどのチームもアジャイルを用いていて、それぞれ局所的な改善を実装するので手一杯だった場合、正式に「IT」ないし「システム開発」と呼ばれるようなより大きな組織では何が起こるのだろうか?これについて巨大なアジャイルプログラムを抱えるコーチが、自分たちの立てた戦略を共有した。これはより大きな組織が全体の動向を把握し、そこから学ぶことで利益を得られるように作られている。Paulo Caroli氏はこれを「ふりかえりについてのふりかえり」と呼んでいる。

スタンフォード大学の研究成果:重度のマルチタスク作業者はパフォーマンスが低下する

トピック
Agile,
リサーチ

スタンフォード大学の研究により、マルチタスク作業が確実に生産性を低下させることが裏付けられた。すなわち重度のマルチタスク作業者はいくつかの標準的なテストで最も悪い成績をおさめたのだ。アジャイル実装者は注意すべきだ。各チームは1人のプロダクトオーナーがついた1つのプロジェクトに対して作業をするよう勧めるのには充分な理由がある。注意力を多くの異なるタスクに分散させるのは、作業をする上で非効率的なやり方なのだ。