こんにちは！
新卒エンジニアの大久保です。
最近プロジェクトでAngularJSを触ったのですが、今までjQueryで感じていたDOM操作の限界を軽々と突破できたことに感動しました！！
フロントエンドからバックエンドまで触れる現場なのでフルスタックエンジニアを目指して奮闘中です！
これからの時代、エンジニアだからといって求められるものが技術だけとは限りませんよね。
そうです、プロジェクトを引っ張れるエンジニアになるためにモダンな開発手法も身につけていく必要があります！
ということで、
今回も社内で行っているスクラム勉強会のお話です！！
第１９章 今後のことがわからない
開発後期で起こりがちなこと
> プロダクトバックログにいろんな人の要望が貯まる
スクラムではプロダクトバックログは一般的に誰でも追加できるものです。
開発の後期になるとプロダクトのイメージが固まってくることで
プロダクトバックログにいろんな人の要望が貯まりごちゃごちゃしてくることがあります。
プロダクトバックログに変更を加えられる人を決めるべき？
決めるべきではありません！！
プロジェクトの状況は絶えず 変化する
その変化に誰が気づくかわからない
- 開発チームかも?
- 利用ユーザーかも?
- プロジェクトの責任者かも?
プロダクトバックログに追加する担当を決めると
意見の反映が遅れたり、
誤解が生じたりする
そのため...
Q.プロダクトバックログに変更を加えられる人を決めるべき?
A.だれでも編集可能にしておくべき
プロダクトバックログを整理して 最善の方法見つけていくために...
1.重要なことを見逃さないように順序を見直す
※プロダクトバックログが新しく追加されたものなのかどうかということは一旦忘れて行う
2.見積りを最新にする
※プロダクトバックログの上位にあるもので見積りがまだのものや見積りが古いものを開発チームで最新の見積りにする
3.プロジェクトの進む先を整理するためにもう 一度順序を見直す
※新しく追加されたものが重要そうに感じるかもしれない、しかしリリースまでに全部を実装できるわけではない
プロジェクトのゴールを意識しながら再度順序の入れ替えをする
さらに...
- 慣れない内にプロダクトのバックログの整理をプロダクトバックログ・グルーミングというイベントにして定期的に実施するのも有効
- 順序の入れ替えは、インセプションデッキを確認するなどしてゴールを明確にすることが重要
第２０章 本当に着手していいのかな？
スクラムではスプリントごとにふりかえりがあるので問題を早期に発見できる
それでも...
手戻りは発生する...orz
プロジェクトの時間とお金が浪費されてしまう...
手戻りが起きる原因
- ＰＯと開発チームとの認識の相違
- 実現したいことに曖昧さが残っている
手戻りをなくすにはどうすればよいか？
曖昧さを減らす努力が大事！！！
ＰＯにできること
- 認識のズレを減らすためにペーパープロトタイピングを作成
- 開発チームとの密なコミュニケーション
開発チームにできること
- 技術的に難しい部分はないか
- 先に調査しておかないといけない箇所はないか
- 仕様に曖昧な部分はないか
などなど、意識して次のスプリントに向けた準備が必要。
こういったスプリントの準備を行うことで
スプリント計画が立てやすくなりベロシティの安定も図れる
(´・ω・｀)..oＯ(慣れないうちは作業を優先しがちで準備に気がまわらないことも多い。。)
文化を根付かせるために、
スプリントの準備にあてる時間を予めイベントとして組み込むチームも多い
準備のために全体の10~20%の時間を確保してスプリント計画に組み込むことも
第２１章 あれ！？間に合わない…
常にゴールに進んでいくことができればよいが、現実的には難しい...
プロジェクトの透明性の高いスクラムでは時にゴールから外れてしまっていることがわかることも...
ビジネス環境の変化でゴール自体が変わってしまうことも...
そんなとき、
調整するとしたらなに？
- 品質
- スコープ(機能)
- 期限
- 予算
- 品質を下げることはセキュリティリスクを上げることになりかねない。また後の保守性を下げることになる。
- 予算も予め決まっているもので変えにくい、また予算を増やして新しい人を増やしてもその人が成果を上げるまでには時間がかかり即効性がない。
- 期限はリリース日ありきで開発はスタートするので変更が難しい。またリリース日が遅れれば競合優位性を失くすおそれやその分予算を圧迫することもある。
スクラムで調整するべきは、
スコープ!!
ユーザーストーリーを実現するためにユーザーのログイン機能など重要なものを削るのは難しいかもしれない。
しかしユーザーが入力しやすいように入力フォームにエフェクトを加える仕様があった場合、それは削ることが可能だろう。
でも、一度に多くのことを諦めるのはツライよね...
そうならないために
プロジェクトが
ゴールに向かっているかを
常に確認し
微調整していく必要がある
