角征典のレビュー一覧

モダン・ソフトウェアエンジニアリング

ソフトウェアエンジニアリングの統一理論はまだ出現してないけど、そんな期待もできそうな。
自分達の開発プロセスを分析して抽象化して再構築して、記法を定義してって、まあエンジニアがいつもやってる事ではある。

モダン・ソフトウェアエンジニアリング

この本独自の用語や解釈があり、モダン・ソフトウェアエンジニアリングというのはあながち間違いでもないなと思った
おすすめしたい本

Clean Craftsmanship 規律、基準、倫理

Clean Craftsmanship

プログラマーのRobert C.Martin氏の著書です。

倍増する経験の浅いプログラマーに向け、プロのプログラマーが持つべき規律、基準、倫理とは、何であるかを解説した本になります。

【本書で学べること・考えること】
- 規律
XP(Extreme Programming)プラクティスの「サークルオブライフ」から、技術に関する以下の5つのプラクティスをベースに解説しています。
- テスト駆動開発
- リファクタリング
- シンプルな設計
- 協力的プログラミング
- 受け入れテスト
- 基準
基準とはベースラインとなる「期待」であると定義し、以下の項目を解説しています。 - 生産性
- 品質
- 勇気
- 倫理
倫理では、プログラマーの仕事の重要性を説き、プログラマーの誓いとして12項目について解説しています。

読んでみての感想です。

ボブおじさんのCleanシリーズの最新刊です。
本書の内容としては、テスト駆動開発、リファクタリング、シンプルな設計の規律に関する記述が多くを占めています。
特にテスト駆動開発が、すべてのスタートであり、これが無くては何も始まらないからです。
でも、TDDってやり方がわからない・・・
大丈夫です。
本書では、Web上でボブおじさんが実際にTDDを行っている動画を5本観ることができます。こんな感じで進めるのかとイメージが湧くと同時に理解しやすいです。
ボブおじさんのハイテンションも面白いです。(笑)

基準や倫理については、プログラマーの構成人員の関係上、あまり体系的にまとめられた資料がなかったので、非常に有益です。
今後も増え続けるプログラマー間の競争を生き抜くためにも、規律、基準、倫理を理解しておきたいと思える良書でした。

ちなみにサンプルコードはJavaです。

エッセンシャル スクラム

スクラムの基本的なポイントがおさえられ、かつ現実的に制約になりえるところ(複数プロダクトを見るチーム、SMと開発者の兼任など)にも目配りされた網羅的な一冊。
「グルーミング」など最新のスクラムガイドでは用いられていない用語があったり、この一冊だけでスクラムと向き合うにはいささか時が流れすぎてはいるが、ある程度習熟しているなら自己点検の意味でも読む価値のある一冊。

Clean Agile 基本に立ち戻れ

Clean Agile 基本に立ち戻れ

プログラマーのRobertC.Martin氏の著書です。

アジャイル宣言以後、プログラミングの世界で定着したアジャイルですが、広がるにつれ誤解も一緒に広がっています。
アジャイルとは何なのかを、基本に戻って確認するための一冊です。


【本書で学べること・考えること】
- アジャイルの歴史（アジャイル宣言）
- アジャイル概要
- サークルオブライフ（XP）
- 顧客、開発者の権利
- ビジネスプラクティス
- チームプラクティス
- テクニカルプラクティス
- アジャイルの価値基準
- 大規模アジャイル
- クラフトマンシップ


読んでみての感想です。

本書を読んで、アジャイルの基本を再認識することができました。
サークルオブライフのプラクティスを利用して、ビジネス・チーム・テクニカルの側面から各プラクティスを説明しています。
体系的にまとめられており、理解が進みました。
また、アジャイルの価値基準では、アジャイルは小から中規模のソフトウェア開発向けであり、大規模アジャイルやハードウェアのアジャイルなどはないということも再認識できました。
印象的だったのは、チームプラクティスでFace to Faceのコミュニケーションを非常に重視している点でした。ココは、普段の業務でも苦労しているので・・・
個人的には、TDDを実践するにあたり、うまくいっていないので、TDDに詳しい技術書を読んで、更に実践できるようにしたいです。

エクストリームプログラミング

原典。「どんな状況でも改善はできる。どんなときでもあなたから改善を始められる。どんなときでも今日から改善を始められる。」がフレーズとして大好き。

「XPはソーシャルチェンジである」も好き。

プロダクトリサーチ・ルールズ 製品開発を成功させるリサーチと9つのルール

プロダクトリサーチと表現されているが、昨今のユーザーリサーチ、UXリサーチと呼ばれる分野と同じ。
良いプロダクトを生み出すためにリサーチを取り込み、その質を高めようという内容で、リサーチするためのマインドセット、問の作り方から実行改善までの全体の流れ、リサーチ時のありがちなバイアスについてなど、リサーチ全体を網羅的に確認できる。
インタビュー等の各手法の深堀りについては専門書に任せることになるが、全体観で言えばかなりよくまとまっている。

エッセンシャル スクラム

スクラムを導入した会社のBiz側として必要な章だけかいつまんで、通読。
一気にスクラムの理解が深まった。

あとは業務上で必要な時に辞書として使うのが良さそう。

Clean Agile 基本に立ち戻れ

アジャイルマニフェストをベースとしたソフトウェアクラフトマンシップは、「柔よく剛を制す」に対する「剛よく柔を断つ」みたい。
どっちも大事。

Clean Coder プロフェッショナルプログラマへの道

全然良い本なんだけど、初心者には序盤が共感出来ず、中堅はClean Agileの方を読めば良いかなという感じ

Clean Agile 基本に立ち戻れ

アジャイルは経験したことがないが、もし経験した時にはこの本をもう一度読み返して、アジャイルの本質は忘れずに取り組んでいきたい。
アジャイルと一緒によくでてくるXPやTDD等、本書の言葉でいえばメソドロジーにこだわるのではなく、そのメソドロジーで叶えたいとしているイデオロギーを見据えることが大事であるというのは、見失わないようにしたい…。
本書ででてくるプラクティスも、いずれはよりよいプラクティスに代替され、マニフェストも塗り替えられていくのかもしれない。
アジャイルだけに限らず、ソフトウェアの開発手法の本質について考えさせられる内容でした。

Clean Agile 基本に立ち戻れ

アジャイルの生みの親の一人である著者による一冊。
間違って利用されることも多いアジャイルと言う言葉ですが、本書を読むことで基本に立ち戻り、改めて理解することができます。

アジャイルコーチング

身についている、実践できていることがほとんどだったが、客観的なアドバイスがまとまっており、自分でたまに読み返すのも、慣れてきたスクラムマスターに読んでもらうのも良さそう

Clean Agile 基本に立ち戻れ

読み終わるまでに結構が時間がかかりました、
サブタイトル「基本に立ち戻れ」にあるとおりAglileの基本と最近の状況を的確に指摘しており、とても示唆に富む内容でした。

P112 ハムエッグの話は評判がよくなく、最近は参照されない

Clean Coder プロフェッショナルプログラマへの道

ボブおじさんの長年のエンジニアとしての経験から、「プロのプログラマーであれば、こう振る舞うべし」と教えてくれる本。
子供が生まれて自分の働き方が大きく変わって早数年。いい意味で自分の働き方を見つめ直す良い機会になりました。

Clean Coder プロフェッショナルプログラマへの道

最初は読みにくいなぁと思っていた。
ただ、「２章の「ノー」と言う」につい食いつきました。

プロフェッショナルというのはどういうことか？という話なのですが、自分も含め、どれだけプロではないことをしていたのかと反省しました。
責任を持って、出来ないことを言うことが大事であること、コミュニケーションをとって、相手が何を望んでいるかを把握すること。その望みをかなえる為に、別の提案で出来ないかを考えること。

その他、プロが見積もりを立てる時、予定完了時間と分散を使った確立的な見積もりを提出することが多い。不確実性があるから、当たり前のことですね。

今まで、やってみますと言って、残業して必死に対応したものの、あまり役に立たなかった、使われなかったことが多々あるなぁ。もう、そんなのは止めよう。

エッセンシャル スクラム

翻訳が読みやすくてサクサク頭に入るのがすばらしい。ところどころにLeffingwellさんの名前が出てくるからSAFe系の図解が多く、エンプラ系に響きそう

エクストリームプログラミング

いいこと書いてあるんだけど、なんか読みづらいのは何故なんだろうか。今となっては当たり前に定着したことを、（今の感覚では）必要以上に丁寧に説明しているからだろうか。
でも、当たり前のことこそ明文化するのは大事で、だからこそこうした古典を読むのは大事だと思う。

図解リーン・スタートアップ成長戦略

新規事業をどのように立ち上げるか、「リーンスタートアップ」は知っていたが、ちゃんと本で読むのは初めて。書きやすく考えやすく、比較しやすいフレームで、考えるべきポイントがまとめてある。新規事業を検討する社内プロジェクトで使用。

エッセンシャル スクラム

スクラムを始めたときから、何回も開いている。
ここに答えはないが、考えるための要素がある。

これまで一気通貫で読んだことがなかったので、通しで読んでみた。
結果、あらためてスクラムは難しいと思った。

予想として良しとするのか、コミットメントしてやり切るのか。
どっちが正解なのかわからない。

本気なのか適当なのか。
本気でやってても、他人からみたら適当レベルに見えるかもしれない。

ただ開発はチームで行っていて、人と一緒にチームを形成している。
一人ひとりが異なるのだから、どのチームでも正解なんてないのと同じように、
そういうことを受け取られる可能性の一つがスクラムなのだと思う。

スクラムを用いることで、チームに最低限のルールを示し、
一人ひとりが異なることを前提に、チームで前進していくしかないのだろう。

（以下抜粋。○：完全抜粋、●：簡略抜粋）
○私自身は、開発チームはすべからく、各スプリントで何を届けられるかを予想（見積もり）しなければならないということに賛同する。しかし、予想を基にコミットメントを導きだすことで、利益を得られる開発チームも多い。コミットメントによって、プロダクトオーナーと開発チームの間にも、開発チームの内部にも、相互の信頼関係が築かれる。（P.18）
○プロダクト開発の初日には、自分たちが何をしているかについての情報は最も少ない。開発が続くにつれて、少しずつ学習していく。それではなぜ、最も重要で、おそらくやり直しの利かない判断を初日、もしくは初期に行おうとするのだろうか？（P.38）
○ただ実際のところは、ほとんどの技術的ストーリーはプロダクトバックログに入れるべきではない。代わりに、これらのストーリーはビジネスストーリーの関連タスクとするべきだ。（P.88）
●プロダクトバックログアイテムの例：PBIの形式は、フィーチャー、変更、不具合対応、技術的な改善、知識の獲得
○みんなでグルーミングすることでさまざまな意見がを引き出せることを知っている。みんなの意見や、それぞれの立場から視点を活かせば、重要な情報をもれなく引き出せる。また、いろいろな立場のチームのメンバーをグルーミングに参加させると、プロダクトバックログについての明確な理解を共有できる。（P.102）
○見積もりはコミットメントではない（P.120）
○技術的負債があまりにも増えすぎてしまうと、そのプロダクトに関して何らかの予測をするのはほぼ不可能になる。（P.139）
○負債を返済する手段として一括払いを選ぶことが多い。それよりは、何回にも分けて、適切なタイミングでインクリメンタルに既知の技術的負債を返済していくほうがよい。（P.154）
○チームを小さく保つ理由を以下のように述べている。
・誰かがやってくれるから自分はやらあくてもよいという「社会的手抜き」が少ない。
・小さなチームは建設的なやり取りが頻繁に発生する。
・調整に必要な時間が少ない。
・誰も陰に埋もれることがない。
・小さなチームのほうがメンバーを満足させることができる。
・有害な過度の専門家が発生しにくい。（P.197）
●Appelo による7段階の権限レベル、通知、説得、相談、合意、助言、確認、委譲（P.218）
●伝統的なプロジェクトマネージャーの責務は一貫性の管理、スコープ、時間、コスト、品質、チーム、コミュニケーション、リスク、調達。PO、SM、開発チームはこれらの責務を分割、あるいは共有する。（P.226）
○事前にきちんと計画を作れると思うな（P.235）
●プランニングのレベル（P.244）
・ポートフォリオ：おそらく年単位
・プロダクト：数か月単位、あるいはもっと長期
・リリース：3か月から9か月
・スプリント：1週間から1か月
・デイリー：毎日
○MRFは最低限の「必須」フィーチャーを表すものだ。つまり、顧客が期待する価値や品質をもたらすために、今回のリリースに必ず含める必要があるフィーチャーである。リリースプランニングの中でも重要なのが、今回のリリースにおける真のMRFが何なのかを再評価して見直すことだ。（P.300）