難しさは何ですか
顧客が時間とコストの観点からプロジェクトの正確な評価を得たい場合、それは十分に根拠のある状況です。 コストは用語に直接依存するため、ITプロジェクトで用語を評価することが難しい理由を判断しましょう。
- ソフトウェア開発は、知的活動のプロセスです。 以前に行われた典型的なタスクがありますが、そのような評価は難しくありません。 しかし、非標準のタスクもあります。 通常、プロジェクト作業の20〜30％を占めています。 これらのタスクを評価することはできません。これは、タスクにかかる時間と開発で発生する可能性のある問題がわからないためです。 簡単な例： 「ザポリツィーからモスクワまでバスで行くのにどれくらい時間がかかりますか？」という質問に答えてみてください。 そして、そのような旅行はいくらですか？」 あなたが以前にそこにいたことはまずないので、このタスクはあなたにとって標準的ではなく、どれだけのことかわかりません。 例で簡単です-私はバスステーションと呼ばれ、旅行の価格と期間を見つけました。 しかし、ここでも交通渋滞に巻き込まれるリスクがあります。 そして、顧客はあなたに電話して結果を揺さぶるでしょう。 そして、彼はそれを正しく行います。約束-それを行います。
- 顧客の要件。 ほとんどすべてのプロジェクトで、実装中に初期要件が変更されます。 顧客は何かを忘れるか、プロジェクトの開始後に新しいウィッシュリストが表示されました。
- 知的活動は開発者の資格であるという事実から生じる別の問題。 プロは、初心者よりも何倍も速くタスクを完了することができます。
これらの3つの理由を、問題のある性質の降順で記述しました。
どうすれば修正できますか？
最も単純なものから始めましょう-開発者の資格です。 この方法で解決されます。中級レベルの開発者がプロジェクトチームに行くか、初心者と専門家を1つのチームに入れて、彼が初心者を弱点に引き上げます。 したがって、速度は平均的な開発者の速度に平均化され、一定期間の認定の役割は大幅に低下します。
次の2つの問題はより深刻です。 2つ目-変化する顧客要件から始めましょう。
開発プロセスの構築には、スクラムとHEScrumの2つのオプションを使用します。
スクランブルを使用しない方が簡単です。要件は顧客から収集され、作業明細書と見積書が作成され、作業は厳密に作業明細書に基づいて開始されます。 ランディングページ、企業サイトなどの単純なプロジェクトを開発する場合、このアプローチを使用します。
しかし、TKのすべてを説明することはできません。そのため、プロジェクトでは常に論争の的になる問題が発生します。 たとえば、これは顧客が事実上の何かを期待した場合に発生しますが、私たちにとっては難しい（または長い）作業であり、時間がかかります。 顧客との関係を台無しにしたくないので、マネージャーがこの問題について話し合う時間を費やすか、プログラマーが問題を解決する時間を費やすか、マネージャーとプログラマーの時間を費やして代替問題とその解決策を考え出す必要があります。 この場合、私たちは通常、顧客のビジネスに最大の利益をもたらすオプションを選択します（「ウィッシュリスト」には深刻な正当性がなく、場合によっては害が及ぶことも多いため）。
大規模なプロジェクトでは、このような状況は必然的に発生します。 そして、今回はリスクとして発生します。 はい、それはあなたに衝撃を与えないでください、すべてのスタジオがそれをします、彼らはあなたが過払いするためにリスクに一定の時間を置きます。 そのため、一般に、多くの企業がプロジェクトで大きな不確実性を抱えています。
スクラムはどのように行われますか？
プロジェクトの大量のタスクリスト、つまりバックログがコンパイルされます。 顧客が望むように、それは優先度によってソートされます。 チームはこのリストから2週間の仕事を獲得しています。 2週間後、顧客は機能の完全に準備され、テストされた部分を受け取ります。 しかし、最も興味深いのは、過去2週間で顧客に何かが変わった場合、プロジェクト内のタスクの1つを安全に破棄できることです。 または、新しいものを入れてください。 または、優先度を変更します。 したがって、今後2週間の仕事で顧客が望んだものになります。 これが柔軟性のすべてです。 ただし、1つだけあります：顧客は、既に稼働中のタスクに対してタスクを変更、削除、または追加できません。 この2週間で
顧客との作業はtrelloで編成されます。
そして、チームの作業はyoutrackで整理されます。
したがって、リスクの変化に時間をかけることができず、プロジェクトに新しい要件を簡単に導入できます。これは、私たちにとっても顧客にとっても有益です。
最後の問題は、非標準タスクの期間の推定です。 ところで、同じ手法を使用して標準タスクを評価します。 私が説明するのは、スカーム、ポーカースコアリングの一部です。 タスクはバックログから順番に取得されます。 評価は、プロジェクトチーム全体によって実行されます。プロジェクトチームのメンバー（注意！）は、単一の決定を下す必要があります。 それらの少なくとも1つが同意しない場合、問題の議論が続行されます。 任意の単位で推定され、ストーリーポイント（sp）と呼びます。 これらの従来の単位はフィボナッチ数列の一部です：0,1,2,3,5,8,13,21。 評価が21を超えるタスクは、大まかな見積もりを避けるために必ず分解されます。
評価プロセス自体は次のようになります：このタスクを直接実装する最初の人は、それを実行したかどうか、どのようにプログラムするか、問題が発生する可能性がある場所、発生する確率を示します-これらはすべて、タスクの複雑さを評価するのに役立ちます。 その後、残りのメンバーは発言し、質問します。 それぞれにフィボナッチ数0、1、2、3、5、8、13、21のカードが8枚あります（カードの特別なデッキが使用されます）。 全員が投票する準備ができたら、全員が裏向きに1枚のカードを置きます。 すべてのカードがレイアウトされると、カードが裏返され、全員が評価を確認します。
したがって、誰も他の誰かの解決策を知りません。 すべての評価が収束した場合、投票は終了し、タスクに対応する難易度が割り当てられますが、少なくとも1人の参加者の評価が異なる場合、ディスカッションは続行されます。 誰もが自分の意見を弁護しなければなりません。
その結果、変化する顧客の要件に適応し、プロジェクトのタイミングを正確に予測できる柔軟なチームがあります。