開発者の視点から見た開発手法!!!

開発者による開発方法論は、Ruby on Rails アプリケーション開発に次のパスを使用することです。

1. 目標、役割、機能のリストを書き留めます。

• 目標 – プロジェクト全体の目標は何か – ビジネスなど。これはどの機能が重要かを判断するのに役立ちます
• 役割 - サイトを使用するのは誰ですか - 訪問者、ログインしているメンバー、管理者?サイト上の同じ情報について、人によって見解が異なることはありますか?
• 機能 - サイト上のインタラクションの基本的なカテゴリは何ですか?例: ユーザー: 登録、フォーラムの使用、ブログ。管理者: ユーザーコンテンツのモデレート

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

• ストーリーは、特定のユーザーの視点から見たインタラクションの単一のスレッドを表すため、フィーチャーとは異なります。
• 「○○として、○○できるように○○したい」という形でストーリーを表現するのが一般的です。これにより、3 つの重要な質問に答える必要があります – これは誰のためのものですか?彼らは何がしたいのでしょうか？なぜ彼らはそれをやりたいのでしょうか？
• この形式でストーリーを完了できない場合は、これら 3 つの質問のいずれかに対する答えがまだない可能性があるため、ストーリーを実行可能にする前に、答えを得るために少し考える必要があります。
• 例: 「管理者として、サイト上でユーザーが投稿したコンテンツの品質を向上させるために、ユーザーをフォーラムから禁止したいと考えています。
• これらのストーリーをノートカードに書き留めてください。これは、見積もりと優先順位付けに役立ちます。

3. ストーリーを見積もる

• 見積もりはそれ自体大きなテーマですが、基本的な考え方は、特定のレベルの労力を各ストーリーに関連付けることです。
• 最も一般的なスケールは 0/1/2/3/4、0/1/2/4/8 です。これはそれほど重要なことではないと思いますが、何かを選んでそれに固執してください。
• 見積もりの正確さにこだわりすぎないでください。ストーリーを完了するまでにかかる時間にはさまざまな要因が影響するため、ストーリーの複雑さの小さな違いは雑音の中に埋もれてしまいがちです。
• ここでの目標は、REST コントローラーを使用して単純なモデルを作成するストーリーなど、労力の少ないものと、アプリケーションを困難なサードパーティ API とインターフェースするなどの労力のかかるストーリーとを区別することです。あまり馴染みのないテクノロジーを使用する必要があるストーリーです。
• 各カードに見積もりを記入します。

4. ストーリーに優先順位を付ける

• ストーリーに取り組みたい順にカードを並べ替えます。
• 実際にこの決定を下せるのは製品所有者だけです。期限、ユーザーテスト、ビジネス価値など、優先順位付けには多くの事柄が関係します。見積もりは機会費用を明らかにするため、優先順位付けと大きく関係している可能性があります。おそらく製品所有者は詳細な管理者ダッシュボードを本当に望んでいるかもしれませんが、それを機能させるためのすべてのストーリーが合計 40 ポイントである場合、この機能だけに 1 か月を費やす価値があるでしょうか。プロダクトオーナーはまだストーリーを望んでいるのかもしれない
• 発売するのに最低限必要な製品に当てはまらないストーリーはありますか?その場合は、それらを下に移動する必要があります。機能するアプリをできるだけ早く完成させて、ユーザーの目の前に公開できるようにしてください。
• この時点で、私は通常カードを Pivotal Tracker に移動しますが、ペンと紙を好む人をたくさん知っています。

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

• キュウリから始める サイトとのユーザーの対話を最初から最後までカバーする Cucumber 機能を作成します。未定義のステップに到達したら定義します。最初の失敗に遭遇したとき、アプリにはない望ましい動作があることがわかります (空のアプリには定義されていないため、これは最初はすぐに起こります)行動が多い）。
• ユーザー インタラクションの重要な部分である Javascript インタラクションがある場合は、Cucumber に @javascript タグを使用してこれらをテストさせるようにします。
• Rスペックに進む こうなってほしいと思う動作のテストを書きます。
• コードを書いてください 仕様に合格するコードを記述します。これにより、ルーティングから UI、モデル、データベース スキーマ、コントローラーに至るまで、アプリケーション全体を確認することができます。テストで指示された順序でこれらのコードに取り組みます。
• キュウリが通過するまで繰り返し、ストーリーは終了です。
• デザインが完了したと仮定して、CSS スタイルを修正する良い時期です。一人で作業している場合、またはデザイナーなしで作業している場合は、ストーリーのコーディングを開始する前に、紙または Balsamiq モックアップなどで UI をワイヤーフレーム化してみるのが好きです。

6. 話を受け入れる

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

6.完了するまで繰り返します

これが私のやり方です。これは決して物事を行う唯一の方法ではありませんが、Rails で物事を行うための非常に一般的な方法です。アジャイル推定の価値や、Cucumber 対 Steak や RSpec 対 Test::Unit などの特定のテクノロジーの価値については、十分な議論があると思いますが、ほとんどの Rails 開発者は、適切なワークフローが次のとおりであることに同意するでしょう。 1)単一のストーリー 2) テストを作成します。 3) 完成させます。 7. 導入

スケーラビリティ、稼働時間、費用対効果、その他多くの要因を考慮して、アプリケーションをクラウドにデプロイすることをお勧めします。私たちは、Heraku、Rackspace、AWS などのクラウド上でのデプロイメントの専門家です。

ツール :- Capistrano、Apache、Passenger、Heraku、GIT/SVN(主にGITが使用されます)

8. 導入後のサポート

アプリケーションが稼働すると、エンド ユーザーが快適なエクスペリエンスを享受できるように、常にアプリケーションをサポートする必要があります。当社は開発するアプリケーションに AMC を採用し、新機能の拡張、バグ修正、24 時間 365 日のサーバー メンテナンスに対応するリソースを確保しています。つまり、これにより、開発したアプリケーションも適切に管理および保守されることが保証されます。

ツール :- BugZilla、Redmine、Pivotal Tracker、ヘルプデスク