タスクの分解に対処し、やりすぎないようにする方法

こんにちは！



私の名前はビクターです。Sportmasterのシステムアナリストです。そして今日は、タスクを分解して開発に移すことについてお話したいと思います。車であれソフトウェア製品であれ、あらゆるオブジェクトはパーツで構成されます。また、これらのオブジェクトを構成部品から1つの全体に組み立てるには時間がかかります。時にはそれは非常に時間がかかることさえあります。特にその前に、主要部分を分解するだけでなく、原子レベルでその下部に到達することにした場合は特にそうです。

タスクの適切な設定と完全な混乱の間の境界線はどこにありますか？Sportmasterで私たちが定期的にビジネスから開発タスクを受け取る方法の例を共有します。

---

---

上記の例からわかるように、各タスクの説明は、顧客の想像力と常識に大きく依存します。どこかそれが多いところ、どこか少ないところですが、アナリストはどうにかしてそれを扱う必要があります。機能の境界を示す場合もあれば、トピックを送信する場合もあります。このようなタスクを直接開発に移すと、出力で理解できないものが得られます。あなたは何をしなければなりませんか？



足で顧客のところまで歩いて行き、すべての要件を尋ね、出口で正確に何をすべきかを明確にします。確かに、ゴールドの顧客もいますが、実際には大多数です。彼らはすべての要件をConfluenceに書き込んでいるので、いつでも読んで質問することができます。そして、機能のフレームワークですべてが明確になったら、タスクの削減を開始できます。

なぜ分解するのか

分解の主な目標は、ビジネスがすべての要望を迅速に実装できるようにすることと、ユーザーがアイデア自体から機能の外観に至るまでの時間をできるだけ短くすることです。これを行うには、小さいながらも小さいタスクを実行できますが、それでも機能はユーザーに届きます。



タスク分解を使用すると、ユーザーとビジネスのニーズを満たすというグローバルな目標を達成するだけでなく、開発が正しい方向に進んでいるか、顧客が想像したものとはまったく異なることが判明したかにかかわらず、顧客からより迅速なフィードバックを得ることができます。



最初はタスクが大きく、一度にすべてを実行した場合、多くの時間を費やし、顧客のコメントの後、すべてを破棄する必要があります。ええと、タスクが小さい場合、せいぜい1日か2日の作業で、大丈夫です。リワークはほぼ同じ量かかります。 2番目のアプローチも安価です。両側の救われた神経は言うまでもありません。



1つの機能が複数の部分に分割されている場合、開発者はそれらに並行して取り組むことができます。したがって、フローを並列化し、prodの機能の出力を高速化します。重要なことは、タスクが互いにできるだけ依存しないようにすることです。



さらに、迅速なテストとバグ修正。繰り返しになりますが、小さな機能は、巨大な巨像よりもはるかに簡単かつ迅速にテストできます。そして、何かがうまくいかない場合、開発者は「修正」にほとんど費やさず、すべてがより速く動作します。



タスクを分解する段階で、顧客と一緒に、利益を上げ始めるために今ここでどの機能が重要であるか、後で何を残すことができるか、そしておそらく不要として何が落ちるかをすぐに理解できます。



ビジネスにとって、機能する機能がどれだけ早く現れるかを知ることは重要です。また、タスクに分割すると、大きな前線が1つある場合よりも、タスクを完了するのにかかる時間を予測し、より正確に見積もることができます。しかし、小さなタスクは、それらを実行する時間の観点から評価するのが簡単であるという事実に加えて、開発者がプロ​​セスで発生する可能性のあるリスクを評価するのも簡単です。



たとえば、フレームワークが更新されたり、一部のメソッドが使用できなくなったり、コードに問題が発生したりします。小さなタスクを実行することで、これらすべてのリスクを最小限に抑えます。そのようなタスクがスレッド内の何かをブロックしたとしても、それが大きなピースであるかのように重要ではありません（すべてをブロックします）。必要に応じて、実用的な解決策を作成し、技術的な負債をバックログに入れることができます。これは、問題が解決されたときに少し後で処理できます。

基本的なアプローチと分解のルール

タスク分解には、水平と垂直の2つの主要なアプローチがあります。水平の場合、タスクは作業の種類、レベル、またはコンポーネントごとに分割されます。たとえば、各タスクは、フロントエンド、バックエンド、データベースなど、いくつかの段階を経ています。また、水平方向のアプローチでは、1つのタスクが後ろに、2番目が前に、3番目がデータベースの変更につながります。



このアプローチが悪いのはなぜですか？個々のタスクを完了した後、機能する機能は得られません。 3つのソースから結果を収集することによってのみ、ある種の結果とフィードバックを得ることができます。このため、水平分解はほとんどの場合使用されません。





はるかに便利なのは、各タスクで視覚的な機能を作成できる垂直アプローチです。タスクはすべての段階を経て、出力には分析、テスト、顧客への表示、必要に応じた修正が可能な結果が含まれます。そして、すぐに起動して使用します。



ルールについて言えば、ここでは3つだけ特定しました。まず、タスクは論理的に完了している必要があります。つまり、タスク自体が独立している必要があります。それはその周りの論理を壊してはならず、必然的にユーザーが結果として受け取るであろう少なくともある程度のビジネス感覚を持っていなければなりません。同時に、ビジネスセンスを持たないタスクを部分に分割しないでください（理想的には、それらはまったく存在しないはずです）。



第二に、1つの小さなタスクを完了した結果は、小さな変化をもたらすはずです。変更が小さいほど、一般的なコードへの移行が速くなるため、コードが陳腐化することはありません。さらに、小さなタスクは、マージ時に開発者間の競合を回避するのに役立ちます。



第三に、タスクを非常に細かい部分に分割するべきではありません。細かく分類しすぎると、これらのタスクの管理に非常に長い時間がかかります。各段階で、それらの優先順位を付け直し、依存関係の接続を再確立する必要がある場合があります。それだけです。したがって、開発速度は向上しませんが、逆に急激に低下します。したがって、妥協点を探す必要があります。

分解方法

ソースに応じて、分解方法の数は大きく異なります。どこかで8つ、どこかで10、どこかで20で示されます。私が仕事で毎日使わなければならない方法を強調したいと思います。

複数のニーズ

この方法は、ストーリーに「and」、「or」の組み合わせがある場合に最も便利です。たとえば、消費者が注文してカードやボーナスで支払いたいとします。このタスクは、ユーザーが注文する1つ目、カードで支払う2つ目、ボーナスを使用する3つ目のタスクに分けることができます。

使用シナリオ

もう1つの一般的な方法は、ユースケースに応じてタスクを分割することです。この場合、1つのストーリーが1つのメインパスといくつかの代替パスです。ユーザーがアイテムを購入したいとします。それがメインシナリオになります。しかし、まだ別の方法があります。彼はすぐに製品をバスケットに入れて支払うか、購入する前にこの製品を他の製品と比較したいと思うかもしれません。次に、製品の比較を別のタスクにします。



おそらく彼は今は買いたくないのですが、どこかで延期し、お気に入りに追加して、後で戻ってくることができるようにします。または、ユーザーがその製品を気に入って購入する準備ができているが、在庫がない。だから、あなたは彼に商品がいつ現れるかを知らせる必要があります。そして、これが4つのシナリオの結果です。

単純なものから複雑なものまで

「Sportmaster」サイトのメインページはバナーで構成されています。そして、私たちができる最も簡単なことは、1枚の写真を撮ってそれをユーザーに見せることです。これは、適切な情報を伝えるための最も簡単で最速の方法です。次に、機能を増やして、1つの画像ではなく、3つまたは4つの画像を追加して、グリッドに結合することができます。これは別のタスクです。





このアプローチでは、後続の各タスクで、機能が拡張されるはずです。たとえば、グリッドからカルーセルを作成し、リンク、テキスト、ボタンなどを追加できます。一般に、最初に最も単純で最もパフォーマンスの高いバージョンを実装してから、より複雑なバージョンに移ります。



つい最近、私はバナーを実装するという同様のタスクに従事しました。バナーはメインバナーにぶら下がっていて、CMSから制御されるはずでした。顧客に正確に何を管理したいかを尋ねると、彼は瞬きすることなく、誰もが喜んで答えます。したがって、ここでは、トピックを少し掘り下げて、今管理する必要があるもの、頻繁に使用されるもの、ほとんど使用されないものを強調することが重要でした。したがって、実装に優先順位を付け、タスクに分割します。

オペレーション（CRUD）

これはおそらく最も一般的な分解方法です。ここでは、タスクは作成、読み取り、更新、および削除の各操作に分けられます。何かを管理したり、何かを構成したりする必要があるタスクに適しています。たとえば、注文のタスクは、注文の作成、表示、編集、削除の4つの小さなタスクに分けられます。

インターフェイスオプション

複数のインターフェイスオプションをサポートする必要がある場合に使用されます。たとえば、サイトは複数の言語をサポートする必要があります。まず、ロシア語版を作ります。その後、他の国で発売する場合は、英語を追加します。国が英語以外の言語を使用している場合は、それを追加することもできます。この場合、最初に1つの言語ですべてを実行してから、徐々に翻訳を追加する方が簡単です。





最近では、多言語のサポートが必要な法的エンティティの個人アカウントのプロジェクトを完了しました。締め切りが厳しかったので、最初はすべてを1つの言語で行いましたが、さらなる翻訳の基礎を築きました。現在、新しい言語のサポートを追加するには、1つの小さなタスクが必要です。一度に複数の言語を追加する必要がある場合は、言語ごとに個別のタスクが作成されます。

役割別の分離

機能が複数の役割とユーザーグループの操作を意味する状況に適しています。Sportmasterサイトでは、ユーザーはさまざまな役割を持つことができます。たとえば、ユーザーは役割ごとに、許可されたユーザー、匿名のユーザー、およびたとえばコールセンターのユーザーに分けられます。後者の役割は2つに分けることもできます-それは通常のユーザーまたは管理者のいずれかです。



役割ごとに、個別のタスクを作成できます。匿名ユーザー向けに表示することから始め、次に、許可されたユーザー向けのタスクの一部としていくつかの高度な機能を追加します。また、コールセンターオペレーターの技術的役割とその機能を忘れないでください。

エラー処理

締め切りが厳しく、最小限の機能ができるだけ早く必要な場合は、エラー処理を別のタスクに取り入れることができます。ここでは、テストの作成についてではなく、サイトが統合されているユーザーとシステムのエラーの処理について説明します。製品タイルを含むカタログページを処理していると想像してください。各カードには、説明、写真、追加情報があります。



たまたま、一部の情報がデータベースからのものではありません。

おそらく、私たちがブランドや素材について話している場合、これは無視され、単に情報が表示されない可能性があります。しかし、価格や名前が出てこない場合は、このカードを提示する価値がありますか？



そのような状況で何をしますか？この質問は、個別のタスクで取り出して、各個別のフィールドを処理することができます。つまり、価格が来なかった場合、1つのアクションを実行すると、製品の説明が失われます-別のアクション。ユーザーエラーについても同じです。彼が何かを間違って入力し、「ページが見つかりません」やエラー500などのエラーが表示された場合は、何が起こったかに関する具体的な情報を示し、次にできることをスクリプトで提供する必要があります。



この方法は、機能を維持するかどうかを決定するために、機能に関するフィードバックをすばやく取得する必要がある状況にも適しています。

静的、次に動的

これは私のお気に入りの方法の1つです。 「スタブ上」で機能を実装できる状況、つまり外部システムがその機能をサポートする準備ができていない状況に適しています。たとえば、メインページの一部のブロックはCMSから制御できません。または、コードで作成してユーザーに表示するメニューですが、同時にビジネスで制御することはできません。そして、変更を加えるために、ビジネスは絶えず開発に行き、それをするように頼む必要があります。



ここでは、ユーザーのニーズと利益を優先します。内部に不便を感じる場合でも、ユーザーはすぐに既製の機能を利用できます。したがって、タスクをいくつかに分割し、最初に新しいブロックをユーザーが利用できるようにしますが、ビジネスはまだそれを直接管理できません。しかし、その後、ビジネス自体がアイテムを交換したり、新しいアイテムを独自に追加したりできるシステムやデータベースと統合することができ、開発に参加せずにそれらを描画します。



この方法をよく使用します。まず、外部から制御できない独自のデータに機能を作成し、次にダイナミクスを追加して、サードパーティシステムからのデータの受信を開始します。

パフォーマンス

タスク全体が複雑で膨大な場合、どちらの端から取り組むべきかが明確でない場合、パフォーマンスは無視できます。最初のタスクは、既製の機能を引き出すことです。これは、ゆっくりではありますが、機能しました。そして次のタスクは作業をスピードアップすることです。たとえば、商品の検索、フィルターの適用、情報の取得などの時間



がかかる場合があります。ほとんどの作業は、関数をすばやく作成することに費やされる場合があります。最初の実装はそれほど難しくありません。しかし、遅い実装から多くのことを学ぶことができます。さらに、そうでなければ重要なアクションを実行できないユーザーにとっても価値があります。これらすべての場合において、タスクは「機能させる」と「高速化する」に分けられます。

考えられる問題

プロジェクトでタスク分解を使用することにした場合、最初に遭遇する問題は、タスクが相互に依存していることです。私の経験では、これは最も一般的なスレッドブロッキングの問題です。これを回避するには、責任を持って分解に取り組み、十分な時間を与える必要があります。





もう1つの問題は、タスクをどれだけ細かく分解する必要があるかを判断することです。そして、ここでは常識だけが境界として機能します。たとえば、都市選択コンポーネントを取り上げます。ボタン、テキスト、入力フィールドがあります。このタスクをどのくらい小さくする必要がありますか？



タスクはフロー全体に沿って1週間以内（約40時間）で実行する必要があるというルールを自分たちで推測しました。分析、開発、テストのすべての段階について話します。さらに、バックエンドとフロントエンドの開発の2つの段階が考慮され、それぞれでのレビューとテストが含まれます。



また、叙事詩の境界が必ずしも明確ではないという事実にも問題がありました。最近、注文するタスクが与えられました。彼女の国境はどこですか？出力はどうあるべきですか？すべての機能を最後まで実行する必要があるのか​​、それとも一部を選択する必要があるのか​​は、私たちには明確ではありませんでした。この叙事詩には支払いが含まれていますか、それともすでに別の叙事詩ですか。



分解する方法と時期を理解するのが難しいタスクがあります。エピックを受け取った段階でほとんどのタスクを分解しますが、分析の段階など、これを実行する必要がある場合もあります。私たちは仕事を引き受け、必要なすべてのデータがすでに統合システムにあると信じていますが、分析中に、データ形式に満足していないか、データ自体の品質に問題があるか、または他のシステムからの改善が必要であることが判明しました私たちはつながっています。次に、「スタブで」タスクを実行し、バックログに別のアイテムを追加する必要があります。これは、主な問題を解決した後に開始します。



それがすべてのようです。タスク分解へのどのアプローチを使用し、その理由についてのコメントでストーリーを共有すると素晴らしいでしょう。



読んでくれてありがとう！