マルチタスクで仕事は遅くなる
新しいオーディエンスとしてアジャイル（またはスクラム）のストーリに参加した場合、もしメンバがチームの仕事にフルタイムで専念できたらチームはもっともっと良くなるという、巨大で厄介な障壁に悩まされることがある。よくあることだ。我々は特別な問題、特に危機的な状況を取り扱うため、 "専門家チーム" や "スワットチーム"として召集される。けれども我々の組織は、独立して業務を遂行することができるスキルを持った人の集まり、というモデルを好むようになり、メンバは複数のプロジェクトに同時にアサインされる。今では、多くのことをいっぺんに実行することがデファクトソリューションになってしまった。これが"乏しいリソース"を最も効率的な使う方法と考えられている。つまり、なんでもこなせるスペシャリストを、少人数（少したりないくらい）でチーム編成するのである。 アジャイルモデルはこれを覆した。 我々は一定時間それぞれの
ペアプロにメタファ適用
今回、一部の人にはイメージつかみにくいかもしれん。できるだけわかるようには書きますが、それでもわからなかったら勘弁。いきなり逃げ腰かよ＞俺。 「XPのプラクティスの中で、最も抵抗の強いものは？」 という質問を投げた場合、「ペアプログラミングだけは勘弁」と即答する方は相当数いるであろうと予測しております。 というのも、ペアプロって他のプラクティスと抵抗のベクトルが逆向きにかかってくるんですよ。 例えばオープンスペース（オンサイト顧客）とか最適ペース（週４０時間）といったものってのは「開発者は望んでいる、でも顧客や会社には抵抗される」という類のものだと思うんです。いわゆる外部抵抗要因。 ところが、このペアプロだけに関しては、「開発者側から非難の声があがる」ということがあるんです。完全な内部抵抗要因なんですな。まぁペアプロ自体にも外部要因はありますが（例：人なんか増やせない）ここでは話を別にしま
XP — 究極の仕事術 ?
なおここ1〜2年では盛んに「アジャイル」開発というキーワードが唱えられるようになった。 アジャイルもXPのように環境の変化に柔軟に対応した開発を進めようという考え方で、 XPや関連する開発プロセスを包括する概念である。 作業者・作業環境に重きを置く XPはここのところソフトウェア開発の主流となっているオブジェクト指向開発の流れを汲み、 繰り返し開発によるシステムの洗練、設計を単純化することにより思わぬ誤りを防ぐ、 一定間隔でコードのリファクタリング(見直し、再設計)を行なう、 など特定の枠組みに縛られないフットワークの軽い手法だ。 さらにXPに特徴的なのは、ソフトウェアを書くのは人間である、 という当り前の事実を重視していること。 ペアでプログラミングをすることで誤りを防ぐとか、 作業は週40時間までにして頭の疲労を防ぐ、 あるいは概念やコードを共有化してチームの一体感を高めるなど、 人間
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Role of Project Managers in Agile
http://www.ogis-swe.jp/process/am-res/am/index.html
http://www.ogis-swe.jp/process/am-res/am/practices.html
IBM Developer
