システム開発 スクラム

スクラムについて考察01

投稿日:2018年10月16日 更新日:

Scrum

スクラムについて考察

実際に試してみて、うまくいかなかった点などについて、あれこれ考えてみます。
「それはおかしい」内容も出てくると思いますが、初心者の感想なので多めに見てください。
徐々に改善していきたいと思っています。

自己組織化されたチーム

  • トップダウンのピラミッド型ではなく、各人が適した場面でリーダーシップを発揮するアメーバ型の組織
  • 全員がメンバーの特性を理解している&全員そろえば対処したい領域をカバーできる
  • 「自分たち」の責任が大きくなるため、不安を取り除く必要がある
  • スクラムマスターは「スクラムのプロセスに詳しい」人、スクラムイベントなどでリーダシップを発揮する

なぜスクラム?

  • 単純に早くなるのかと思ったが違った
  • プロダクトオーナーと頻繁に認識合わせができて手戻りを減らせる
  • メンバーの意思統一、スキル平準化、フォロー環境
  • ウォーターフォールでうまくやる方法はないのか?

スクラムの向き不向き

  • プロダクトオーナーがいないとスクラムは無理
  • Readyにできない、時間がかかるものは無理、要件は決まっていてほしい
  • 納期がある物、規模が大きいものは初心者には難しい
  • 外部との連携・調整が必要なものも難しい
  • 既存システムの保守改修は向いていそう
  • 「やりたい」という気持ちが大切

スプリントの長さはどれくらいが適切?

  • プロダクトオーナーを捕まえるには「◯営業日」よりは「◯週間」で特定曜日にイベント設置がよさそう
  • ころころ期間を変えるのはリズムをつかむにも、ベロシティを測るにも不適切なので固定にする必要がある
  • とはいえ、1週間で短すぎるなら長くする必要もある(価値を提供できないと意味が無い)
  • どの長さが適切化はチームの熟練度、プロジェクト対象の特性によって決めればよさそう

酔いどれまさになう。

関連

スクラムについて考察01




-システム開発, スクラム

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください

関連記事

Review

設計レビューを効果的に行うには、目的を理解してそれに沿った方法で行おう

レビューあるある 長い 喧嘩してる、槍玉に上げられてる 脱線する 重箱の隅をつついていている 不具合を見つけたけど黙ってる などなど、結果として時間はかかる、気分も悪い、その割には後で不具合が見つかる …

お菓子

エリック・エヴァンスのドメイン駆動設計(DDD本)読書会

エリック・エヴァンスのドメイン駆動設計(DDD本) の読書会を社内有志で行いました。 その時の記録を残しておきます。 第0回 準備を兼ねた第0回は、スケジュールや進行方法について相談しました。 スケジ …

読書会

アジャイルサムライ横浜道場参加記録

アジャイルサムライ横浜道場 説明は以下を参照してください。 https://github.com/agile-samurai-ja/support/wiki/Readingagilesamuraiin …

カテゴリー