小さな.Netチームにスクラムアジャイル手法を採用する方法
.Netアプリケーションを開発している小さな製品ベースの会社に取り組んでいます。 5-6人の開発者からなる小さなチームがあります。私はすべてを計画する責任者です。しかし、私の主な役割はソフトウェア開発者です。
現在、私たちの現在のプロジェクトは、組織が不十分なために非常に不安定です。今日、上司から電話があり、現在のプロジェクトを成功させるために必要なリソース、適切な方法論、必要な人員と給与のスケールに関するレポートを提出するように言われました。
十分な編成スキルがないので、プログラミングスキルをさらに深める必要があります。ですから、開発のみに集中する必要があります。そのため、プロジェクトを管理できなくなりました。
現在、継続的な開発を成功させる他の方法を探しています。私の質問は
- 私のチームに適したアジャイル手法は何ですか？
- スクラムは上記のシナリオに適していますか？
- スクラムを採用した場合、次に何をする必要がありますか？ （私はプロジェクトを管理するために新しいものを雇うのがより適していると思います。それで私たちはスクラムマスターと他の何人かの開発者を取得しなければなりません。）
- この問題を解決するためのヒントやアドバイスを入手するためのリソース（本、ブログなど）はありますか？
- スクラムが私たちのシナリオに適した方法論ではない場合、他に採用するのにより適切な方法論はありますか？
誰かが私の問題に良い解決策を与えることができますか？
はい、スクラムは非常に適切ですが、それについてもっと学ぶ必要があります。 ケンシュワバーの本 は、スクラムマスターがプロジェクトマネージャーではない、チームが自己組織化する必要があるなど、多くのことを教えてくれます。
アジャイルルートを使用する場合に必要となる主なものは、自分の前に落とされたボールを自己動機付けして拾うことができるチームです。開発全体を通してチームと緊密に協力することをいとわないお客様です。プロセス、および現在および長期的な範囲とその優先順位の範囲内にある必要があるものを決定するための手段を備えた製品所有者。
したがって、最初にスクラムについてもっと学び、それが適切かどうかを判断する必要があります。そのように決定した場合は、すべての利害関係者と話し合い、彼らがそれを実行する用意があるかどうかを確認する必要があります。うまくいけば、彼らの1人がプロダクトオーナーとして手綱をとることになります。次に、雇用するか、スクラムマスターになる必要があります。
「現在のプロジェクトは、組織が不十分なために非常に不安定です」とあなたは言います。これに対して上司は、「すべてを計画する責任者」に主な仕事が「ソフトウェア開発者」であるが「プロジェクトをこれ以上管理できない」と前もって計画を立てるよう依頼しました。私はソフトウェア開発者としてもプロジェクトマネージャーとしてもあなたの能力を批判していませんが、ここには開発方法論では解決できない大きな問題があるのではないかと思います。あなたの問題のいくつかと、スクラムがどのように役立つかどうかを推測させてください。
スクラムは、不正確または変化する要件の処理に最適です。チームは要件を実装し、製品の所有者（顧客）が見て、将来のスプリントの改善を提案するリリースを作成します。製品の所有者が「何を見たらわかるか」で何が欲しいのか正確にわからない場合に特に便利です。
ただし、スクラムはそのような要件の作成を強制しません。製品担当者になるための顧客担当者にアクセスできない場合、スクラムの利点の一部が失われます。
スクラムは、進歩を示す優れた方法です。あなたが何かを提供できるという信念を人々が失っている場合、目に見える改善の定期的なリズムを提供することは非常に役立ちます。
ただし、必要な機能を備えた不動の締め切りがある場合、スクラムは同様に機能しません。実際、開発方法論にはありません。スクラムは、機能のサブセットを高品質で実装するのに役立ちますが、特効薬ではありません。
スクラムは、期限の指示や詳細な事前計画の確認に慣れている非技術者にも説明するのが難しい場合もあります。多くの人々は、「計画通り」を「カウボーイコーディング」として聞き、コントロールの明らかな喪失を警戒しています。スクラムを実装したい場合は、それほど重要ではないプロジェクトを選び、それが機能することを実証する方が簡単かもしれません。それ以外の場合、ここで実装してプロジェクトが失敗すると、将来のプロジェクトで使用するのがはるかに難しくなります。