GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Mark Levison , 翻訳者 笹井 崇司 投稿日 2009年9月13日
Agile Coachingの著者、Rachel Davies氏とLiz Sedley氏により、“Top Ten Tips for Agile Coaches”(「アジャイルコーチの秘訣、トップ10」)という、おもしろいセッションが開かれた。このセッションは「多くのアジャイルコーチができてないこと、トップ10」と呼んでもよかっただろう。
自己紹介をしよう – コーチが初めて(既存の、もしくは新しい)チームにやって来たときというのは、忘れられない出来事だ。コーチが何者なのか、なぜそこにいるのか、そもそもその仕事をする資格があるのかさえ、チームにはよくわからない。こういうときには、年長者(マネージャやチームリーダー、あるいはとても尊敬されている人)から自己紹介をすると、不安をやわらげる効果がある。コーチはその背景や目標についても説明しておくべきである。
アジャイルは宗教じゃない – チームのメンバはアジャイルなんかどうでもよくて、とにかく仕事が完了すること、給料が上がること、そしておそらく昇進することで頭がいっぱいだ。だから、現在取り組んでいる問題を解決するのに役立つことにしか関心がない。私たちはコーチとして、時間をかけて、状況を理解し、話を聞く必要がある。最も重要なのは、チームの懸念を聞いてくれたと感じてもらうことだろう。
敬意を払おう – チームの抱えている問題をすべて解決しようとしてはいけない。どうやって今の状況に至ったのかを理解しよう。言葉には注意しよう。例えば、チームメンバは人であり、単なるリソースや開発者、テスタ、マネジメントというものではないのだ。
一歩離れて見よう – 私たちコーチは、全体像を見ずに、チームが提起した問題に目がいってしまうことが多すぎる。人をどうにか元通りにしようとしてはいけない。 – たいていの場合、彼らは組織のプレッシャーに反応しているだけなのだ。代わりに一歩離れて、システム思考を活用して、そのプレッシャーを見つけよう。そして、そのプレッシャーを解消することに注力しよう。
時間をかけて考えよう – 私たちはついカッとなって問題に反応してしまうことが多い。ムッとして即座に反応するのではなく、立ち止まって、時間をかけて考えよう。他のコーチとも議論しよう。ことによると、一晩考えてみてもよいだろう。
質問しよう、アイデアを語ろう– チームがどのように動いているのか/仕事をしているのかを理解しようとするときには、「どうやって」と「何を」という質問をしよう。Liz氏によると「なぜ」という質問は避けた方がよいらしい。「なぜ」という質問をすると、たいていの人は守りに入ってしまうためだ。「なぜ」という質問は根本原因分析のためにとっておこう。 – 慎重に使おう。シェアすべきおもしろいアイデアがあれば、チームに語ろう。ここで質問をしてはいけない。あなたのやっていることを見透して、不快に感じてしまうだろう。
みんなが避けている重要な問題を切り出そう – 大きな問題は無視されてしまうことが多い。みんなどうせ解決できないと思っているためだ。これを見逃してはいけない。ふりかえりの場を利用して、「みんな避けているけど…」と切り出そう。その問題に少しずつでもチームが取り組んでいけるよう手助けしよう。結果がどうあれ、まだチームの準備ができていないなら、無理に行動させてはいけない。
変化を1つの実験だと考えよう – 人は変化に怯えてしまうものだが、変化を1つの実験だと考えることで、その不安を貴重な経験にすることができる。チームメンバを変化に巻き込むことで、彼らはそれを自分のものにし、小さな変化をすることに慣れていく。ふりかえりは、こうした実験を取り入れるのによいタイミングだ。
チームの実力に合わせよう – いつもチームが直面している最大の問題を解決しようとするのではなく、チームには何を解決する力があるのかを見いだそう。まずは小さな問題を解決することで、自信と喜びを得ることができる。経験を積むにつれ、向上心と実力が養われるだろう。
信念に従って行動しよう – 定期的に、あなたの信頼は傷つき、疑念をもたれることだろう。勇気をもって自分を信じよう。しかし何より、我慢しよう。私たちはチームに非常に大きな変化をもたらそうとしているのだ。私たちはこうした変化をすでに会得しているのだが、チームはまだこれからなのだ。
聴衆からも、いろいろな秘訣が紹介された。
以前の記事:InfoQの「初心 ― 聴くことへの入り口」、ブログのCoaching Workshop
【豆蔵】大好評のため、Jenkins講座を追加開催致します!Jenkins作者の川口氏が講師です。
【ネクストスケープ】.NET、C#のアプリケーション開発者募集
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
去る1月12日、定理証明支援系ツールCoqの初心者向けチュートリアルが開催さ れた(http://kokucheese.com/event/index/23667/)。今後も2月2日 (http://kokucheese.com/event/index/23744/)、2月9日、2月16日と引き続き開 催されていく予定である。本記事では、開催の様子をレポートする。
Neal Gafter氏はOracleによるJava買収の影響に関する議論、Javaにセグメンテッドスタックやメタオブジェクトプロトコルを追加することについての主張、そしてJavaとC#との比較について話をしてくれた。
GoogleはVMをともなう新しい言語であり、JSコンパイラでもあるDartをプレビューした。 InfoQはDartのアプリの構築に貢献する文法の裏側を探った:スナップショット、Isolate、モジュール方式
本記事ではCSPベースの「マルチドメイン・モデル検査ツール」である、PAT(Process Analysis Toolkit)について紹介する。モデル検査は、形式手法(Formal Method)という方法論を基礎とする技術であり、複雑さが増大しながらも安全性を求められる、現在のソフトウェア開発の状況に対する処方箋の1つとして注目されている手法である。
前回まで、Jenkinsの幾つかの側面に注目して解説をしてきました。シリーズ最後の今回は、Jenkinsをサービスとして使う方法を紹介します。
Alloyは、MITにて開発された仕様記述言語であり、ツールによる自動解析を使い、インクリメンタルに形式仕様が書けることが特長である。筆者らはAlloy開発者による、Alloyを使った形式手法入門書を翻訳、今夏にオーム社より刊行した。本記事では、Alloyの簡単な概要と、翻訳書『抽象によるソフトウェア設計』(「Alloy本」)を紹介する。
スマートフォンを中心としたマルチデバイスにおけるタッチユーザーインターフェイスへの対応は、既に必須の項目となりつつある。本記事では、Windows デバイスにおける UX のベースとなっている「メトロ」というデザイン言語を掘り下げながら、既存環境を意識しつつもどのようにタッチユーザーインターフェイス開発に取り組んでいくべきであるかについて解説していく。
No comments
スレッド表示 返信