どういう時に「スクラム」フレームワークを使いたいのか - stefafafan の fa は3つです

我々も「スクラム」やるぞ！と言われても、イマイチどうしてスクラムでやりたいかが伝わっていないことがあると思います。あまり乗り気でない開発者は以下のようなことを感じているかもしれない。 スクラムを導入したところで嬉しさがわからない スクラム独自の用語が沢山あり、覚えるべき概念が多そうに感じる・学ぶための労力が割にあわないと思っている そもそもチーム改善とかに興味がない 改善に興味がなかったら厳しそうですが、スクラムを導入する嬉しさは簡単にでも紹介できたほうが良いと思うのであらためてちょっと整理してみます。 そもそもどういうことができているチームが優秀なチームかというのを考えると 以下のようなことができていると、優秀なチームなのかなと私は考えています。 改善サイクルが回っている（一定の周期で開発と振り返りと改善を繰り返すことができている） タスクが急遽差し込まれたり、方針が変わったときにスムー

[yigarashi]

要は変化に強いアジャイルなチームであればなんでも良いのだけど、まとまったやり方がスクラム一強すぎて一足飛びにスクラムやりましょうになりがちかもなぁとか考えた。丁寧な言語化だ〜

[tinsep19]

スクラムイベントが全て導入されてはじめて「1. 改善サイクルが回っている（一定の周期で開発と振り返りと改善を繰り返すことができている）」の状態になる

[hitode909]

いい話

[onk]

めちゃくちゃ良い言語化