アジャイル開発手法
Railsアプリの構築

目標、役割、特徴のリストを書き出す

  • 目標 - プロジェクト全体の目標は何か - ビジネスとそれ以外。これにより、どの機能が重要かを決めることができる。
  • 役割 - サイトを利用するのは誰か - 訪問者、ログインしているメンバー、管理者？サイト上の同じ情報でも、人によって見方が違うのか？
  • 特徴 - サイト上でのインタラクションの基本的なカテゴリーは何か？例えばユーザー：登録、フォーラム利用、ブログ作成、管理者：ユーザーコンテンツの管理
 

ストーリーのリストを書く

  • ストーリーは、特定のユーザーの視点からのインタラクションの単一スレッドを表すため、フィーチャーとは異なります。
  • として、私は○○できるように○○したい」という形でストーリーを表現するのが一般的だ。これでは、3つの重要な質問に答えざるを得ない。彼らは何をしたいのか？なぜそれをしたいのか？
  • このような形でストーリーを完成させることができない場合は、これら3つの質問のうち1つに対する答えがまだない可能性が高いので、ストーリーを実用的なものにする前に、答えを得るために少し考える必要がある。
  • 例：「管理者として、フォーラムからユーザーを追放したい。
  • これらのストーリーをノートカードに書き留めてください。これは、見積もりと優先順位付けに役立ちます。

ストーリーを推定する

  • 見積もりはそれ自体大きなテーマですが、基本的な考え方は、特定のレベルの労力を各ストーリーに関連付けることです。
  • 最も一般的なスケールは0/1/2/3/4、0/1/2/4/8だ。これは非常に重要なことだとは思わないが、何かを選んでそれにこだわることだ。
  • 見積もりの正確さにあまりこだわらないでください。ストーリーを仕上げるのにかかる時間にはさまざまなことが影響するので、ストーリーの複雑さによるわずかな差はノイズに埋もれてしまいがちだ。
  • ここでのゴールは、RESTコントローラーでシンプルなモデルを作成するストーリーのような、労力の少ないものと、アプリケーションと難易度の高いサードパーティAPIとのインタフェースのような、労力の多いストーリーを区別することです。
  • 各カードに見積もりを記入します。

ストーリーに優先順位をつける

  • ストーリーに取り組む順番にカードを並べ替える。
  • この決断を下せるのはプロダクトオーナーだけだ。優先順位の決定には、納期、ユーザーテスト、ビジネス価値など、多くのことが関係する。見積もりは、機会費用を明らかにするため、優先順位付けと大いに関係があるかもしれない。プロダクトオーナーは、詳細な管理者ダッシュボードが本当に欲しいのかもしれない。しかし、その機能を実現するためのストーリーが全部で40ポイントあるとして、この機能だけに1ヶ月を費やす価値があるのだろうか？プロダクトオーナーはまだそのストーリーを望んでいるかもしれない。
  • 立ち上げ可能な最小限の製品に当てはまらないストーリーはありますか？もしそうなら、下に移動させるべきだ。できるだけ早く機能するアプリを完成させ、ユーザーの前に出せるようにしましょう。
  • この時点で、私は通常カードを Pivotal Tracker に移動しますが、ペンと紙を好む人をたくさん知っています。
 

最初のストーリーを完成までテストドライブする

  • Cucumberで始める ユーザとサイトとのインタラクションを最初から最後までカバーするCucumberの機能を書く。未定義のステップをその都度定義していき、最初の失敗にぶつかった時に、あなたのアプリにはない、あなたが望む動作があることを知るのです（空白のアプリにはあまり動作がないため、最初はこのようなことはすぐに起こるでしょう）。
  • ユーザー インタラクションの重要な部分である Javascript インタラクションがある場合は、Cucumber に @javascript タグを使用してこれらをテストさせるようにします。
  • Rspecへ進む 望む動作のテストを書く。
  • コードを書く 仕様を通すためのコードを書く。これは、ルーティングから UI、モデル、データベーススキーマ、コントローラに至るまで、 アプリケーション全体を対象とすることになります。テストに指示された順番で、これらのコードに取り組むことになります。
  • キュウリが通り過ぎ、話が終わるまで繰り返す。
  • デザインはできていると仮定して、CSSのスタイリングを修正する良い機会だ。もし私が一人で仕事をしていたり、デザイナーがいない場合は、ストーリーのコーディングを始める前に、紙の上かBalsamiq MockupsのようなものでUIのワイヤーフレームを作成したい。

私たちは物語を受け入れる

  • その話は受け入れられますか？それはあなたが望んでいたとおりに動作しますか？そうでない場合は、戻って、想定どおりに機能するようにする必要があります。事前に Cucumber テストを作成しておくと、このような事態を防ぐことができます。
  • テストはすべてパスしたか？ビルドを壊していないよね？もしそうなら、壊した部分を修正する必要がある。
  • 自分の仕事を客観的な目で見るのは難しいかもしれない。

終わるまで繰り返す

  • これが私のやり方です。決してこれが唯一のやり方というわけではありませんが、Railsでは非常に一般的なやり方です。アジャイル推定の価値や、Cucumber対Steak、RSpec対Test::Unitのような特定の技術の価値については、それなりの議論があると思いますが、ほとんどのRails開発者は、適切なワークフローは次のとおりであることに同意するでしょう：

1) 一つのストーリーを特定する

2) テストを書く

3) 完成させる。

私たちはお客様の最新化をお手伝いします
アプリケーションポートフォリオ

プロジェクトを見積もる

ビジネスをよりスムーズかつ迅速に進める方法を学ぶ

専門家に相談してください

RailsCarma サービスに興味がある

お問い合わせ
jaJapanese
en_USEnglish de_DEGerman fr_FRFrench es_ESSpanish it_ITItalian sv_SESwedish jaJapanese