どこぞのエンジニアなマネージャーのブログ。

Perlとかviとかcssとかjavascriptとか(rubyとか)git >> https://github.com/rozary hatenaIDがrozrayなのはtypo

2月22日、アトラクタさんのスクラムトレーニングに行ってまいりました。

コスパ最強?

1日通しの研修でした。
認定スクラムマスター研修は、3年前?4年前?に行っているんですが、
自分の状況も変わったので、再発見・学習の為にと参加してきました。

端的に行ってしまうと、1日の研修なのにかなりの再発見があったなぁと感じました。
スクラムマスター研修は2日 or 3日ですが、
今回のは1日の開催なのにも関わらず、かなり中身があるもでした。

得たものがたくさんあったので、その中でも特にというものをまとめてみる。

スクラムは、カオスな環境にこそ必要。

スクラムは変化に適応することを重視しているプロセスだと思いますが、
まさにその通り、要求が変わる、増えるといったプロジェクトにこそ使われるとよい。
要件定義から1個1個決定し戻れない(戻るには改めてプロジェクトが始まる状態になる。)ウォーターフォールは、
変化に適応しづらい。
言ってみればその通りなのだけれど、チームビルド的な内容もスクラムは持っているので、
カオスなのかそうでないのかという指標で導入をする、しないみたいなことも判断すると良い。
アジャイルは速度を出すものよりは、変化に適応するための手法。
オーダーメイド的プロジェクトに対する答え。

見積もり以上のものをやろうとして失敗する(ことがある)。

見積もり=合意をとった状態なので、それを完了できるようにすればいい。
見積もり以上のものをやる必要はない。<<オーバーコミット。
そして失敗しては意味がない。
この場合の見積もりは、成果物見積もり。人日の見積ではない。
この辺がちょっと、ウォーターフォール的なやつと違う。
この期間にこの成果物を完成をします。という見積もり、合意。
この作業をやるのに、この人日が必要。とは逆の感覚。

(難しい問い)人数が少ないチームの場合、技術領域がカバーできずに1チーム1スプリントで完成させることが出来ないのではないか??

人数が少ないならクロスファンクショナルになる。
クロスファンクショナルが難しい場合は、
アーキテクチャを揃えてチームを越える。
プロトタイプ的、ダミーのものでレビューをかける。
ミニウォーターフォールをある程度受け入れざるを得ない事もある。
チームごとにready状態を意識する。
=>足回り(アーキテクチャやダミー、開発フローも含まれるだろうか?)を固めるのが重要。

プロダクトオーナー=プロダクトマネージャー??

プロジェクトの価値を考えるのかプロダクトの価値を考えるのか。
自分の周りでは、作っておわりではなく作ってからも価値を変更、追加していくプロダクトが多いので、
プロジェクトマネージャーよりもプロダクトマネージャー的思考・活動の必要性を感じる。
※プロダクトマネージャーは4年程前からプロジェクトマネージャーから必要に迫られて分岐した。
的なことをこないだのdevsumiで聞いた。

結び

という感じで、かいつまんでまとめてみた。

なんか研修にいくことでウラ(研修とは別の話)ではいろいろとありましたが、
幸せに終えることができました。

次回はQAアジャイルの研修だそうです、これからもアトラクタさんのトレーニングには期待です。