Redmadrobotでは、アジャイルとスクラムのアジャイル方法論に取り組んでいます。 ご存じのように、プロジェクトスプリントの編成方法に大きな自由度があることを意味します。各企業は、自分たちにとって便利なモデルを選択します。 ケース-スピリッツの実行中にチームがどのように編成されているかに関する情報-外部ソースでは非常に少ないです。 「キッチン」を公開します。
まず、生産プロセスでVAが強調した主な問題について説明します。
1.クライアントはメイン画面ですべてを一度に見たい
多くの場合、企業はWebのカテゴリとソリューションの観点から考えて、モバイルアプリケーションの起動ページですべての主要な機能、機能、サービス（サイトのメインページであるかのように）を見たいと考えています。 控えめに言っても、これは常に正当化されるわけではありませんが、議論が必要です。
2.アナリストが開発者が気に入らない要件を発明
要件を読む開発者はいません。 要件の作成中に10回、開発者と議論するアナリストがいます。
3.テスト段階で要件が無効になる
テスターとコミュニケーションをとる必要があります-彼らは破る方法を知っています。 アナリストが設計する前に、「どのように機能するか」のヒントの長いリストを入手すると便利です。
4.素晴らしいデザイン
レイアウトは実行可能でなければなりません。 したがって、インターフェイスと設計レビューの要件が必要です。
5.アプリケーションを開発する必要があり、徐々に開発する必要があります
すべての機能を一度に実装することは不可能です。 したがって、タスクのセットを制限する必要があります。
「改善は必要ありません。 生存は任意です」（c） Edward Demming
遅かれ早かれ、プロジェクトは、アジャイルやスクラムでも、プロセスを標準化するようになります。 しかし、プロセス自体に細心の注意を払わなければ、完璧を実現することはできません。 こんな感じです。
スプリントパルス
Redmadrobotの標準スプリントは4週間です。 この間、目標の形式化、コードおよび厳密なテストの行での実装から、App StoreおよびGoogle Playでのアプリケーションの新しいバージョンのアップロードに進むことができます。
最初に、設計要件を準備し、それから初めて開発を行います。
-3週間。 スプリント候補者のトレーニング
参加者：
PM-将来のスプリントのために一連のタスクを要求します
顧客側のRO（プロダクトオーナー） -新しいスプリントの潜在的な候補となる一連の機能を形成します
BA-情報を処理し、未解決の質問を明確にします
アーティファクト：
-機能の形での将来のスプリントのタスク候補のセット
-顧客からの優先事項
ツール： JIRA
手順全体は、以前に計画されたロードマップの優先順位の明確化です。
-2週間。 スプリントトレーニングとスコープレビュー
参加者：
BA-要件をキャプチャし、詳細すぎて目標とは無関係な情報から影響マップをクリーンアップします
顧客側のRO-ビジネス目標の責任
UXデザイナー -ユーザーの目標とそれらを達成する方法を熟考するのに役立ちます。
アーティファクト：
-インパクトマップ
-ユーザーの説明
-ユーザーストーリー
-利害関係者のトポロジー
-外部システムAPI仕様
ツール： Xmind、Confluence
私たちに来るすべてのタスクは、 2つのタイプに分けることができます ：
-動作するAPIメソッドがあります
-メソッドなし
メソッドの開発にはかなり長い時間がかかることは論理的です。 このようなタスクを開発に取り入れないようにしますが、メソッド、インターフェースの開発要件を準備し、将来のスプリント（2週間のスプリント）の設計を行うことができます。
Impact Mapをコンパイルするには、4つの質問に答える必要があります。
- なぜこれを行うのですか？ 適切なターゲットは問題であり、理想的にはSMART形式に従います。
- 誰がこの目標を達成するのを手伝いますか？ このマップでは、ユーザーの特定のセグメントだけでなく、目標を達成するために影響を与えることができるすべての参加者も示すことが重要です。 たとえば、製品を担当するマーケティング従業員。
- 目標を達成するために、このアクターにどのように影響を与えるべきですか？
- 実際に何を実装しますか？
この段階では、問題1がしばしば解決されます。「誰もがメインページに参加したい」。
スコープレビュー
参加者： DEV、DES、QA、BA、PM、UX Designer
アーティファクト：
-顧客によって同意および承認されたスプリントスプリント
ツール： Confluence
これは、要件仕様の出現とインターフェース要件の間の中間チェックポイントです。 チームがこのタスクを完了するのにかかる時間を決定します。タスクをスプリントに入れることができない停止要因がある場合、人件費が見積もられます。 スコープは、プロダクトオーナーによる承認のためにPMに送信されます。 その後、スプリントが修正され、新しい機能を追加できなくなります。 「アプリケーションを開発する必要があり、徐々に開発する必要があります」-問題5に対処します。
-1週間。 設計インターフェース要件と設計レビュー
参加者： BA、UXデザイナー
アーティファクト：
-ユースケース
-コンテンツ制限
-非機能要件
ツール： Confluence
要件を準備する際に、標準的なアプローチを使用してそれらを記述します：ユースケース（ Alistair Kobernが提案したテンプレート）。 スクリプトは、事前に準備されたユーザーストーリーとうまくやり取りしてカバーします。 シナリオ開発は、UXデザイナーと連携して実行され、デザイナーが反映する必要があるシステムの将来の動作を記述します。 このフレームワークを超えると、要件に変更が生じます。API仕様と顧客とのコミュニケーションに基づいて特定されるコンテンツ制限、および非機能要件です。
NB！ インターフェイスの要件を準備した後、チームの他のメンバーと不在者によるレビューを実施します。 早い段階でコメントを収集することで、実現不可能なデザインを描く必要がなくなります。
設計レビュー
参加者： DEV、DES、QA、BA、PM、UX Designer、PO
アーティファクト：
-スクリーンマップ
ツール： Confluence
既製の画面が送信されるとすぐに、レビューのためにチーム全体に送信されます。 レイアウトのチェックは、いくつかの指標に従って実行されます。
- インターフェイスの初期要件、およびモバイルアプリケーションの準備された要件に準拠するため
- システム機能のコンプライアンスのため
- 多数のコメントがある場合、デザインは改訂のために送信されます。 チームとの検証段階に合格すると、モックアップが承認のために顧客に送信されます。
前の段階で対処し始めた問題№4「ファンタスティックデザイン」の解決を続けます。
ケース「My Beeline」
「選択する数」サービスがアプリケーションに実装されたとき、既成の設計がVAに落ちました（プロジェクトに完全な分析がなかった時代からの遺産として）。 分析後、デザインの実装が困難であることがわかりました+ APIはそのような実装をサポートしていません+アプリケーションで使用されていない画面の追加セットが描画されました。 デザインのスコープが誤って定義されました。
すべてを再描画する必要がありました。
1週間のスプリント。 カバレッジレイアウトの要件と要件のレビュー
参加者： BA、UXデザイナー
アーティファクト：
-インパクトマップ
-ユーザーの説明
-ユーザーストーリー
-ユースケース
-非機能要件
-コンテンツ制限
-API外部システムの仕様
-機能要件
この段階の目的は、開発済みシステムの機能要件の形式で前述した契約を正式に修正することです。 要件は、チームメンバーの相互作用と共同決定から生まれます。
それが役立ちます：
- プラットフォームの一貫性を維持します。
- すべての製品要件と意思決定を1か所で保持します。
- 新しい開発者をすばやく最新の状態にします。
- 顧客と要件を正式に調整します（これは完全にアジャイルではないことに同意しますが、これは厳しい現実です）。
- チーム全体の要件に取り組み、テスター、開発者によって生成された未解決の質問をカバーします。
要件レビュー
参加者： DEV、DES、QA、BA、PM、UX Designer
アーティファクト：
-インパクトマップ
-ユーザーの説明
-ユーザーストーリー
-ユースケース
-非機能要件
-コンテンツ制限
-API外部システムの仕様
-機能要件
ツール： Confluence
この段階のタスクは、開発に必要な一連の要件が、すべてのチームメンバーに明確であり、同じように解釈されるかどうかを確認することです。 コメントおよびコメントが表示されると、要件が変更され、再レビュー手順を経てから、顧客と合意します。
ケース「My Beeline」
アプリケーションは、AndroidとiOSの2つのプラットフォームに実装されています。 各プラットフォームおよび開発チームには、独自のチームリーダーがいます。 これらのコマンドは、互いに同期していないソリューションを提供することがあります。 要件で修正します。
2週間のスプリント。 開発段階でのチームのサポートと大規模なタスクの要件の開発
参加者： BA、DEV、UX Designer
アーティファクト：
-顧客が同意したスプリントスプリント
-外部システムのAPI仕様（ある場合）
ツール： Confluence
ここのタスクは2つのタイプに分けられます 。 最初のケースでは、API仕様が欠落しています-アナリストは開発とともに、バックエンドの要件の仕様を準備します。 これは、将来の画面マップの主なものになり、コンテンツ制限で考慮されます。 2番目のケースでは、外部システムのAPIの仕様がありますが、タスクが大きすぎるため、分析からテストまでのサイクル全体を完全に実行できません。 その後、 「インターフェイス要件の開発とデザインレビュー」の項で説明した標準手順に従ってプロセスが進行します 。 その後、次のスプリントに進み、モバイルアプリケーションの要件でカバーされ、開発されるか、APIメソッドが到着するまでバックログで遅延されます。
NB！ 当然のことながら、そのサイズのためにスプリントに陥ることのできないタスクを使用する必要があります。 次に、次のスキームが使用されます。
-別のスプリントでのビジネス分析
-インターフェース設計
-開発への移行
このようなスキームは、3つの4週間スプリントにまたがることがあります。
おわりに
理想的なプロセスはありません。そのプロセスは現時点では良好です。 現在のプロセスでは、お客様のビジネスの問題を効果的に解決できます。 当然のことながら、プロジェクトスプリントの構成は、この記事の冒頭で述べた問題を完全にはカバーしていません。 それらを完全に克服する方法について-次の記事で。
また読む：
ビジネスインテリジェンスツールキット：個人的な経験
Evernoteで個人のナレッジベースを整理する
マテリアルデザイン：月と背中に