ソフトウェア開発プロセスのいくつかの古典的なアプローチに基づくあらゆる議論は、近代的なソフトウェアを作成する方法です。我々は、市場のニーズを念頭に置いて期待される頻度で製品を提供するためにいくつかのレディンスを確立しなければなりません。 イテレーションの長さは、製品バックロッグの変化に必要な適応速度を反映すべきです。 優先順位管理のアプローチは完全に直感的で、ソフトウェア開発に使用するために標準化に深い理解を必要としないように見えるが、いかなるプロセスを確立することは、すべてのチームメンバーのための一般原則の宣言を意味する。 常に独自の優先順位システムを発明することは可能ですが、新しいチームメンバーにシステムの原則を説明する必要性が生じます。プロジェクトが大きくなり、新しい同僚がたくさんいれば、それは問題です。したがって、いくつかのタイムテストされた国際標準やアプローチを使用するのは簡単です。この記事では、製品開発における優先順位化のためのMoSCoWメソッドの使用を事実上最も一般的な方法として、イテレーション中に作業を簡素化し、迅速かつ測定可能な結果を提供する方法として議論したいと思います。 例として、私はこのアプローチで直面したカスタマイズされた優先順位化方法と問題の例を提供します. Then we will dive into the MoSCoW method breakdown to consider each priority with live examples. 記事は、製品マネージャーや、うまく機能する製品開発プロセスを追求する誰にとっても役に立つかもしれません。 アイテム優先度に関するカスタマイズされたアプローチで楽しむ 非常に長い間、ある製品チームで、私たちは開発サイクルの項目優先順位の問題を解決しようとしていました。そのプロセス自体は非常に未熟でした:実装期限はしばしば破られ、チームは超過時間で作業し、製品リリースは不十分な品質でした。その時点で私たちは数値優先順位 1-2-3-4 を使用し、それらはまったく役に立たなかった。その後、私たちはチームメンバー間のコミュニケーションを簡素化することに決め、追加の優先順位「5」を導入しました。この優先順位は、最も高い優先順位になり、「1」よりも重要であり、「showstopper」を意味します。 Why is “5” more important than “1”? Because historically we had myriad priority “1” items, and “0” was used for the tasks that had to be prioritised later. Changing the meaning of “0” means a thoughtful review of the entire backlog, implementation of some migration, and nobody wanted to do it. How does it happen that we have so many priority “1” tasks in the iteration that we have to introduce an additional priority? And what is the purpose of 2-3-4? These are the most important questions that show the process immaturity, because team members had no idea what the difference was between 2-3-4. All these tasks were just “optional”. How do we explain these illogical rules to new team members? These rules were impossible to explain, and this improvement didn’t help to make things right. もちろん、優先順位化の方法はこのプロセスにおける一般的な問題ではありませんでした。計画、リスク管理、戦略そのもののアプローチには根本的な問題がありました。しかし、テーブルの上に多くの課題がある場合、独自の曖昧な方法論の発明は最善の決定とは思えません。 「MoSCoW」のアプローチ いくつかの基準は、IETFやIEEEなどの機関からの国際的なベストプラクティスRFCで厳密にコード化されている一方で、他の基準は独自に基準となっています。 このアプローチは本書でDai Cleggが提案したものだ」 「MoSCoW」という名称は北部の首都とは無関係で、優先順位のカテゴリの略称として作成された。 オスは、 ハウスは、 ウルフは、 これらのカテゴリは、数的優先順位 1-2-3-4 と関連付けられ、製品開発イテレーションにおけるタスクまたは項目の順序を明確に決定するのに役立ちます。各カテゴリの明確な目的は、この方法をそのような宝石にします。 Case Method Fast-Track: A RAD Approach M S Co W まず、アプローチを使用するための例のシナリオを確立する必要があります。 私たちは、B2B製品を開発している製品チームのメンバーであると仮定します。この製品では、顧客はプロジェクトのためのファイルを保存し交換することができます。シンプルに保つために、当社のチームは、「ユーザー招待」などの基本的な機能を追加します - プロジェクトに新しい参加者を追加する機能です。我々は、特定の日付までにこの機能を実装することを顧客に約束しました。我々はコミットメントを持っています。 この例では、チームのメンバーを専門分野(Dev、DevOps、QA)に分割することはなく、私たちのチームをカノニカルなユニバーサルスクラムチームとして想像します。 ユーザー招待シナリオでは、技術的な要件、UX/UIが用意されています。この機能はすでに有意義なアイテムに分解され、これらのアイテムはすべて推定されました。 これは優先順位化のアプローチを使用する時間であり、さらなる問題なしに、これらの項目を分類しましょう。 MUST HAVE - 1 Must Have “1” 優先度は、次の開発イテレーションに含まれるタスク、機能、製品バックログの項目、ユーザーストーリー、またはバグに使用されます。 例えば、計画の過程で、いくつかのタスクが顧客との合意を通じて開発されるべきであるか、あるいは他の理由でビジネスに重要であることに気づきました。 主なアイデアは、これらの項目が重要で交渉できないということです。 チームはそれらを推定し、リスクをとり、計画する必要があります。 新しい製品機能の例に基づいて、「新しいユーザーをプロジェクトに招待する」機能を実装したいと仮定します。「Must Have」カテゴリはMVPタスクを反映し、基本的な機能性を生成します。 Implement the <Invite user> button in the project users list. Develop basic functions of the “Invite user” pop-up. Send a notification to the new user with authentication instructions. きっと・・・2 2つ目のカテゴリーは「Must Have」に近いが、後で延期したり配達したりすることができるものだ。 ユーザー招待についてクライアントと合意した場合、MVP機能は優先度「1」で必須オプションとしてリリースされますが、常に実装する必要がある改善がたくさんありますが、宣言された範囲内で省略される可能性があります。 たとえば、「ユーザー招待」機能では、製品が新しいユーザーを搭載するのに役立ちます。「Must Have」優先順位では、チームは作成と招待の重要なシナリオを開発します。しかし、新しいユーザーが成功してログインした招待管理者へのフィードバックを送ることも重要です。このフィードバックなしで機能を使用することは可能ですが、この通知で製品は確実に良くなり、管理者はすべてがうまくいっていることを知ります。 「Should Have」製品バグはシナリオを破るものですが、通常のユーザーと非技術的なユーザーに利用可能な合理的な解決策があります。 たぶん・・・3 このカテゴリーは、全体的に違いを作り、製品の全体的な感覚を向上させることができる改善や軽微な視覚欠陥についてですが、現在は重要ではないか、シナリオのために深く選択可能なものではありません。これらのものを開発することは、すべての「Must Have」または「Should Have」の優先事項のリスクが軽減される場合にのみ良いでしょう。計画中、製品チームは「Could Have」の項目をこのように考えるべきです:最初の優先事項は行われなければなりません。私たちは第二の優先事項を提供するために最大限の努力を払うべきです。 「ユーザー招待」機能の場合、第3の優先順位は、ユーザー招待フォームのいくつかの追加の改善です。第3の優先順位として、管理者は、ユーザーが次の3日間にログインしていない場合に自動通知を設定することができます。プロジェクト管理者は、第2の優先順位通知の欠如に気付いた場合にこのメモを手動で送ることができますが、最初に自動メモを導入するのが良いでしょう。 製品バグとしての“Could Have”の優先度は、いくつかの異常な環境で再生される稀有な機能やビジュアルバグについてです。これらのバグは、未完成の機能や他のカテゴリの製品バグがなければ修正することができます。 第三の優先度バグは、製品リリースをブロックしていないため、長い交渉なしに次のイテレーションに移行することができます。 たとえば、当社の顧客ベースの大部分は特定のエンジン上でウェブブラウザを使用し、我々は不人気のエンジンで無意味な欠陥を持っています。 このバグを修正することは素晴らしいことになりますが、誰もがより重要なタスクで忙しい場合は、リリース中にこの問題がある問題はありません。 持たない(4) イーテレーション中に絶対にリリースされない項目を表示する有用なカテゴリですが、残っている容量がある場合にそれらを持ち続けることが重要です。 製品チームはイーテレーションとセグメントタスクとバグを最初の、第2および第3の優先事項として計画することができます。 そして、タスクが計画されていたよりも簡単であることが起こります。 開発者は第4の優先事項のために使用できる余分な時間を持っています。 これらの項目は常に分支で開発され、現在のイーテレーションで合併するつもりはありませんが、これは次回のイーテレーションのために物事を容易にします。 どのようなタスクが「Won't Have」バックロッグとして適していますか? 「Must Have」または「Should Have」の優先順位も非常に重要ですが、コードベースのメンテナンスのための定期的なコードの改善は、第4の優先順位の素晴らしい例です。開発者は、ビジネスに不可欠なタスクの後にコードを改善し、これらの改善を次のイテレーションで使用する機会を持っています。 また、次回のイーテレーションで最初の「Must Have」の優先順位となる項目を「Won't have」の優先順位として追加することも有用です。私たちは、基本的なユーザー招待の後、このシナリオに詳細なユーザー許可設定を統合して管理者フローを簡素化すべきであることを知っています。この機能は次回のイーテレーションのMVPになります。もし我々がいくつかの能力を持っているなら、それを第4の優先順位として開発し始めることは素晴らしいことです。それは将来のリスクを低下させるでしょう。次回のイーテレーションの計画中に、この項目の優先順位は「Must Have」に更新されます。 このカテゴリは、バグがイーテレーション中に修正されないことを示しているため、第4の優先順位の製品バグを持たない方が良いが、バグはバックロッグボードに追加の混乱を生み出すだけである。それでも、現在のイーテレーションに危険なアーキテクチャ的変更を必要とするバグには優先順位を使用することができ、それらのテストは次のイーテレーションで計画されるべきである。 優先順位の使い方について 一般的な1つは、これは優先順位の意味の明確な理解です。この記事の初めに、私は4つのカテゴリを含むカスタマイズされた優先順位アプローチの例を示し、誰も理解しなかったし、チームは最も重要なタスクのための5番目の優先順位を導入しなければなりません。 これらのルールはまた、チームベンチマークとして機能し、チーム計画のアプローチにおける問題を示すのに役立ちます。 たとえば、チームが最初の「Must Have」の優先順位のすべての予定された項目を開発できない場合、他の優先順位については言及せず、プロセスにおける深刻な問題を示します。 特徴的な要件はそれほど良く、明確ではなかった。 解体のミスがありました。 チームは何とか課題の複雑さを過小評価した。 誰かがイーテレーション中にアイデアを変えることにしました。 チームは、後見を提供し、問題の起源を明らかにし、壊れた開発プロセスを修正するための解決策を見つける必要があります。 同時に、第3および第4の優先事項の安定的な完成はあまり良くありません。それは、我々が評価とリスク管理に優れていることを意味しますが、チームがかなりリラックスしているか、または過剰に負荷を負っていることを示しています。もしかしたら、我々は「Must Have」または「Should Have」の優先事項の追加項目を計画することができるかもしれません。 Cons of the Approach 関連記事 上記の例では、タスクは、1 つの特定のイーテレーションの優先順位によってカテゴリ化されましたが、会社のビジネスに応じて全体的な優先順位を意味しません。 さらに、このアプローチには、一つのカテゴリー内のタスクの順序に問題があります。イーテレーションに「Must Have」項目が少ない場合は、どちらが先に開発されるべきですか? この順序は、イーテレーションの計画を通じて議論され、特定のソフトウェアを通じて調整されるべきです。開発プロセス全体に銀の弾はないが、MoSCoWのようなアプローチを使用することで、基本的なプロセスを簡素化できます。 結論 優先順位化のための方法やアプローチはたくさんあるが、私は、MoSCoWアプローチは、ソフトウェア開発プロセスの一般的な改善から始めるのが最も簡単なアプローチの一つだと思う。このアプローチは、明確に定義されたタスクとビジョンを持つB2B市場の製品や製品開発により適している。このアプローチを正しく使用するために、その後のイテレーションのための計画が必要である。混沌と急速に変化する環境では、このアプローチが機能しなくなり、リリース予測性に影響を与える多くの優先順位のタスクを作り出す可能性がある。同じ問題は、適切な計画と評価プロセスなしに発生する可能性があるが、それにもかかわらず、このアプローチを使用すると、これらの
