私たちのチームは、法人向けのクレジットおよび保証製品を開発しています。方向性は若く、最初の問題は2018年に始まりました。私たちはチェックインして市場を調査し、オーバードラフト、売上高と銀行保証を増やすためのローンを開始しました。計画は、契約に対するローン、担保付きローンおよびその他の製品を開始することでした。
症状
食料品の仕組みをすぐに始めてからの私たちのプロセスは、クラッチを積み上げてきました。私たちは彼らに我慢しましたが、ご想像のとおり、プロセスのタスクの開発が長すぎることに気づいたことがあります。これはリリースの絶え間ない転送に反映され、タスクは時間どおりに完了しませんでした。バグが山積みになり、特定の小さな顧客セグメントに影響を及ぼしていました。
すでに2ヶ月間移動されていた次のタスクのリリースが再び無期限に延期される場合がありました。同時に、オーバードラフト機能のリリースは銀行の保証を破りました。製品理解の非同期化がありました。開発者は、ビジネスチームが注意を払っていないことが重要であると考えました。一方、製品の主な機能は不明のままでした。
危機的状況から抜け出すために、「悪いことと長いこと」から「速くて良いこと」を作るという課題に直面したワーキンググループが設立されました。私たち自身は、パフォーマンスを向上させ、バグの数を減らすという目標を設定しました。
問題
チームのプロセスを深く掘り下げてみると、個別に解決できない問題が絡み合っていることがわかりました。統合されたアプローチが必要でした。
- 古いテクノロジースタック。
- 長く曲がったかんばんプロセス。
- ビジネスは開発の内政に登りました。
- 開発チームはプロジェクトへの興味を失っていました。
- 一般的な毒性。
これがどのように表現されたかを詳しく説明します。
古いテクノロジースタック。私たちのプロセスは、チームの邪魔になる多くの機能を備えたシステムであるIBMODMで作成されました。それらは私たちの建築家デニスによって詳細に説明されました コツキン隣接するプロジェクトの場合（IBM BPMはありましたが、一般的にはすべてが公平です）。これとは別に、このシステムの経験を持つ専門家は市場にいないことに注意してください。
長い配達プロセス。公式には、私たちは自分たちをかんばんチームとして位置付けましたが、プロセスは滝とスクラムの間のクロスのように見えました。ウォーターフォール開発の遺産は、ビジネス、開発、およびテストがJiraカードでのみ通信することです。誰もが明確な考えを持っていました：「私は仕事の私の部分をしました、私の小屋は端にあります。」
すぐにかんばんに来ませんでした。当初、私たちはスプリントでスクラムを使用しました。これは若いプロジェクトでよりよく示されます。その後、チームがスプリントからスプリントにタスクを移すのは道徳的に難しいことに気づき、かんばんに切り替えました。その後、入力ストリームの操作方法を誰も知らないことが明らかになり、開発サイクルが現れ始めました。それは、ビジネスからのタスクが週に1回受け取られ、チームがそれらを評価し、何も明確でないことが明らかになり、タスクが次の週に送られるという事実に現れました。同時に、言葉で言えば、かんばんをしてボトルネックを探しました。
KanbanとScrumの考え方は矛盾しておらず、方法論の組み合わせが良い結果を示している例があることを理解しています。しかし、純粋なかんばんという過激な立場があったことを強調したいと思います。テストから開発への多数のリターンも大幅に遅くなり、初期段階でのタスクの品質が低いことを示していました。
役割モデル違反。ビジネスアナリストはアーキテクチャに従事していました-彼らは問題の技術的な解決策を考え出しました。これは、彼らがソリューションの精緻化と仕様を支持して深い発見を行うことをしばしば拒否するという事実につながり、このハックは弱いアーキテクチャと相まって、開発を繰り返し遅くしました。
プロジェクトへのチームによる関心の喪失。才能のある、野心的な、若いチーム。純粋なスタートアップ。立ち上げとスケールアップの後、成長する痛みが始まりました。ビジネスからの絶え間ないプレッシャー、リファクタリングの欠如による開発の複雑さ、蓄積された内部の問題、数ヶ月先のバックログは、平凡な疲労と燃え尽き症候群につながりました。
上記のすべてのために、チームの雰囲気は酸っぱいものになりました。問題はレトロで修正されましたが、解決されず、週ごとにさまよっていました。一般的な毒性はスケールから外れ、仕事に関するあらゆる対話は相互の非難に巻き込まれました。
私たちは何をしましたか
率直に言って、最初は、問題を取り除き、経験豊富な開発者とチームを強化するために、プロセスを最初から書き直す必要があることだけを理解していました。6か月後、私たちを助けたもう2つのことを挙げられます。
- かんばんプロセスの再構築。Tinkoff Biznesデリバリーセンターに感謝します。TinkoffBiznesデリバリーセンターは、私たちの問題を迅速に掘り下げ、Jiraの適応を支援してくれました。
- ビジネスとITの同期。ここで私たちは、チームが製品を理解する必要があり、それをもたらすタスクを実行するだけではないという信念に駆り立てられました。
結局、プロセスを書き直すことで、テクノロジースタックの問題が解決され、クラッチを取り除くことができました。かんばんプロセスの再考は、役割モデルを再構築し、返品の数を減らすのに役立ちました。つまり、製品へのタスクの配信速度が向上しました。多くの同期アクティビティと現在のフォーマットの再考により、一般的な雰囲気がまっすぐになりました。
パート1。プロセスを書き直す
そこで、IBMODMからCamundaにプロセスを書き直し始めました。カマンダを選んだ理由はニコライの記事に記載されています nshipyakov..。
申請プロセスでは、「文書の収集」や「ローン契約への署名」など、クライアントにとって明確な意味を持つ、プロセスの論理的に閉じた部分であるステージなどの用語を使用します。私たちの最初の仕事は、契約ローンを開始することでした。 3つの段階の論理はそれに固有であり、残りは循環ローンの同様の段階と変わらないことに気づきました。実は、カムンダで新製品の3つのステージを書きました。将来、ビジネスタスクがその重大な変化のために現れたときに、ステージ全体が書き直されました。
自然な疑問が生じます：私たちはどのようにビジネスと交渉したのですか？すでに機能している機能を書き直すには、古いエンジンで変更するよりも時間がかかることは明らかです。すべてが非常に簡単になりました。同僚は新しいプロセスに投資する準備ができていました。隣接するプロジェクトでそれがいかにクールに機能するかを見たからです（そして、こんにちは、デニスコツキン）。同時に、新しいエンジンの開発時間は、ローテーションを開始してからそれほど長くはありませんでした。燃え尽きた男たちは他のプロジェクトに移動し、それらを置き換えるビジネスプロセスの開発と設計の経験を持つ従業員を雇いました。
パート2。タスクを実行する順序を変更する
開発プロセスを変更するときは、次のガイドラインに依存しました。
- ボードに反映されていないステップがあってはなりません。
- 技術的な専門知識をチームに提供する必要があります。
- チームは、タスクがビジネスにどのように影響するかを理解する必要があります。
かんばんプロセスを変更することで、以前は暗黙のうちに開発段階を経ていた新しい段階を特定しました。これは、アーキテクチャと3つのアミーゴの出会いです。当然、小さな変更で建築は行われていませんが、どんな仕事でも3つのアミーゴのミーティングを開催するようにしています。Nastyaに「ThreeAmigo」メソッドに関する記事がありますトラビエソ..。 Nastyaに特別な感謝を述べたいと思います。彼女のアジャイルテストのトレーニングは、チーム内で多くの変更を加えるように私たちを刺激しました。
チームは、ユーザーストーリーの形式で製品の価値に関するデータを受け取り、タスクが製品に与える影響の評価を受け取ります。精通したビジネス顧客のブラフを見つけるのは難しい場合があります。たとえば、「このルールは重要です。すべてのアプリケーションでチェックされます」という評価は、「分析を行ったため、ルールは1週間に10件の追加のアプリケーションを拒否します」よりもはるかに情報量が少なくなります。したがって、開発にタスクを送信する前に、開発者の価値を共有するビジネスチームの代表として、書かれた価値の品質を検証します。
また、うまくいかなかった慣行もあきらめました。たとえば、今では、必要な場合、つまり何かについて話し合う必要が蓄積された場合にのみ、レトロを行うことはめったにありません。これは月に1回程度発生します。各チームメンバーが自分を圧迫する問題について前向きな変化を見ることが重要であるため、レトロで示された問題を解決することが不可欠です。
タスクのストーリーポイントとチーム評価の使用を停止しました。ビジネスから受け取った期日を処理し、それに応じて入力フローを管理します。数か月間行われる大規模なタスクでは、分解を実行します。これにより、一種のチェックポイントを作成し、期限の精度を高めることができます。進捗状況を監視するために、定期的に会合を持ち、時間どおりかどうかについて話し合います。そうでないことがわかった場合は、入力ストリームを調整し、実行する小さなタスクを減らします。締め切りに間に合わせる正確さについては、現在の主要な任務については、期限を迎えているとしか言えません。
役割の再配分については、アーキテクトと2人目のシステムアナリストでチームを強化しました。ビジネスチームは、タスクに何が必要か、どのような価値があるかを明確に説明しようとしますが、開発の内部の仕組みについてアドバイスしたり、入り込んだりすることはしません。私もビジネスチームの世話をします。
パート3。ITチームとビジネスチームの同期
ビジネスと開発者を同期させるために、いくつかの形式を使用しています。
タスクごとのデモ。これは、ポートフォリオアナリスト、リスク部門、マーケター、ITスペシャリストなど、関心のあるすべての人が集まり、価値、問題のある問題、技術的な解決策について話し合うものです。
発見段階で見逃したエラーを見つけて修正する時間ができる重要な会議。また、タスクを主導するマネージャーは、どの会社のプロセスがリリースの影響を受けるかを確実に知りません。このような宣伝により、分析レポートなど、プロセスの変更が中断する状況を防ぐことができます。
タスクのレトロ。この会議では、開発者と顧客が問題の開発中に遭遇した問題について話し合います。リリース後の分析の後、情熱が落ち着き、誰もが建設的な対話の準備ができたときに、それを実施します。その理由を突き止めた後、私たちは成長のポイントとアイデアの雲を形成し、それを将来的に試みます。教育プログラムの形式で製品
に関する講義を行い、その後のディスカッションを行います。彼らの目標は、IT担当者をビジネスコンテキストに没頭させることです。「今日の講義を評価する」という最も一般的な表現を使用した調査の形で収集されたフィードバックによると、平均評価は10点満点中8.5点です。
結果
6か月後、プロセスの80％以上を書き直し、まったく新しいエンジンを使用した契約に対してローンを開始しました。チームの雰囲気が改善され、効率が向上しました。これを確認するために、チームの調査を実施し、Jiraから統計を取得しました。
調査では、チームの雰囲気、仕様の品質、開発とアーキテクチャ、ビジネスとのコミュニケーションの品質について質問しました。調査の結果によると、半年以上プロジェクトに参加している男性の平均スコアは、10点満点中6点から8点に上昇しました。残念ながら、調査は変更後に実施されたため、完全に正直ではありません。表示されている数値は、年初と7月初旬のものです。ですから、チームの状況は良くなったと言っても過言ではありませんが、どれだけかは言えません。
この間、生産性（1日あたりのタスク数）は2倍になりました。当然のことながら、分解を犠牲にすることはありません。私たちは、遵守する特定の基準について事前に合意しました。
テストから開発へのリターンの数はわずかに減少しました。つまり、本番用に表示されるタスクの数が複数回増えても、返品の数は増えませんでした。これは、発見段階とアーキテクチャ段階でのタスク開発の品質が向上したことを示しています。本番環境で見つかったバグの数は変更されていません。
私たちは何を学びましたか
ここで、チームと私が経験から学んだいくつかのアイデアを策定します。チームで同様の問題が発生した場合は、チームもお役に立てば幸いです。
- , . — . , — , . — .
- , , , , , . , .
- — , , . , , discovery .
- . one-one-, , . Shoom3301, .
- : — , IT — . , .