Размер видео: 1280 X 720853 X 480640 X 360
Показать панель управления
Автовоспроизведение
Автоповтор
めっちゃ良いですね。弊社内に紹介させていただきます。
講座は最高でした。様々案件に適用させて頂きます。
為になる動画ありがとうございます!!!今の会社では、アジャイル開発ですが、スクラムほどしっかりした枠組みで回せて居ないのが現状です。スクラム開発の「各々がタスクに集中できる」という部分に特に魅力を感じました。ただ、一方で現在や運用や一部問合せ対応も行なっている為、どうしても計画時に出てこないタスクが頻繁に途中で生まれている状況です。そういうチームでスクラムを回すとすると飛び込みの運用タスクに対してどういった解決策が考えられるでしょうか?運用タスクは、別枠で時間を設けて対応する。(スクラムには入れない)などでしょうか?何か、実践例や、アドバイスありましたらお教えください。
明日以降に返信します!
スクラムをやるときはまずはスクラムの型を守ることをオススメします。スクラムの型を守らないと、多くの場合失敗します (私も失敗しました)。スクラムの型の中で今回の件と関係するものは、スプリントゴールですね。スクラムでは、スプリント中はスプリントゴールを達成することが優先されます。スプリントゴールはスクラムで数少ない約束事の1つで、開発チームで必ず達成すべきものです。差し込みタスクで、スプリントゴールが達成できないようなスプリントが続くと、スプリントゴールが形だけのものとなってしまい、何に集中して開発すればいいかがわからなくなり、スクラムが機能しなくなります。スプリントゴールが達成できないような差し込みタスクが入る場合は、スプリントを中止するという判断をプロダクトオーナーにして貰う必要があります。スプリントを中止するのか、差し込みタスクを次のスプリントに回すのかは、プロダクトオーナーが最終的に意思決定してもらうとよいです。とは言えども、かたおかさんの状況のように、通常は差し込みタスクが発生しがちです。なので、差し込みタスクがなぜ発生するかを洗い出すことが重要だと思います。スプリント中の差し込みタスクが発生することの原因としてよく以下の4つが挙げられます。1. スプリントプランニングが不十分2. スプリントが長すぎる3. 障害が起きた4. スクラムに関してのステークホルダーの理解が不十分1の「スプリントプランニングが不十分」であることに関しては、プランニングの時間をしっかり取ることも大事なのですが、チーム内でのスプリントゴールに対する認識を改めることも重要です。スプリントゴールはプロタクトオーナーと開発チームの約束事で必ず達成するもの、それを達成するためのタスクをきちんとプランニングで考える。スプリントプランニングを曖昧にすると、関連するタスクがスプリント中に多く発生してくるようになります。もちろん、実際に作業したあとに新たなタスクが発生することが完全に防げるわけではないですが、プランニングをしっかりやることで、大抵の場合防ぐことができると思います。2の「スプリントが長すぎる」ことに関してですが、最初差し込みタスクの対応に慣れていないうちは、スプリントを短くしておくのも手だと思います。スプリントが短いと、差し込みタスクが来たとしても次のスプリントに回しやすくなります。スプリントが短いと達成できるスプリントゴールは小さくなりますが、プランニングが容易だったり、短い期間での学習が可能になるという利点もありおすすめです。3の「障害が起きた」場合は、こちらはサービス上以上避けられないものではあるので、スプリントを中止するなどして対応することを検討すると良いと思います。もちろんスプリントゴールが達成できるのであれば、スプリントを中止せずに差し込みタスクをやッテも大丈夫だと思います。4の「スクラムに関してのステークホルダーの理解が不十分」に関しては、現場あるあるのはなしだと思います。ステークホルダーは開発チームがどのようなワークフローに従って働いているかを知りません。そのため、どのタイミングで依頼をしていいのか分からないため、悪意なく差し込みタスクを依頼しがちです。ここに関しては、障害などの緊急タスク以外は基本的にスプリント中は差し込めないことをステークホルダーに理解してもらっておく必要があると思います。そのためには、スクラムマスターによるスクラムに関するティーチングがステークホルダーには必要です。また、もう一つ差し込みタスクを発生させないためには、チケットの起票をできるようにしておくなど、タスクの受け皿を用意しておくことが重要です。起票されたチケットがきちんとスプリントが始まるときにさばかれることを伝えておくと、ステークホルダーもより安心してくれると思います。ざっと色々述べましたが、スプリント中は基本的に障害などの緊急自体以外やることを変更せず、次のスプリントに回すことを徹底することで、プランニングの重要度が増して、よりよいスプリントにできると経験上思っています。そのためには、どんな差し込みタスクがあって、それが緊急かどうか、仕組みで解決できるものではないかを考えてみるといいと思います。長くなりましたが、参考になさってください。もしまた何かあれば、コメントでもメッセでも答えられると思うので、お気軽にご質問ください。
@@kenichiro-nishioka ご丁寧な回答ありがとうございます。現状、一番多くある差し込みタスクが「顧客からのお問い合わせ」です。クライアントとの問合せなので、早めに対応した方がいいと考えていましたが、一歩引いて、ゴールを考えて>それが緊急かどうか、仕組みで解決できるものではないかを考えてみるを行ってみます。また、4の「スクラムに関してのステークホルダーの理解が不十分」というのも該当していると感じてきました。こちらを肝に、よりより運用回せないか考えてみます。ありがとうございます!!!
めっちゃ良いですね。
弊社内に紹介させていただきます。
講座は最高でした。
様々案件に適用させて頂きます。
為になる動画ありがとうございます!!!
今の会社では、アジャイル開発ですが、スクラムほどしっかりした枠組みで回せて居ないのが現状です。
スクラム開発の「各々がタスクに集中できる」という部分に特に魅力を感じました。
ただ、一方で現在や運用や一部問合せ対応も行なっている為、
どうしても計画時に出てこないタスクが頻繁に途中で生まれている状況です。
そういうチームでスクラムを回すとすると
飛び込みの運用タスクに対して
どういった解決策が考えられるでしょうか?
運用タスクは、別枠で時間を設けて対応する。
(スクラムには入れない)などでしょうか?
何か、実践例や、アドバイスありましたらお教えください。
明日以降に返信します!
スクラムをやるときはまずはスクラムの型を守ることをオススメします。
スクラムの型を守らないと、多くの場合失敗します (私も失敗しました)。
スクラムの型の中で今回の件と関係するものは、スプリントゴールですね。
スクラムでは、スプリント中はスプリントゴールを達成することが優先されます。
スプリントゴールはスクラムで数少ない約束事の1つで、開発チームで必ず達成すべきものです。
差し込みタスクで、スプリントゴールが達成できないようなスプリントが続くと、スプリントゴールが形だけのものとなってしまい、何に集中して開発すればいいかがわからなくなり、スクラムが機能しなくなります。
スプリントゴールが達成できないような差し込みタスクが入る場合は、スプリントを中止するという判断をプロダクトオーナーにして貰う必要があります。
スプリントを中止するのか、差し込みタスクを次のスプリントに回すのかは、プロダクトオーナーが最終的に意思決定してもらうとよいです。
とは言えども、かたおかさんの状況のように、通常は差し込みタスクが発生しがちです。
なので、差し込みタスクがなぜ発生するかを洗い出すことが重要だと思います。
スプリント中の差し込みタスクが発生することの原因としてよく以下の4つが挙げられます。
1. スプリントプランニングが不十分
2. スプリントが長すぎる
3. 障害が起きた
4. スクラムに関してのステークホルダーの理解が不十分
1の「スプリントプランニングが不十分」であることに関しては、プランニングの時間をしっかり取ることも大事なのですが、チーム内でのスプリントゴールに対する認識を改めることも重要です。
スプリントゴールはプロタクトオーナーと開発チームの約束事で必ず達成するもの、それを達成するためのタスクをきちんとプランニングで考える。
スプリントプランニングを曖昧にすると、関連するタスクがスプリント中に多く発生してくるようになります。
もちろん、実際に作業したあとに新たなタスクが発生することが完全に防げるわけではないですが、プランニングをしっかりやることで、大抵の場合防ぐことができると思います。
2の「スプリントが長すぎる」ことに関してですが、最初差し込みタスクの対応に慣れていないうちは、スプリントを短くしておくのも手だと思います。
スプリントが短いと、差し込みタスクが来たとしても次のスプリントに回しやすくなります。
スプリントが短いと達成できるスプリントゴールは小さくなりますが、プランニングが容易だったり、短い期間での学習が可能になるという利点もありおすすめです。
3の「障害が起きた」場合は、こちらはサービス上以上避けられないものではあるので、スプリントを中止するなどして対応することを検討すると良いと思います。
もちろんスプリントゴールが達成できるのであれば、スプリントを中止せずに差し込みタスクをやッテも大丈夫だと思います。
4の「スクラムに関してのステークホルダーの理解が不十分」に関しては、現場あるあるのはなしだと思います。
ステークホルダーは開発チームがどのようなワークフローに従って働いているかを知りません。
そのため、どのタイミングで依頼をしていいのか分からないため、悪意なく差し込みタスクを依頼しがちです。
ここに関しては、障害などの緊急タスク以外は基本的にスプリント中は差し込めないことをステークホルダーに理解してもらっておく必要があると思います。
そのためには、スクラムマスターによるスクラムに関するティーチングがステークホルダーには必要です。
また、もう一つ差し込みタスクを発生させないためには、チケットの起票をできるようにしておくなど、タスクの受け皿を用意しておくことが重要です。
起票されたチケットがきちんとスプリントが始まるときにさばかれることを伝えておくと、ステークホルダーもより安心してくれると思います。
ざっと色々述べましたが、スプリント中は基本的に障害などの緊急自体以外やることを変更せず、次のスプリントに回すことを徹底することで、プランニングの重要度が増して、よりよいスプリントにできると経験上思っています。
そのためには、どんな差し込みタスクがあって、それが緊急かどうか、仕組みで解決できるものではないかを考えてみるといいと思います。
長くなりましたが、参考になさってください。
もしまた何かあれば、コメントでもメッセでも答えられると思うので、お気軽にご質問ください。
@@kenichiro-nishioka
ご丁寧な回答ありがとうございます。
現状、一番多くある差し込みタスクが「顧客からのお問い合わせ」です。
クライアントとの問合せなので、早めに対応した方がいいと考えていましたが、
一歩引いて、ゴールを考えて
>それが緊急かどうか、仕組みで解決できるものではないかを考えてみる
を行ってみます。
また、4の「スクラムに関してのステークホルダーの理解が不十分」
というのも該当していると感じてきました。
こちらを肝に、よりより運用回せないか考えてみます。
ありがとうございます!!!