GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Vikas Hazrati , 翻訳者 徳武 聡 投稿日 2009年10月8日
フィードバックとは過去の出来事からのアウトプットが未来と潜在的に関連している状況だ。アジャイルでは各ステップでフィードバックを集めたり提供したりすることをとても重要視している。これは品質の良い製品を作り上げるためだ。良いフィードバックによって得られる利益は計り知れないが、Tom Ferguson氏は、チームはフィードフォワードも価値あるツールと見なすことができると助言してきた。フィードフォワードは未来の方向性の観点から、今後のために助言を与えることだ。
Dietrich Kappe氏 は、次のように言うときフィードバックループを相当重要視している。
アジャイル開発の3つの掟は、
- フィードバックループ
- フィードバックループ
- フィードバックループ
氏が説明では、ペアプログラミングを実践することでソフトウエアを素早く定期的にリリースするには、すべてのプロセスにフィードバックが組み込まれている必要がある、ということだ。
Michael Hugos氏はGlenn Vanderburg氏が作成したホワイトペーパーを引用している。このホワイトペーパーはフィードバックループを3つのレベルに分割することを試みている。底辺のレベルを形成するのは次のような低いレベルの実践だ。ペアプログラミングやコーディング標準、単体テストと機能テスト、リファクタリング、シンプルな設計、労働時間は週40時間。その上に位置するレベルを作るのはもう少し広い実践だ。すなわち、システムのメタファ、継続的統合、オンサイト顧客、共同所有、承認テスト、計画ゲーム、小規模リリース。これらの実践を通じてアジャイルプロジェクトは進むべき方向の点からフィードバックを得られる。そして、フィードバックループの3つのレベルの最上位に位置するのは、アジャイルプロジェクトを監視し管理するためのプロジェクトマネジメント活動だ。この活動を通じて、ステークホルダーはプロジェクトが期待通りに進んでいるかどうかを知ることができる。
さらにZachary Spencer氏はフィードバックを受動的と能動的の2つに分類した。氏は受動的フィードバックに対する能動的フィードバックの利点を説き、すべてのアジャイルチームは能動的なフィードバックを収集するべきだと奨めている。氏によれば、
フィードバックを集めるには2つの方法があります。フィードバックを求めること、これは能動的フィードバックです。一方、他の人がすることを観察して得られるのは、受動的フィードバックと言えるでしょう。ほとんどの場合、能動的フィードバックが使いやすい状況と受動的フィードバックが使いやすい状況は異なりますし、それぞれ良い点と悪い点があります。しかし、両方ともに、本当に確かな意思決定を下すために利用しなければなりません。
また、別のところでTom Ferguson氏が言うには、フィードバックは常に過去に焦点を当てているが、頻繁にシナリオを変更するためにアジャイルプロジェクトに前を見ることも必要なのではないか、ということだ。氏の考えでは、
問題はフィードバックの‘バック’の部分です。フィードバックは過去の出来事に焦点を当てる傾向があります。であるからして、限定的で静的なものになります。しかし実際のプロジェクトでは限定的で静的な過去の情報を受け入れる余裕はありません。確かに過去から学びたいとは思いますが、しかし歴史を変えることはできません。こういう困難があるのですから、少しはフィードフォワードを試みてもいいのではないでしょうか。
さらにFerguson氏はフィードフォワードという言葉が作ったのがMarshal Goldsmith氏であるということを説明している。Marshal Goldsmith氏は“フィードバックの代わりにフィードフォワードを”ということを提唱した人物だ。Ferguson氏はフィードフォワードを行う理由を次のように述べている。
フィードフォワードはもっと積極的な観点から生まれます。つまり、みんな一緒にいるんだから互いに助け合いましょう、というような考え方です。こう考えることで人間関係の動的な側面が全体的に変化します。
- 批判的ではありません。
- 過去の失敗にまとわりつく消極的なニュアンスは消えます。フィードフォワードするだけならなんの失敗も起きません。
- 伝達するのも簡単です。将来のことを議論するときは皆、少し緊張がほどけます。フィードフォワードでは個々人の主体性を希薄になり、抵抗が生まれにくいです。
- 素早いのも特徴です。過去の出来事を吟味するのはとても時間がかかります。未来についての良さそうなアイディアを発信する方がよほど早いです。
- 過去は歴史です。今日は現在であり、未来は冒険です。私たちが変えられるのは今日より先のことだけです。過去の失敗に着目することに何の意味があるのでしょう。自分が望む未来について考える方がいいのではないでしょうか。
- フィードフォワードはコーチングと相性がいいです。なので、チームのパフォーマンスを最大化するために必要な人間関係を構築することにも適しています。
- このように自分のパフォーマンスを改善する手助けをしてもらった人は、自身のキャリアのなかでより大きな成功を手に入れるでしょう。
- 成功するプロジェクトの核心はコミュニケーションです。フィードフォワードはコミュニケーションより強力にします。
- なぜ、皆が嫌っている過去のことに時間や労力を使わなければならないのでしょう。
氏によれば、フィードフォワードがもたらすのは、フィードバックのもたらすいかがわしい特性や負のエネルギーではなく、積極的なエネルギーだ。フィードフォワードはチームのメンバの間に素晴らしい関係を生み出してくれる。フィードフォワードの場合は、フィードバックのように特定の個人が引き受けることがないからだ。
Marshal Goldsmith氏が言うには、
リーダはフィードバックを与えるべきではない、あるいは、パフォーマンスの評価は捨てるべきだ、と言いたいわけではありません。日々のやり取りの中で、フィードフォワードがどのようにしてフィードバックよりも効果的になりうるのかを示したいのです。有効性や効率性を別にすれば、フィードフォワードは人生を豊かにしてくれます。“前にフィードバックを受け取ったときどう思った?”とマネージャに尋ねられたら、否定的な返答しかできないのが普通です。しかし、フィードフォワードを受け取ったときどう思ったかを尋ねられれば、役に立っただけでなく楽しかったと答えるでしょう。
このようにフィードバックとフィードフォワードは共に価値があり、プロジェクトとアジャイルチームを正しい方向へ導いてくれる。鍵になるのは、現時点の状況と作業環境においてどちらが適切なのか判断することだ。
世界の先進エンジニアが集結 - QCon TOKYO 2012 早期割引実施中!
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
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
スレッド表示 返信