法律があります
ビッグデータに飛び込む前に、ビッグデータの処理を管理する法的枠組みを理解する必要があります。 「通信に関する」および「個人データに関する」連邦法は、モバイルオペレーターによって蓄積されるデータ処理手順を詳細に規定しています。 この情報は、法律に従って保護する必要があります。したがって、実際のクライアントとそのトランザクションに関する情報を使用して、作成したコードをデバッグおよびテストすることはできません。
詳細から一般へ
「内部クライアント」と職務遂行者が隣接するテーブルに座っているとき、これは即座に自然なフィードバックを提供します。 ここでは、常に明確なタスクの声明ではなく、顧客が「外出先で」調整を行いたいという要望を追加します。SCRUMが最良の作業方法になることがわかります。 彼は2013年末までほぼ12か月間忠実に奉仕してくれました。 開発は迅速に進みましたが、効果的な製品を実験して生産する機会がありました。 顧客と開発者の完全なチームが、技術コンポーネントの要件の分解において、タスクの議論に参加しました。 その結果、顧客は自分のアイデアがどのようにコードに実装されているかを見て、開発者はアナリスト、アーキテクト、デザイナーの機能を組み合わせて実行することで興味深い問題を解決しました。
一方、顧客からのタスクは増え続け、要件は厳しくなっていました。バックログは蓄積され、技術的な負債は増大していました。 さらに、すでに実装されているソリューションの信頼性とパフォーマンスの要件が厳しくなりました。 その後、SCRUMが失敗し始めました。スプリント計画が非常に長く複雑になり、チームのリズムが乱れました。 誰もが大規模で複雑なタスクをスプリントに持ち込むことを望みませんでした;私もタスクをカットしたくありませんでした。 多数のタスクについて、チームは全体像を見ることをやめ、一時的なタスクが人々の気をそらし、生産性を低下させ始めました。 かんばん方式の時が来ました。
ワークフローを再構築し、再び「内部顧客」自身が議論に参加し、建設的な対話を確立しました。スプリント計画だけでなく、タスクが常に評価されました。 同時に、顧客の要求の流れをフィルタリングするアナリストが不足しており、チームの規模はタスクの量に多少対応していませんでした。 その結果、トレーナーを招待しました。リーンテクノロジーのトレーニングを専門とする人々の相談が必要でした。 それらと通信した後、私たちは現在使用しているプロセススキームに来ました。
エラー処理
おそらく、主な問題は多数のタスク（それらを解決するための作業量に関係なく）であり、期限を延長しました。 顧客は不満を抱いており、プロセスの透明性が望まれていませんでした。 別の問題が発生しました。顧客からのフィードバックはうまくいきませんでした。 彼は、自分のタスクがどのように分解されるのか、どの順序で仕事をするのか、何を、いついつ受け取るのかには興味がありませんでした。 したがって、作業の実際のタイミングの理解不足。 3番目の問題は、開発者自身が特定のタスクがチームの全体的な目標に与える影響についての理解を失い始めたことです。
柔軟なアプローチ（作業のスピード、柔軟性、迅速な対応を保証）に引き続き取り組み、プロセスを次のように変更しました。
- 1.要件収集プロセス、バックログ管理の形式化
すべての要件が収集され、アナリストが強調する場合、バックログの維持と記入に関する一般規則に同意しました。
これにより、顧客は自分のタスクが失われないことを確信でき、開発者は事前に設定された優先度で正しく記述されたタスクを受け取る機会を得ることができます（将来、これは機能をやり直す不必要な反復を回避するのに役立ちます）。
- 2.ストーリーマッピング
ユーザーストーリーマッピングを積極的に使用するようになりました。このツールは、タスクとその分解の議論に顧客を巻き込むための優れたツールになりました。 ワークフローのすべての参加者にとって、特定のタスクを完了するために何が行われているか、この決定が最終製品にどのように影響するかが明確になりました。
ストーリーマッピングを正常に適用した後、インパクトマッピングツールを使用します。 共通の目標に対する各改良の影響をグローバルに評価し、強調することができます。
- 3.サービスクラスの紹介
開発プロセス内のいくつかの領域を特定し、異なるチームが開発したすべてのサービスをクラスに分類しました。 これにより、開発チームを分離することができました。そのおかげで、プログラマは他のプロジェクトの瞬間的なタスクに気を取られなくなり、顧客とアナリストは各開発エリアの能力を理解し、より効率的に目標を設定しました。
- 4.正確な「かんばん」
トレーニングはすべての従業員（顧客および研究開発）に対して開催され、そこで、彼らは、方法論、仕事の基本原則、およびカンバンを最大効率で使用するためのツールについて話されました。
- 5.サービスクラス別など、同時に作業中のタスクの数を制限する
このかんばんの重要な実践により、お客様の開発プロセスの透明性を高めることができました。 タスクを完了する平均時間を計算し、各方向のタスクの最大数を計算しました。これは、顧客の要件を満たすために必要です。 したがって、作業の品質と条件を保証するために、正確に処理できるタスクのみを考慮します。
- 6.毎週の顧客とのミーティング
毎週の計画を完全に放棄することはできませんでした。そのため、開発段階のステータスが議論されている顧客との毎週のミーティングを残しました。
主要会議 ：
•計画
参加者：顧客、マネージャー
会議の目的：バックログからTODOを埋める
毎週
•受け入れ
参加者：顧客、リーダー、チーム
会議の目的：チームワークの結果の受け入れ
毎週
- 7.開発チームのための毎日の会議（スタンドアップ会議）
私たちはチーム全体のために毎週の会議を手配し始めました。 チーム全体が一般的なプロセスを認識できるように、それらは以前に配置されました。 現在、技術的なタスクに重点が置かれており、どの開発者が特定のタスクを実行するかが決定され、以前に完了した作業は終了し、開発計画が形成されます。 それは本当に効果的なツールになりました。
ここに続きます 。