第10回は、発表者が一周したので @kenchan が24章から26章をまとめました。
第24章 ユーザーにやさしい緩やかなバージョン移行
- ユーザーは変更は求めていない。よくできた新しい機能は使いたいが、今できていることはそのままやりたい。
- 一部のユーザーから始めるなど緩やかなバージョン移行が大事。
第25章 迅速な対応
- 製品の発売はゴールではない！
- 発売しないとわからないことがある！
- 製品開発の中で一番ROIを改善できるのは発売直後なんすよ
- すばやくバグを解決するとむしろ好印象・高評価になる
しかし現実は…
「開発直後にそのプロダクトの優先順位がダダ下がりになる」「リリース後に問題が多発する」→「あるある〜 (´・ω・`)」
なので…
「すぐに開発チームを解散しないで！」「リリース後も定期的にモニタリングしよう！」
第26章 アジャイルな開発手法を使いこなす
- POとデザイナーは、製品開発チームよりも1,2スプリント先行すること（開発チームの協力も必要）
- 「これ大事ですよね！！」
- 重厚な仕様書ではなくプロトタイプとユーザーストーリーを作ろう
- 開発者の環境でなく、ステージング環境で製品の品質を確保しよう
- ローカル環境ではさくさく動いたのにステージングでは重い…とかになりがちなので
- スプリントの最後には、現状のデモと次に開発するプロトタイプのデモをしよう
- 次のスプリント用のデモまでできてないなー
- 全員にアジャイル開発のトレーニングを受けさせよう
- ちゃんとしたコンサルを雇おう！共通認識を持とう！
補講：スクラムを「ちゃんと」やろう！
☆みんな、アジャイルソフトウェア開発宣言読んでる？
プロセスやツールよりも「個人と対話」
包括的なドキュメントよりも「動くソフトウェア」
契約交渉よりも「顧客との協調」
計画に従うことよりも「変化への対応」
左にも価値があるけど、右はもっと価値があるね！
☆スクラム、「ちゃんと」できてる？
- スクラムを知らない人・自己流でスクラムやってる人が多い。
- バックログのリファインメントをやってないチームが多い。
- プロダクトバックログがただのめんどくさい事案の塊になっていたりする。
▼スクラムガイドを全部読んで、まずはその通りにやろう！！ https://github.com/kdmsnr/ScrumGuide/blob/master/2013-07a/Scrum_Guide_2013_ja.pdf
▼その名もスクラムという本が出た！ 著者はスクラムの生みの親ジェフ・サザーランド。 http://www.amazon.co.jp/%E3%82%B9%E3%82%AF%E3%83%A9%E3%83%A0%E3%80%80%E4%BB%95%E4%BA%8B%E3%81%8C%EF%BC%94%E5%80%8D%E9%80%9F%E3%81%8F%E3%81%AA%E3%82%8B%E2%80%9C%E4%B8%96%E7%95%8C%E6%A8%99%E6%BA%96%E2%80%9D%E3%81%AE%E3%83%81%E3%83%BC%E3%83%A0%E6%88%A6%E8%A1%93-%E3%82%B8%E3%82%A7%E3%83%95%E3%83%BB%E3%82%B5%E3%82%B6%E3%83%BC%E3%83%A9%E3%83%B3%E3%83%89/dp/4152095423/