Jean Tabaka氏による「Collaboration Explained--真のアジャイルチームのためのファシリテーションツール」
Jean Tabaka氏の書いた書籍では、会議などのチーム活動において、ファシリテーションの手法とツールについて具体的かつ実践的に説明しています。8/8(金)、Agile2008の最終日の朝のセッションでは、Jean Tabaka氏自身が本の内容をベースとしたセッションを行いました。
作者 Mark Levison, 翻訳者 安井 力 - (株)永和システムマネジメント 投稿日 2008年7月9日 午前3時50分
チームが新しい習慣を身に着けようとして、なかなかうまくいかないときがある。習慣とは、ユニットテストを書く、コンパイラの警告をなくす、ビルドを壊さない、などのことだ。どうしたら、チームにこうした習慣を植え付けることができるだろうか?Clint Shankは(リンク)メンバーを移行させるために、あるゲームをデザインした。
そしてErik RamfeltはHudson用の「継続的結合ゲームプラグイン」(リンク)を書いた。開発者が良いことをするためには、ときに後押しが必要であるという前提にたったゲームである。
以前、ビルドを壊してしまう人がいるという問題がありました。そういう人を助けるために、いくつかの方法を試しました。交代でビルド監視役をつとめたり、ビルドを壊したら貯金箱に1ドル入れる、などです。いずれもネガティブな、懲罰的なものでした。それでは、ビルドを壊さなかった開発者に褒賞を与えるようなやり方はどうでしょう?作業を小さな単位に分割して早く頻繁にチェックインするという(リンク)ベストプラクティスをきちんと守っている開発者に報いるようなやり方はどうでしょうか?
Clintは、Darin Cumminsの「開発ゲーム」の記事(Agile Development Conference 2004)を読んだ。そしてビルドで問題を起こさなかった開発者を報いて、問題を起こしたら罰するようなゲームを思いついた。
Ericの実装によると、開発者のカルマは以下のように計算される。
ゲームのルール
- ビルドを壊したら-10ポイント
- すでに壊れているビルドを壊したら0ポイント
- ビルドで問題が何もなかったら+1ポイント(不安定なビルドにはポイントがつかない)
- 新しいテストが失敗するごとに-1ポイント
- 新しいテストが成功するごとに+1ポイント
他のプラグインに依存しているルール
Clintは以下のような注意を付け加えている。インチキをする人(たとえば、1時間ごとに無意味にチェックインするなど)が出ないように気をつけること。ときどきポイントを0に戻して、誰でもいつか勝てるチャンスが巡ってくるようにすること。
Scrum Developmentで(リンク)このことが話題になり、いくつかの懸念点が指摘された。Graeme Matthewが指摘したのは、得られる褒賞が大きすぎると、スコアを上げることに熱中してしまい、顧客へ価値を提供することがおろそかになってしまうかもしれないという点だ。Ilja Preussは以下のように述べた。
もうひとつ、気をつけるべき点があります。外的なモチベーションは、内的なモチベーションと激しく対立してしまうのです。つまり、チームの内的モチベーションが十分なときに外的モチベーションを導入すると、状況を悪化させてしまうかもしれないのです。
最後にPete Deemerが以下のように述べた。
個人にインセンティブを与えるような複雑なフレームワークは、「自分」思考を増長し、「われわれ」(チーム)思考を阻害してしまうと、私は思います。(「われわれ」思考は、Scrumで「隠れた推進剤」のひとつに数えられています。)そのようなやり方はミクロレベルでの最適化を招きます。ミクロレベルの最適化は、全体的な最適化の障害となります。それにまた、顧客にサービスを提供するうえでは不必要な、儀式や考え方がいろいろと生まれてしまうでしょう。
原文はこちらです:http://www.infoq.com/news/2008/07/rewards-improve
Jean Tabaka氏の書いた書籍では、会議などのチーム活動において、ファシリテーションの手法とツールについて具体的かつ実践的に説明しています。8/8(金)、Agile2008の最終日の朝のセッションでは、Jean Tabaka氏自身が本の内容をベースとしたセッションを行いました。
Agile2008の4日目となる8/6(木)の8:30から、Hubert Smits氏による「ゲーム・デザイン・ワークショップ」がおこなわれました。ゲームと言っても単なる遊びではなく、「フレームゲーム」と呼ばれる、グループでの情報収集や意志決定、また教育やトレーニングの教材として使えるいろいろなゲームです。
eBayが日々挑んでいる主要なアーキテクチャの勢力は、スケーラビリティです。これはアーキテクチャや設計に関するあらゆる意思決定を特徴づけたり、駆り立てたりします。
Bean Validationフレームワークの初期ドラフトに関する以前の記事に続き、InfoQは専門家グループが求めているコミュニティの関与と提案について理解を深めるため、Emmanuel Bernard氏と対談しました。
ポーカーは他のトピックにも広く適用できるような数少ない教えを私にもたらしてくれたと信じています。実際私はソフトウェアを開発すればするほど、これら二つの仕事は非常に似ていると言う確信の度合いを深めています。
恒例の「バーチャルパネルセッション」で、InfoQは新しいOASIS BPEL4People技術委員会の代表と対談をし、この作業が何故必要であるかについて彼らのフィードバックを得る機会を得ました。
ドメイン特化言語は最近非常に人気が高まっている話題です。これは恐らく、Rails現象に起因していると考えられます。Railsの人気と、Railsにおけるドメイン特化言語(以降、DSL)の大規模な使用は、DSLに対する広範な関心を呼び起こしました。
Rubyには、Rubyコミュニティの内外で広く知られている誤解が一つある。Rubyにはデバッガがないという誤解だ。しかし、Rubyにデバッガが無いということは誤解なのだ。実際のところ、Rubyにはデバッガ用のツールがある。
No comments
返信