こんにちは。ソフトウェア製品の評価における私の経験についてお話ししましょう。私はこれを15年間中断することなく行ってきましたが、私の経験と評価に関する私の見解の進化を共有したいと思います。きっと役に立つと思います。目標設定から始めましょう。なぜ測定するのですか？誰がそれを必要としますか？
答えは実際には非常に単純です。人々は確実性、特に「いつ準備ができるのか」という質問に対する答えを求めています。いつ休暇に行くことができますか、いつ販売が始まるか、いつ関連するタスクを実行するか。一方、あなたは人々が何を望んでいるのか決してわかりません、なぜ他の人々がこの活動に時間を無駄にしたいのか？
しかし、最終的には、私たち全員が給料を受け取りたいと思っており、給料は空からは見えません。会社は、別のケースでは、投資からの収入からそれを受け取ります。そして、この収益を実現するには、ビジネス目標を達成する必要があります。また、ビジネス目標を策定する人々は、ROI、LTV、その他のEBITDAなど、あらゆる種類の財務公式を非常に気に入っています。そして、これらの公式は常に期限を特徴としています。それらがなければ、ワニは捕まえられず、ココナッツは成長しません。
もう1つの理由もありますが、それほど重要ではありません。機能の見積もりが明確な場合、これは優先度に影響し、単純なタスクは優先度が高くなる傾向があります。従来のアジャイルアプローチでは、バックログが定期的に揺さぶられるため、タスクの評価に関する入力情報は、優先順位付けプロセスをより効率的にするのに役立ちます。
結果として：おそらく、あなたはまだ評価しなければなりません。 謙虚に。
それでは、プロセスのすべてとすべての人を呪わないように、これを行う方法について話しましょう。IT関連の評価方法を知らない人は通常どのように評価しますか？このような：
- 私たちはすべての仕事を直接評価します。
- 万が一に備えて10％追加してください。
- 開発者の数で割ります。
- 結果の日数を現在の日付に加算して、最終日を取得します。
- それで全部です。
このため、タイトル写真からのベトナムのフラッシュバックはまだ私の目の前で点滅しています：この戦争で私の神経の多くが失われました。そして、あなたがこのように評価し始めるならば、それはあなたのために死ぬでしょう。問題は、これがまさにあなたに期待される種類の評価であるという ことです。
「ストーリーポイントをいじくり回さないで、手を見せてください。」
評価中に直面する問題
理想的な状況から始めましょう：
- アトミックな（単純で分割できない）タスクがあります。
- 他のタスクに依存することはなく、何も調整する必要はありません。
- それを行う方法を知っているタスクのための100％献身的な人がいます。
この場合でも、「誰が評価するのか」という疑問が生じます。この瞬間、容赦のない制御機が始動します。まず、マネージャーは次のように考えています。開発者がこれを行う場合、彼が騙すために莫大な人件費を指定することを妨げるものは何でしょうか。 ->したがって、マネージャーは自分でタスクを評価します。 ->しかし、マネージャーはトピックを十分に理解しておらず、落とし穴を理解していません（または見たくない）。 ->見積もりは取り返しのつかないほど過小評価されていることが判明しました。 ->チームは締め切りに間に合いません。 ->死と腐敗。
上記の状況は、従業員の不信という典型的な企業文化の問題です。ただし、ほとんどの開発者は、興味深い問題を解決するという本質的な動機を持っています。彼らにとっては、コンピューターで馬鹿を演じるよりもはるかに魅力的であるため、広範囲にわたる不信の理由はありません。一般的に、会社は従業員への信頼の推定に基づいて構築されるべきであり、通常のビジネスプロセスをひねって黒い羊のように見せてはなりません。
不信の文化は、企業の恐怖の文化と関連して非常に一般的です。開発者がタスクを評価している場合でも、評価中に頭の中で何が起こりますか？彼は質問に答えます：「私の会社は計画された日付と実際の日付の間の不一致にどのように反応しますか？」開発者が締め切りに間に合わなかったことで叱られた場合、彼はそれらを過大評価します。開発者が事前に行ったタスクについてそれ以上の評価が中断された場合、開発者は事前にタスクを引き渡すことはありません。
恐怖の文化の最新の例は、サイバーパンク2077のリリースです。このゲームは、前世代のコンソールで嫌な品質でリリースされました。同社のCEOは声明の中で、「結局のところ、ゲームで発生した問題の多くはテスト中に発見されなかった」と述べています。もちろん、これは完全な嘘です。問題は肉眼で確認でき、テスターはこれを物理的に見逃すことはできませんでした。これは恐怖の文化における典型的な状況です：問題は静まり返っています。そのため、経営陣の最上階に至るまでの情報は、「ベースコンソールでプレイできないゲーム」から「リリースしよう」になりました。
これが当てはまらない場合は、さらに評価することができます。会社の文化に不運な場合は、これ以上読まないでください。正確さではなく、当局からのキックを最小限に抑えるために評価を発行する必要があります。これはまったく別の作業です。
そして、あなたは見積もりを出しました、例えば-1週間。これはあなたの推測であり、それ以上のものではありません。評価により、タスクの計画完了日が決定されますが、実際にいつ完了するかは決定できません。タスクの実際の完了時刻が正確に記述される場所は、正規分布で表されます。今のところ、これを公理として覚えておきましょう。最後に、どんでん返しがあります。
一部のタスクは基本的に部分に分割されておらず、並列化できないこともあるため、すべてがさらに複雑になります。相互に依存するタスクもあります。タスクのコンテキストに飛び込む必要があります。さらに、開発時には、チームは活動を同期させるためにコミュニケーションをとる必要があります。
未来の見方もわかりません。その結果、私たちが予測できなかった、そして予測できなかったタスクが常に発生します。どうなり得るか？
- 顧客の希望または製品の所有者。
- 何かを改善する必要がある突然の問題。
- 予期しない合法。
- そしてたくさんのもの。
最も予測不可能なのは、開発者の速度が異なるという問題です。
同じレベルで同じ給与の実際の開発者の場合、生産性は桁違いに異なる可能性があります。
- 誰かが1週間コードを切り取ってデバッグし、誰かが半日で開いているライブラリを台無しにするでしょう。
- 誰かがスタックオーバーフローを吸うでしょう、そして誰かがすでにそのような問題を解決していて、すぐに利益を得始めるでしょう。
その結果、ガウス分布は次のようになります（タスクのサイズが十分でない場合、見積もりは同じように見えます）。
一般に、すべてが複雑で、ここでは溝を掘っていません 。そのような状況でどうやって良い成績をとることができますか？
良い成績基準：
- 高速な評価-評価自体にはビジネス上の価値がないため、開発の邪魔にならないように、できるだけ早く評価を行うのが論理的です。
- 評価はチーム全体の責任であり、チームを上限から保護するための優れた「評価、実行」の原則があります。
- 分析、開発、単体テスト、自動テスト、統合テスト、DevOpsなど、本番環境の機能の出力のすべてのコンポーネントを忘れないでください。これをすべて評価する必要があります。
ご覧のとおり、正確さについては何も書いていません。見積もりをしてきた15年間、正確に見積もる方法がわからなかったので、もっと控えめに、少なくともおおよそ見積もりをしてみましょう。評価プロセス全体は次のようになります。
- タスクを製品バックログに入れる。
- バックログで最も優先度の高いストーリーを任意の方法で評価します（方法はたくさんありますが、以下で説明します）。
- 私たちは仕事を始めます（たとえば、スクラムで-スプリントによって）。
- 数回のスプリントの後、各反復で平均していくつのストーリーポイントを取得するかを測定します。これが私たちのVelocityです-平均的なチーム開発速度です。
- . burndown chart. , .
しかし、世界は完璧ではないため、プロダクトオーナーが各スプリントを生成する新機能の数（ストーリーポイントでも推定）を修正します。赤い線はバックログの増加を示します。これで、赤い線と青い線の交点が目的の日付になります。
プロダクトオーナーが非常に創造的である場合は、次のようになります。
評価は正規分布の法則に従っていることを思い出しますが、プロットのねじれ-そのようなガウスは完全に合計されます。したがって、これが判明します（これはエンチャントされたバーンダウンチャートと呼ばれます）：
若い数学者の夢が実現したように見えます：混沌の山から美しいグラフが得られ、巧妙な外観で放送できます。 50％の確率でスプリント14で終了し、17日には80％の確率で、95％から19日には終了します。
このプロセス全体には、いくつかの落とし穴があります。
まず、部屋の中の象についてすぐに言います。バックログが多く、ユーザーストーリー形式の説明以外に何も知られていないタスクがたくさんある ので、いずれにせよ見積もりは非常に概算になり ます。大まかな見積もりが数学の言語でどのように見えるかについては、すでに上で示しました。
第二に、「開発者が異なる生産性で作業する」という問題は、原則としてまったく解決されていません。 ..。これは、確率が非常にフラットに増加することを意味します。これは、管理上の決定を下すのにあまり役立ちません。「50％の確率で、14番目のスプリントで80％の確率で、27番目に95％で終了します。 「39日」-つまり、数学の言葉では、「空への指」のように聞こえます。
したがって、私は個人的に「評価率」メトリックを最大化し、次に私が試した方法を説明します。
プランニングポーカーメソッド
これは、おそらく最も古いため、最も人気のある評価手法の1つです。
- プロセスの参加者は、フィボナッチ数で特別に番号が付けられたカードを使用します。
- プロダクトオーナーは次のストーリーを簡単に発表し、チームからの質問に答えます。
- 情報を受け取った後、「ポーカー」の参加者は、自分の意見で適切な評価のカードを選択し、誰にも見せません。
- 次に、すべてが一緒に明らかにされ、最低スコアと最高スコアの参加者が、スコアの選択を説明する短いコメントをします。
- ディスカッションプロセスの結果、チームは1つの決定を下し、次のストーリーに進みます。
このように1時間のセッションで、4〜8話を評価できます。これはこの方法の最大の問題です-それは長く、人々は退屈して気が散ります。「すべてが一緒に明かされる」という言葉を使ったのは無意味ではありませんでした。
「建築注文」方式
これは、現在私たちが仕事で使用しているアプローチです。重要なのは、タスクを相互に関連させて評価することです。これは、難易度でソートされた一連のタスクが構築される方法です。この方法では、最初に評価されたタスクのプールを蓄積し、それらをスケールに配置する必要があります。
- 評価するときは、各チームメンバーが交代で動きます（ボードゲームのように）。移動は次のようになります。タスクをスケールに配置し、タスクをスケールに沿って移動し、同僚とストーリーについて話し合い、移動をスキップします。
- その結果、タスクは常にボード上を移動し、チーム全体を満足させる状態が得られるまで、タスクの相互の評価が洗練されます。
- すべての参加者が順番を逃すと、完了です。
これは速いテクニックです。その助けを借りて、あなたは1時間あたり15-20の物語を見積もることができます、それは通常かなり十分です。
大きい/小さい/あいまいな方法
何度か使ったことがありますが、定着しませんでした。
- ボード上には、「大きなタスク」、「小さなタスク」、「不十分な情報」の3つのゾーンがマークされています。
- , «/». « » = « ».
- .
この方法には大きなプラスがあります-それは超高速です。したがって、1時間あたり50のユーザーストーリーを処理できます。
ここでは、これらの推定値をストーリーポイントに変換する際に問題がありますが、チームの速度がすでにわかっている場合は、Jiraでスプリントごとに噛むストーリーポイントの数を理解し、このメトリックに関する小さなタスクを評価します。
残りのタスクについては。次のセッションで再評価できるように、「不十分な情報」領域から分析にタスクを送信し、「大規模タスク」から分解にタスクを送信しました。
その結果、私たちの製品では、近い将来に書く時間があると思われる機能を備えたロードマップを描くだけです。時間がない場合は、そうですね。また、見積もりは、正規化した当面のタスクに対してのみ使用しますが、それでも常にではありません。
おそらく私は疑似科学的な観点から評価の分野で自分の無能さを投げかけることに従事していますが、個人的には、プロセス自体はかなり馬鹿げているように見えます。私たちが同じ安定したふりをするためにプレイする奇妙なカーゴカルトのようです。予測可能な業界。他の本当に安定した予測可能な業界のように。この分野でのあなたの経験について読みたいと思います。何かが足りないかもしれません。