ゲームプログラマのすすめ

https://coconala.com/users/3696234

Regional Scrum Gathering Tokyo 2017 報告会

スクラム関連のイベントに参加してきました。

devlove-kansai.doorkeeper.jp

セッション・スライド資料はこんな感じ。

 

2−1:つらい問題に出会ったら 開原 隆弘
http://www.slideshare.net/kaihara_t/rsgt2017

2−2:Scrumありがとう、そしてさようなら-Scrum 破- kyon_mm
https://confengine.com/regional-scrum-gathering-tokyo-2017/proposal/3246/scrum-scrum-

2−3:結果的にスクラムになってる!なのがいいと思う! 椎葉光行
https://speakerdeck.com/bufferings/jie-guo-de-nisukuramuninatuteru-nafalsegaiitosi-u-number-rsgt2017

2−4:アジャイルカルチャーが組織に根付くまでの挑戦 中村 洋
https://speakerdeck.com/yohhatu/asiyairukarutiyakazu-zhi-nigen-fu-kumatefalsetiao-zhan

3:Regional Scrum Gathering Tokyoの雰囲気を味わう

 ピザとお酒と一緒にスクラムについて色んな話やRegional Scrum Gathering Tokyo 2017の雰囲気などの話。

 

全体を通しての感想

スクラム推進派の方と会ったり話聞いてたりすると反ウォーターフォール?みたいなノリありませんか(笑)。本質としては最大限の利益を獲得できればウォーターフォール/スクラムでもどっちでもいいです。ただ手法として振り返りやユーザへの付加価値に目を向けることが日常的に組み込まれてる手法はときに変な拘りを持つエンジニアや若手エンジニアをコントロールするのに向いていると思う。私自身はスクラムの失敗経験からSCMを取得したりミニマムなチームでスクラムを実践したりはしているものの、そこから開発のしやすさ(気持ちよさ)が手に入ったことはあれどそれが最大限の利益を生み出すには至っていない。プロダクトやサービスの価値と開発手法に関連性がないならウォーターフォール/スクラムそれこそどちらでも良いことにならないだろうか。結論としては組織や開発メンバーのレベルに応じて手法を選択する必要があるのかなと思いました。

 

ちゃんとまとめられてる方がいらっしゃったので紹介しておきます。

blog.eumyang.net