GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。

作者 Prasad Prabhakaran , 翻訳者 徳武 聡 投稿日 2010年9月8日
この記事ではアジャイルスクラムプロジェクトの独自性を明らかにします。また、成功するチームに必要な特徴を特定します。そして、効果的なスクラムチームを作るには、介入をする必要があると結論づけます。
下記のようないくつかの点がアジャイルプロジェクトと伝統的な手法に基づくプロジェクトの間に違いを生み出します。
伝統的なプロジェクトでは、チームは開発環境を構築するのにたくさんの時間を使います。一方、アジャイルチームの場合、最初の1時間で何かを生産できる体制を構築しなければなりません。私たちの経験では、開発環境構築に関する文書がないことが環境構築に時間がかかる主要な原因です。また、環境構築に手動で行わなければならない作業がいくつか含まれているのも大きな原因です。コーディングを開始し、チームの作業を統合するために、スプリント0では、開発者に必要なことはどんな小さなことでもすべて文書化する必要があります。
この点に関しては早めに失敗しましょう。私たちが学んだのは手動のビルドは不安定になりがちで、特定のマシンに依存しやすいということでした。また、手動ビルドで時間を失うということは、その分開発やテストの時間を失うことでもあります。本当に小さいプロジェクト以外では、ビルド自動化はとても重要です。私たちが感じたのは、ビルド自動化を実現するのに時間がかかるとしても、その時間は後で取り戻せるということです。また自動化されたビルドプロセスがあれば、そのビルドプロセスがプロジェクトのすべてのメンバで共有できる標準化されたビルドプロセスであることを簡単に保証できます。ビルド自動化に関して、私たちが使ったことのある主要なツールはAnt、Maven 、Nantです。
私たちが過去の経験から学んだことは、何週間も経ってから他のチームのメンバのコードを取り込むことは大惨事の一因だということです。自動化されたビルドが配置できたら、次は継続的統合です。もちろんビルド自動化と継続的統合はバージョンコントロールシステム(もっときちんとした印象的な名前で言えばソフトウエア構成管理)があることが前提です。統合上のエラーを発見したら、すぐに修正できること。これが学習した大事なことです。継続的統合では、私たちはCruiseControl、CruiseControl.Net、そしてBambooを使いました。
要求や優先順の変更が頻繁に発生するとても流動的な環境で複数のメンバと働く場合、昨日の作業が今日どうなっているかをはっきりさせることが重要です。また、私たちはこのような状況下で統合上のエラーについても課題を抱えていました。この厳しい状況下で私たちが学んだ実践は単体テストを実施し、コードの変更が既存の機能を損なっていないか確かめることです。また、コーティングを始める前に単体テストケースを書くことも始めました。私たちが単体テストで使ったツールはJUnit (そしてNUnit、HTTPUnitのようなxUnitツール)、そしてMockObjectsです。
伝統的な環境では、統合を行うまでは個々人が自身のコードベースを保守します。しかし、アジャイルのコードの所有の考え方では、すべてのコードはすべての開発者に属し、必要だと感じたら自由にコードを改善できます。ある期間、私たちのコードは奇妙な動きをしていました。私たちはこれをリファクタリング(Martin Fowler氏の同じ名前の書籍のおかげでリファクタリングという言葉は一般的になりました)を行うことで解決しました。リファクタリングを端的に説明すれば、不要な機能変更を伴わずに、コードの構造を改善してコードの透明度を高めることです。また、私たちはリファクタリングをする前に安全網として単体テストを準備することを学びました。Eclipse、NetBeans、IntelliJ IDEA 、Visual Studio.NETが私たちがリファクタリングに使ったツールです。
アジャイルプロジェクトでのエンジニアリングの実践には、はっきりとした独自性があることは明白です。したがって、チームはアジャイルを実践するにあたり、事前の準備が必要です。
アジャイルチームは通常のチームと働き方が違います。アジャイルチームは効率的で効果的なコミュニケーションと作業の高速実施に大きく依存します。したがって、ソフトスキルの必要性が大きくなります。このことに気付き、これらのスキルや特質の利用を積極的に促進すれば、アジャイルチームをより意味深く生産的にできます。
自己組織化はたいていの場合、好意的な反応や否定的な反応、開発と調査のバランス、いくつもの相互作用などの基本的な材料によって成り立っています。私たちの経験から言えば、多数の文化的社会的問題が原因で、チームは正しいフィードバックが与えられなかったり、コミュニケーションを避けたりする場合があります。
私の経験ではこれは‘神話’のままです。私たちは常に‘予想症候群’を患う傾向があります。つまり、計画すればするほど、予測が可能になるということです。
チームは優れた規律と責任を負う能力、誓約をする能力、説明責任とオーナシップを持つ必要があります。
チームが持たなければならない主要なスキルのひとつは、支援を求めるスキルであり、レビューを求めるスキルです。私たちは‘エゴ’が大きな障害として除外された場合も経験しました。
責任を負うこと、誓約をすること、協調して働くこと。これらのことは軽く見られる場合があります。私たちの経験から言えるのは、これらのことを生み出すには外部からの介入が必要な場合もあるということです。
一般的には無視される傾向にあるものの間違いなく大事なスキルとして、自発的に物事を進める能力、厳しい環境でも仕事を楽しめる能力、新しい状況や枠組みに簡単に適応する能力が挙げられます。
ほとんどのプロジェクトは分散しています。つまり、顧客とサービス提供者の間に協調して開発をするスクラムがあるということです。このような文脈では多様性を管理する能力、時間管理能力、交渉術やリーダシップがとても重要です。
高い生産性を発揮する上出来なアジャイルプロジェクトを実現するには、チームはより熱狂的に仕事をする必要があります。また、自分が年長者であり、専門家であるということに関わらず同僚から学ぶための正しい態度を身につけなければなりません。そして、大胆不敵に振る舞うことを保証するための安全網が必要です。こうすることで本当の仲間意識が芽生えます。‘自分にとって役に立つか’を考えるよりも仲間意識があるほうが、チームの目的への集中力が高まるでしょう。
私の経験や観察から言えるのは、アジャイルプロジェクトで高度に生産的に振る舞うために必要なスキルは伝統的なプロジェクトに必要なスキルとは違うということです。この記事では優れたチームにするための技術的なスキルや振る舞いを特定しました。これらの‘デルタ’特質を獲得した人はだれでも、正しい技術的なスキルや振る舞いを身につけて、アジャイルプロジェクトで効率的に働くことができるでしょう。下の一覧はスキルの要約です。
|
役割 |
技術的なスキル(各プラットフォームでの) |
振る舞いスキル |
|
開発者 |
CRUD処理、開発で利用しているフレームワークの他のレイヤに対する調和 単体テスト (ツールはNUnit、JUnit) コード網羅率の概念とツール コードレビューの概念とツール 継続的統合とツール リファクタリングの概念 「コードのにおい」の概念 スクラム |
コミュニケーション 協調 時間管理/計画 思考 対立の管理 変更/柔軟性対策 意思決定 チームワーク/チーム作成 ストレス管理 問題解決 リーダシップ 交渉術 |
|
品質保証部門 |
作業完了 -> 受け入れ条件の定義 テスト管理 自動化/スクリプティング 環境構築 データベースの概念 |
開発者と同じ |
|
スクラムマスタ |
スクラム テンプレートとその使い方 プロジェクト管理ツール 継続的統合ツール 開発環境構築 |
開発者のスキルと + 調停能力 |
Prasad氏はIT業界で10年間の経験があります。氏が初めてアジャイルに触れたのは2005年のMicrosoftのプロジェクトでした。それ以来、GE、Cisco、Cokeというような企業でアジャイルの開発やコーチング、コンサルティング、教育に従事しました。最近では、氏はSymphony Servicesのアジャイルラボでマネージャとして働いています。Symphonyでは40%のプロジェクトはアジャイルに関連があり、2004年から重要なビジネス価値をアジャイルを使って顧客に提供しています。連絡先pprabhak@symphonsysv.comです。
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
スレッド表示 返信