GAE開発の落とし穴
Googleのクラウド環境をつかったGoogle App Engineによる開発するにあたり、初めての試みで苦悩する開発者達の経験をもとに、各開発フェーズにあわせて問題点やどう解決したかをご紹介します
ブックマークされました!
ブックマークがエラーになりました。もう一度お願いします。
作者 Mark Levison , 翻訳者 和智 右桂 投稿日 2010年2月4日
デイリースタンドアップを良いものにするためには、どのようなコツやテクニックがあるだろうか。ほとんどのアジャイルチームではデイリースタンドアップが実施されている。しかし、Joakim Karlsson氏は次のように言う。 「世の中のデイリースタンドアップのほとんどは、はっきり言って退屈なものです。」全員が参加を強制される単なるミーティングと化しており、ひどい時には日次に加えて伝統的な週次ミーティングにも参加しなければならないのだ
Paul Wynia氏は、プロジェクトリーダがアジャイルのトレーニングを受けたこともアジャイルを経験したこともなく、デイリースタンドアップを日次進捗ミーティングとして扱った例を挙げている。
そのリーダが各参加者に対して詳細に説明させたのは、各機能、バグ、前日に行った認識合わせとこれから行う見積もりを含む作業でした。参加者は作業詳細がびっしりと書かれたメモ帳を持参し、リーダから割り当てられる新しいタスクもそこに記入しました。たった5名のチームにおいて、リーダはデイリースタンドアップを30分から40分も続け、恐ろしく退屈なものにしてしまったのです。
Wynia氏は続けて、ミーティングは10分から長くても15分に抑えるように勧める。さらに氏は、コーチを行っているチームに対して、もし制限時間がオーバーしたらそこから立ち去ってもよいと言う。これはスクラムマスタに対して、ミーティングの実施方法に問題があることを伝えるためだ。
Joakim氏は次のように勧める。
Mike Cohn氏の勧めによれば、チームはデイリースタンドアップをタスクボードの前で行い、作業中のストーリーを指差すよう話し手に頼むのが良いという。加えてCohn氏が述べているのは、チームが9人以上になるとチームの別のメンバが何について作業しているのかが追跡できなくなりやすいということだ。
Drew Stephens氏は、自分たちのチームが「ユーザストーリに焦点を絞ったスタンドアップ」を用いていると報告している。ほとんどのアジャイルチームと同様に、Stephens氏のチームもいたって伝統的なスタンドアップから開始したのだが、チームが大きくなるに伴って苦労したのだ。
ひとつのストーリーについてチーム全体を巻き込む時間がなくなってしまったので、ストーリーを平行させはじめました。同じく気がついたこととして、多くのストーリーが以前よりも長く完了しないままとなり、われわれが「タスクテール」と呼ぶものができ始めたということです。(タスクテールとはストーリが停滞し、はっきりしないタスクがいくつもだらだらと何日も続くことを指します。)タスクテールが発生する原因として、主要なものを2つ特定しました。
- コードの品質が低く、結果としてバグがぽたぽたと常に流れ出していることにQAが気づくことになる。
- ストーリーが完了に近づいているように見えるが実は終わっていない時に、開発者が他のストーリーに移ってしまう。
このような事実によって、私たちのスタンドアップミーティングは混乱し始めました。ある人がその前の人とは異なるストーリーについて語ることが常となり、これによって各ストーリーの現在の状況を把握するのが難しくなったのです。アクティブなストーリーを完了させるのに何が必要なのかに集中する代わりに、それぞれが何をしているのか、あるいは何をしようとしているのかに注意が向けられました。これはわずかな違いですが、徐々に問題となっていったのです。
彼らの取った解決策はウォークスルーだった。進行中のストーリーに対してウォークスルーを行い、そのストーリーに関して作業したことのある人がそれぞれストーリーに関する質問に3つ答えるのだもし1つ以上のストーリーについて作業していたら、それらすべてについて話すことになる (これは潜在的な危険な匂いだ)。スクラムマスタは誰が話をしたかを記録しておく。もし終わるまでに誰かが話をしたとしたら、それはおそらく、妨げとなるものがあるということなのだ。
Artem Marchenko氏はいくつかの提言をしている。
Henrik Larsson氏とのインタビューにおいて、 Jason Yip氏 (「It's Not Just Standing Up: Patterns of Daily Stand-up Meetings」の著者)はスタンドアップに対する見方がどう変わったかを記している。
かつては状況について見ようとしていました。しかし、今では約束について見るようになってきました。これは主にMike Cohn氏が書いたものによる影響です。かつては、問題解決であると考えていましたが、今の好みは、タスク/ストーリーボードが使える時には「ウォーク・ザ・ボード」スタイルを強く好むようになっています。また以前は、仕事を終わらせようとしているのか、単に忙しくしようとしているだけなのかに注意することの重要性を強調する傾向がありました。
それでも、何年経っても全く変わらない側面もありました。それが、儀式の活気を保つことやリーダに対して報告するのではなく、リーダと共有することの重要性です。
あなたのチームでは、どのようなことをするとうまく行っただろうか?
以前のInfoQの記事に「よい朝会はどう作るか」がある。
【豆蔵】「オブジェクト指向を現場で活かすリファクタリング入門」新規講座キャンペーン中
【ネクストスケープ】.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
スレッド表示 返信