アジャイル開発は、特にモバイルアプリの開発に役立ちます。 アジャイル手法は、お客様に継続的なフィードバックループを提供します。 Sourcebitsモバイルアプリの設計および開発クライアントは、2〜3週間ごとにマイルストーンを確認します。 彼らはプロジェクトの最後まで待たされることはありません。 モバイルアプリのアジャイル開発は、クライアントがプロジェクトの成功を確実にするために、方法のあらゆる段階でフィードバックを提供することを意味します。 -Sourcebits 、CTO、Joe Chen
モバイルプラットフォームの開発には、ライフサイクルのほとんどのフェーズに適用される重要な特徴があります。
- 動的な市場への製品の短納期の必要性、さらに継続的な更新。
- 世界中の多数のユーザー。
- 利害関係者の特定が困難であることを含め、アプリケーション要件の特定が困難。
- ユーザーのニーズと期待が変化する可能性が高いため、開発中に変更を加える必要がある。
- 急速な技術進化-新しいデバイス、OSリリース、PL、モバイル通信、IoTなど
これらの特性を満たし、リスクを軽減し、モバイル開発のプロセスを合理化するために、アジャイル手法は、 適応 （頻繁な変更の許容）、 反復増分 （各反復での顧客からのフィードバック、および複数のリリース）、 協調 （高密度）で広く使用されています開発者、顧客、エンドユーザー間のコラボレーション）およびシンプルな （理解、変更、および改善が容易な ）開発アプローチ。
アジャイル
アジャイルは、顧客と協力して自己組織化された専門家チームが価値ある作業機能を継続的かつ迅速に提供することにより、ソフトウェア製品を開発するための一連のアプローチです。
アジャイルは、ライフサイクルの反復モデルとスパイラルモデルを組み合わせたバージョンです。 反復モデルから取得した作業ソフトウェアの既製フラグメントの段階的な開発と可用性+ヒューマンファクターの主要な役割とスパイラルモデルから取得したリスクの分析。
アジャイルの利点、および企業がアジャイルを使用する理由は、アジャイルの状態 、 CHAOSレポート 、 アジャイルの定量的評価などの多くの有名な研究でよく説明されています。
アジャイルの状態 ：アジャイルが使用される理由
アジャイルのコアアイデアは、アジャイルマニフェストと呼ばれるドキュメントで提示されました。 また、アジャイルの12の特定の原則が含まれています。 両方のドキュメント（およびその翻訳）の全文は、 http：//agilemanifesto.orgで入手できます。
モバイル開発向けのアジャイル
前述のように、アジャイルを使用すると、モバイル分野の持続不可能なニーズにプロセスを適合させることができます。 アジャイルは、市場を理解し、製品を構造化し、短期間でリリースする柔軟性を提供します。
過去数年にわたって、モバイル分野での使用に適した多くのフレームワークが開発されてきました：Mobile-D、MASAM、Hybrid、Scrum、SLess。
モバイルソフトウェアのアジャイル開発方法論の進化（ Image source ）
スクラムとSLeSSは最も現代的ですが、SLeSSの基礎は同じスクラムです。 アジャイルをモバイル開発に適応させる最初の試み-Mobile-D-も、特にXPエンジニアリング手法の要素が含まれているという理由で興味深いものです。
スクラムとXPについては、後で詳しく説明します。
スクラム
スクラムは、製品が固定期間の一連の反復として作成されるアジャイルメソッドの1つです。 この手法は、開発プロセスの品質管理、チーム開発環境でのタスク管理に焦点を当てています。
一般に、スクラムは短いイテレーション（通常2〜4週間）でプロジェクトに取り組むことを含みます。各イテレーションはプロジェクトの縮小版であり 、機能の向上に必要なすべてのタスクを含みます。
スクラム会議は毎日開催され、チームは作業を同期し、問題について話し合います。
新しい機能、モジュール、または更新が完了するたびに、テストが実行されます。 開発中のテストのおかげで、発生する可能性のあるバグが時間通りに修正され、最終的に製品の安定性が大幅に向上します。
反復の終わりに、顧客は製品の新しいバージョンを受け取り、必要に応じて、プロジェクトまたはその一部がレビューされます。 また、エンドユーザーからのフィードバックも考慮されます。 さらに、遡及的プロセスの過程で、チームは作業プロセスを最適化する機会を得ます。 その後、実装ループが再び開始されます。 その結果、顧客の要件を最も厳密に満たし、市場で需要があるソリューションが作成されます。
スクラムプロセス（ 画像ソース ）
スクラムのメインツール：
- 製品バックログ
- ユーザーストーリー
- スプリント計画（スクラムでの反復）;
- スプリントバックログ
- タスクボード（たとえばJIRA内部の物理またはデジタル形式）
タスクボードの例
- 燃焼タスクのチャート（分解チャート）;
- クイックミーティング（スタンドアップ/集会）;
- スプリントレビュー（デモおよび回顧）。
XP
XP Agile（Extreme Programming）は、製品開発のエンジニアリング側に焦点を当てています。 これは、プログラミングに対する体系的なアプローチです。 Scrumは管理とリリースにより注意を払っていますが、XPは生産プロセスに焦点を当てています。 XPには、最終製品の品質を大幅に改善するプラクティスが含まれています。
- 継続的インテグレーション（CI）
継続的統合サイクル（ 画像ソース ）
- 自動テスト
- リファクタリング
- コードレビュー;
- ペアプログラミング;
- コーディング標準など。
技術の適応
多くの場合、モバイル開発では、プロジェクト、チーム、および顧客の仕様に合わせて古典的な手法を適用する必要があります。 そのような適応のためのいくつかのオプション：
- アジャイルプラクティスのタイムフレームの変更 。 たとえば、スプリント時間を1週間に短縮します-原則として、アプリケーションの顧客は新しいリリースを受け取りたいと考え、チームはできるだけ頻繁にフィードバックを受け取ります。 別の例：回顧は、プロジェクトのニーズに応じて、月に1回または各反復です。
- アジャイルプラクティスの実装の変更 。 たとえば、 Slack / Stride /などを通じて非同期のスタンドアップを実行します。 チームがリモートで作業する場合、これは特に当てはまります。 別の例：顧客のしばしば「あいまいな」要件、および作業を計画するときのチームの対応する困難のために、 デュアルトラックスクラムは興味深いように見えます。
- アジャイルプラクティスのセットの変更 。 明らかに、特にスタートアップでは、選択した手法のすべてのツールを一度に作業に含める必要はありません。 したがって、最初は最も必要で「機能する」もののみを選択できます。
滝はどうですか？
従来のウォーターフォール方法論がモバイル開発の連続した段階に適用できないことについて明確に言うことはできないことに注意してください。 それはすべて、特定のプロジェクトの詳細に依存します。 プロジェクトの例があります（たとえば、超臨界作業を行う、予備研究を必要とするまったく新しい分野で、開発期間の長さ、複雑さ、長さ、政府との契約など）、その本質はアジャイルの原則と矛盾しており、ウォーターフォールは適切な選択です。 しかし、商業開発にはそのようなプロジェクトはほとんどありません。
まとめ
モバイルプロジェクトは、多くの場合、不明確な要件やユーザーニーズの頻繁な変更など、内部または外部の不確実性の影響を受けるため、何らかのアジャイル手法を使用してライフサイクルを計画するか、実際にはよくあることですが、両方の組み合わせを使用するのが賢明です。 良い結果は、スクラムとXPの適応バージョンの使用を示しました。
英語版はこちらから入手できます 。