カスタム開発では、常に多くの機能と予期しない問題があります。 スクラムとかんばんの技術を組み合わせた実践的な経験を共有します。 特定の目標を達成するために、それらをどのように使用し、適応させ、最適化したのか、なぜそれが必要で、何につながったのかを説明します。
現在の作業では、伝統的にスクラムを使用しています。 この効果的なツールセットは、新しい特定のプロジェクトが出現するまで、常にすべての困難に対処します。
ソースデータ：
特徴的な機能は次のとおりです。
- プロジェクトの採用時点では、2年以上開発されていました。
- 機能の印象的な部分が実装されました。
- 要求のあるソリューションと関連性のないソリューションの両方が数多く開発されています。
私たちのチームはプロジェクトの最終段階を完了する必要がありました。
予備作業の後、通常のスクラム方法論に従って環境をセットアップし、サーバーを上げてワークフローを編成しました。 バックログを更新し、2週間のスプリントの形成を開始しました。
条件：
1.計画
計画プロセス（Planning Poker、マップおよび相対的な労働投入単位S、M、L、XL、XXL）で、タスクは詳細に練られ、形成された要件は追加の質問を引き起こしませんでしたが、実際の評価は透明性からはほど遠いことが判明しました次の条件が最初の問題を形成しました。
問題1-計画、関連性が急速に失われている：
- 以前に実装された機能を開発する方法と方法に関する情報の不足。
- 未完了のタスクの存在;
- 出発材料に詳細な長期浸漬がなければ、タスクの段階と完了率を評価できない。
- 何時間も計画を立てることは不合理です。
継承されたコードと数百の依存関係に隠された「落とし穴」は、コードを扱う初期段階では予測できないため、計画は合理的ではありません。
2.開発
実際には、すべてがさらに悪化しています。 プロジェクトが作成されたCMSは完全に改訂されたことが判明したため、ドキュメントは関連性がないか、まったく存在しないことがよくあります。 前のチームとの積極的なコミュニケーションを開始します。これにより、エントリーのしきい値を緩和できます。 しかし、開発の最初の日から、いくつかのタスクを大幅に過小評価していたことが明らかになりました。 更新されたデータに基づいてスプリント計画を調整します。
問題No. 2-多くの緊急の予定外のタスク
プロジェクトは非常に多く、1日あたり約25,000人のユニークユーザーがいます。 開発の3日目に、即時修正が必要な重大なエラーが見つかりました。 反復を通して、計画を再構築し、タスクを切り替え、緊急のタスクを引き受ける必要があります。 追加のドキュメントコストと完全な混乱と混乱の感覚を伴います。
すべての困難にもかかわらず、主なことはスプリントの終わりまでに行われました。顧客は満足し、参照タスクが開発されました。 振り返ってみると、ポーカーの前にタスクをより慎重に分析するために、事前にシェアを計画するように顧客に依頼することが決定されました。 これはすぐにいくつかの改善をもたらしますが、他の困難が現れます。
問題No. 3-反復中のタスクの優先順位の変更。
評価後、顧客はタスクの優先度を変更します。タスクの一部は、顧客のアイデアと比較してより労働集約的であり、小規模で緊急のアイデアを対象としています。 計画が再び変更され始め、緊急のタスクが表示され、優先順位が変更されます。 これらの問題はチームの変更に関連していないことが明らかになります-プロジェクト自体にはそのような詳細があります。
多数の緊急事態が不安定になり、作業が難しくなり、生産性が低下します。さらに、反復の成功を適切に評価することはほとんど不可能です。 振り返ってみると、プロセスをどのように整理するかという疑問が生じました。
解決策：
これを行うために、2つのアジャイル手法（スクラムとカンバン）をツールに分解し、必要なものだけを取り出して、開発をコンベヤーに配置することが決定されました。
彼らは、カンバン方法論によって提案された開発プロセスを整理するアプローチを取り、行われた作業の分析の透明性のためにスクラムからいくつかのツールを残しました。
- アナリストは、承認のためにタスクを文書化および分析し、それらをバックログに追加します。
- プロダクトオーナーはタスクの優先度を調整します。
- 予備計画は実行されません。
- 開発者は、バックログから最も優先度の高い開発タスクを取得します。
- 完了したタスクはテストに入ります。
- 必要なチェックが実行されます。
- サーバーと戦うためにタスクを転送するか、開発に戻るかの可能性について決定が下されます。
- コメントがない場合、タスクはステージサーバーに送信され、そこでリグレッションが再チェックされるか、他のタスクが予期されます。これがないと、バトルサーバーに転送できません。
- プロジェクトのライフサイクル全体が2週間の反復に分割されます。 それらは、生産性のダイナミクスを評価し、完了したタスクの追跡を時系列で簡素化する機能に関して、本質的に形式的なものです。
- 簡略化されたスキームに従って、各反復の結果に従ってデモンストレーションを実施します。追加のコメントが必要なタスクのみがデモンストレーションされ、顧客は残りを自分で見ることができます。
- 各反復は振り返って終了します。
このプロジェクトで使用した主なツール：
| スクラム | かんばん |
|---|---|
|
|
したがって、変更には多くの技術的な問題が伴いました。「テスト」、「削除の準備完了」、「送信済み」などのタスクのステータスの透明性と、バージョン管理システムでタスクを維持するためのルールを決定するために、バグトラッカーのステータスシステムを改良する必要がありました。
結果：
この手法は、最初の反復ですでに結果を示しました。
- 生産性の成長。
- スケジュールされていないタスクは、全体の計画を変更しなくなりました。
- チームの全体的なムードとパフォーマンスの改善。
- 組織化されたプロセスの透明性を維持し、すべてがチームにとっても顧客にとってもシンプルです。
もちろん、すべての問題がすぐに解決されたわけではありませんが、答えは自分で解決し始めました。それぞれの問題を解決する必要はなくなりました。 時間が経つにつれて、プロセスはより思慮深く自然になり、開発にさらに多くの時間が与えられました。
結論：
さまざまな業界での長年の仕事の中で、人々は割り当てられたタスクを解決するための非常に多くの方法論を思いつきました。 それらはすべて開発を統一するように求められており、ある程度は私たちにも適しています。 ひとつのことを繰り返して、視野を広げ、方法論をツールに分解し、必要なものを取り、自由に余分なものを捨て、何かを変えることを恐れないでください。 試してみると、確実に良い結果が得られます！
著者： Boris Syrovatkin-/テストエンジニア/ソフトライン開発部