サウスポーなエンジニアの独り言サウスポーなエンジニアの独り言サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。・・・と言われたので、もう少し書いてみます。「なかなか書けないなぁ」とウダウダしているうちに長沢(@tomohn)さんにも先を越されてしまったりしました。いや、でも本当にいい本なんですよ。私の説明や感想なんかより「とりあえず(2時間もあれば読めるから)読んでみてよ!」です。読書感想文ですがScrumを構成する事柄(原則やロール、イベント等々)について、「どういう背景で、なぜそれが必要なのか?そしてそれがなかったらどうなるのか?」とかなり深く書かれているように感じました。正解がない中でボクくん達のチームが何を考え、決断して、振る舞えば、より良いゴールに辿り着けるのか(これもあくまで”可能性が高くなる”の話ですが)がテンポの良いマンガとして描かれています。実際にScrumをやっていると、陥りやすかったり、悩みやすかったり、はまったりしやすい色々なポイントに対して「自分(著者達)ならこう考えて、こうするよ」と考えや豊富な経験を見事に文章に書かれている点も素晴らしいと思いました。#章やコラムによっては3人それぞれの声が脳内再生されたりして、ニヤニヤしました。マンガのように最初のScrumでこれほどうまく行くこと(それでも、ボクくん達チームはリリース間際は深夜残業な様子でしたが)は簡単ではないでしょうし、もしかするとプロダクトオーナー、チームメンバーが最初から前向きなのも、なかなか珍しいかもしれません。繰り返しになりますが、そんなところも含めてScrumの嬉しいところも、難しい(そんな簡単に上手く行かないよ)ところが余すところなく書かれています。Scrumを実践者はもちろん、「アジャイル、スクラムって聞いたことがあるんだけどなぁ」という方もぜひ読んで「こういう方法もあるんだ」と手持ちのカードを増やしてもらえたらと思いました。#自分が読みながらつぶやいたまとめ最後になりましたが、こんな素晴らしい本を届けてくださった著者のみなさん、ありがとうございました!※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。コメントをキャンセルメールアドレスが公開されることはありません。昔は良かった?年上の人と話すと、割と誰しもが感じる「昔は~だった」について、「自分もこうなったらあかんな」と自戒を込めて書きます。年上の方と話していると、時々「昔は...だった」という話が出てきます。...仕様変更における納得感の大事さシステム開発プロジェクトでは、仕様変更は程度の差はあれどあるものです。(デブサミ2014)】に参加してお話してきました。...徹底することの難しさやり方の改善や新手法を取り入れることがあります。今までの設計手法を「品質の向上を目的として、今度はこういう手法、方法をやってみよう...」等という時です。...未来の自分を信頼し過ぎないプログラミングにおいて他者のことを考えて「分かりやすいコードを書きましょう」「適切なコメントをつけましょう」というのは基本的なことです。この「他者」には、そう遠くない「未来の自分」も含まれています。Stories2)ギルドワークスの現場コーチ。「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。様々な規模のSIerでのシステム開発を経て今に至る。DevLOVE関西を主催。(14)サウスポーなエンジニアの独り言サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。