角谷信太郎のレビュー一覧

アジャイルサムライ――達人開発者への道

2011年の出版。それでも色あせていない。インセプションデッキという考え方。相対サイズの見積、リファクタリング、テスト駆動開発、継続的インテグレーションといったアジャイルならではの手法。「イテレーション計画ミーティング」「ショーケース」「デイリースタンドアップ」「ミニふりかえり」というイテレーションの運営。アジャイルに必須の要素が詰まっている。お陰様でアジャイル検定レベル１に合格できた。実践に使えるかはこれから。

アジャイルサムライ――達人開発者への道

アジャイル開発の概要を理解したいときに読む本。
事例を踏まえて学びたいときは、次に「アジャイルな見積りと計画づくり」を読むとよい。

アジャイル開発は、実態を可視化しづらいウェブアプリを前提としており、実態やプロトタイプを作る組み込みの世界にそのまま適用できなさそう。
特に、エンドユーザが直接的に価値を感じ取れないデバイス系や、Tire2サプライヤの開発には適用が難しいと思った。

組み込みの世界に適用できないところ。
　１．部分発注
　２．途中からの機能ドロップ
　３．ストーリベースの開発
　　　　ハードウェア上でソフトウェアが動くので、
　　　　どうしてもソフトウェア階層の下位から上位へ開発が進むので、エンドユーザへリリースできない。

組み込みの世界に適用できるところ。
　１．インセプションデッキでプロジェクトの外観を知る
　２．TDD　検証基準で顧客と合意しておく。

アジャイルサムライ――達人開発者への道

アジャイル開発の方法・志を説明している本です。
軽快な文章であり、それに加えて300ページほど文量なので非常に読みやすかったです。
開発者ならアジャイルについて理解するためにも読むべき本だと感じました。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

とても良い本でした。
ソフトウェア開発にたずさわる読者に、「アジャイルであること」とは何なのかを理解させ、アジャイルプラクティスの試行を大いに助けてくれる本です。
アジャイル(Agile)とは、直訳すると「機敏である」ということ。
ソフトウェア開発において、最終的な製品の仕様が開発段階であらかじめ完璧に決まっているなんてことはあり得ないんだから、当然完璧な要求仕様やスケジュールなんか最初から組めるわけない。エクセルで開発スケジュールを作り、スケジュールが変化するたびに(スケジュールは当然変化する)エクセルのスケジュールをちまちま編集する、そんな馬鹿げたことに無駄な時間と労力を費やすよりも、とにかく作ろうとするソフトウェアをモジュール単位に分割して、何かしら設計してみて、コーディングして、コンパイルして、テストして・・・のサイクルを機敏に繰り返して素敵な製品を作って進化させていこうよ、という設計姿勢が「アジャイルであること」らしいです。
開発段階では仕様が確定していないので、素敵な製品の定義というのもこの時点では曖昧です。アジャイル開発は、その曖昧さを解消するために、ソフトウェア開発者にユーザーと常に接することを求めます。作った(あるいはテスト中の)ソフトウェアをユーザーに見せ、ユーザーからのフィードバックを反映し、より良いアイデアを能動的にユーザーに提案し、再テストする。この繰り返しが、ユーザーにとっての素敵な製品とは何かを定義づけていくプロセスであり、この繰り返しのプロセスを設計者がアジャイルに(機敏に)できる環境を構築することが、アジャイル開発の肝であるようです。それは例えば、分割したモジュールのコンパイルが容易であるとか、自宅からでもモジュールのチェックイン/アウトができてどこにいてもソフトウェアが作れる環境にあるとか、競合(同モジュールをチームの複数人が同時に編集しようとする)が発生しにくい仕組みやチームワークを構築する、といったことです。
チームワークの重要さもよく述べられていました。現代のアプリケーションの規模を見たときに、そのソフトウェア開発をひとりで行うケースというのは現実的でなく、ソフトウェア開発は常にチームで進められるものであるから、そのチームワークは大切であるとのことです。その有効な方法として例えば、短いスタンドアップミーティングをチーム内で毎日実施して開発者同士の進捗を確認するとともに交流を深めたり、ひとりひとりがチームにとってのメンターになる意識を持って自分の知識をチームと共有する機会を設けたり、といったことです。自分の知識は思わぬところで他人の役に立つことがあるから、とにかくメモ書きでもブログでもなんでもいいから残して共有しておくと良く、またそれを継続するためには自分自身が常に勉強する意欲と他人から教えを請う姿勢が常に求められるので、結果として自分もチームメンバーも互いに向上し合える、というのが「メンターになる」ことのメリットだそうです。(実際、「アジャイル開発」という言葉を全く知らなかった僕がこの本を読むことになったのも、チームの先輩から教えてもらったことがきっかけでした。)

最後に、ソフトウェア開発における「設計」について述べられた文章が印象的でしたので、ご紹介します。

『設計とは、直面している問題それぞれに固有の解決策である。現場でそのまま使えるほど詳細に事前設計することは難しい。最初の段階では、まだ問題の背景も十分わかっていないし、フィードバックもほとんどない。設計は時とともに進化するのだ。アプリケーションの実態(そして実装)を無視して、新しい機能や機能の強化を設計することはできない。(著書より抜粋)』

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

読みやすくてためになった
プログラミングの会社に勤めている人なら部分的に取り入れるだけでもいいと思う

リーン開発の現場 カンバンによる大規模プロジェクトの運営

プロジェクトを進めるにあたっての考え方を学べる一冊。
アジャイルやXPなどの様々な手法と比較して、how toを伝えるだけにならず、どうやったら継続して改善できるかを書いていて、試そうと思える方法がいくつもあった。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

まだアジャイルの概要以外何にも知らない状態から読んだ。
易しい言葉で書かれているので読みやすいし、すんなり理解できて良かった。
実際の現場と比較しながら読めたのも面白かった。

リーン開発の現場 カンバンによる大規模プロジェクトの運営

簡潔なのに、かなり包括的。中心は実例ベースだけど、最後にテスト自動化や因果関係図、プランニングポーカーまで載ってる。
継続的リリースを、警察機関の報告業務アプリで実現させたとのこと。こういう開発を日本でもやらなきゃいけない。

リーン開発の現場 カンバンによる大規模プロジェクトの運営

カンバンを使うことによる組織のコラボレーションと進化の仕組みであると理解した。
カンバン上に表現することで、コミュニケーションが発生し、問題が可視化され、カイゼンする文化が築かれ、枠を超えた信頼とコラボレーションが発生するのだ。

現在のプロジェクトで利用しているタスクボード上にも、エモーションチケットやKPT、割り込みタスク、やりたいこと、バッファなどが発生している。これもいわゆるカイゼンプロジェクトボードという形でスケールしているんだなぁ。

-引用-
プロジェクトメンバーを集めて、自分たちのコンテキストでの「理想」を見つけよう。...理想の探求は、進むべき道を示すコンパスになるはずだ。理想を達成することが必要なのではない。理想とはたどりつくべき場所のことではなく、ありたい姿に向かい続ける事なんだ。

優れたプロセスは、設計によって生み出されるものではない。進化の結果として表れるだから、現在行っているプロセスが重要なのではない。現在のプロセスを改善するためのプロセスこそが重要なんだ。

本当の失敗はひとつしかない。それは、失敗から何も学ばないという失敗だ。

結果が重要なのではない。人と結果を出せるシステムを育てるのが重要なのだ。

学びとは、ただ知る事ではない。知識は頭の中のものだが、学びとは手の中にあって、熱意によって行動に移されるんだ

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

テスト駆動開発、継続的インテグレーションといったいわゆるアジャイル手法についてひと通り書いてある本。（良書だと体系的にまとめてあると表現するところだが、別に体系的になっているわけではない）。ブログとかで色々散見したものが1冊にまとまっているので考えを改めて整理するにはいいと思います。これからエンジニアとして一歩を踏み出す人におススメです。すでにアジャイル関連のブログとかで知識がある人は改めて読むこともないかなと。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイル開発をするうえで必要な習慣や心構えが紹介されている。アジャイルの入門書なんだろうけど、開発に携わっている人なら別にアジャイルでなくても、十分役に立つ内容だと思う。内容は短くまとまってるし、文章も硬くないので、読みやすかった。

私としては以下のプラクティスが印象的だった。
・批判するなら人ではなく、アイディアに
・作る前から使う
・時が来たら習慣を捨てる
・ソリューションログをつける
・シンプルにする

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

プログラマが意識していなくてはならないことが書いてある。
しかし、この手の本を読んでいる人には少し物足りないかもしれないが、再認識という意味でも有益な内容であった。
スタンドアップミーティングに関しての記述は面白いし、実際に一昨年は行っていたが、効率的にミーティングを行う事を考えていた当時を思い出した。

Clean Agile 基本に立ち戻れ

アジャイルのポエム。
本じゃなくても、Qiitaとかで読めれば良さそうな内容。
XPのプラクティスが重要。
デイリースクラムは、必須じゃないとか。
ペアプログラミングも常時やらなくても良いとか。
クラフトマンシップ、職人宣言とか。
Scrumで最初はガチガチの型に嵌めてやれとは少し趣が違った見解。

アジャイルサムライ――達人開発者への道

アジャイル開発のテキストとしては有名な本だったので、読んでみました。

内容はアジャイル開発とは何ぞやから始まって、プロジェクト発足からリリースまでにどのようなことを行うのか、その際の注意点などがみっちりと書かれています。

ただ、海外の技術書によくある回りくどい表現がとても多く、内容を理解するにはそこから要点を見出して頭の中で情報を整理する必要があります。個人的にはこの作業にとても疲労感を覚えるため、本書を読解するのにとても苦労しました。

オライリー本を抵抗なく読める人であれば重宝すると思いますが、私みたいにちょっと苦手という方は誰かが要点をまとめたサマリーを探す方が良いかも、なんて思いました。

リーン開発の現場 カンバンによる大規模プロジェクトの運営

かんばんの話が多かった印象。
短くて読みやすいけど、リーンについて本当に知りたかったらトヨタ生産方式を知る必要がある？

アジャイルサムライ――達人開発者への道

「サムライ」というタイトルだが、訳書。
なので、洋書独特の言い回しや、アイスブレイクの仕方は好みが分かれるところ。
（マスターセンセイと弟子のくだりとか）
内容はアジャイル開発を始めるために必要な情報が網羅されていて、入門書としてオススメの一冊。

アジャイルサムライ――達人開発者への道

分量が多く斜め読みした。

アジャイル開発に携わっていた時に良んでおくべきだった。
アジャイル開発のフレームワークについてはこれを読んでおけばいいかなという印象。
やり方どうこう以前にもっと量書かないといけないなと自覚した。

アジャイルで躓いた時に再度読み直そうかな。
一冊家に置いておけばいい一冊

Clean Agile 基本に立ち戻れ

アジャイルに対してどういう思いで議論され、生み出されたのかを感じるできる本です
スクラムなどの実践的な手法の説明ではないので、そういう事を求めてる人には合わないと思います
一方で全体としてアジャイルとは何かを考えたい人には合う本ではないですしょうか

アジャイルサムライ――達人開発者への道

顧客とプロジェクトの状況を正直に包み隠さずに共有出来ることが、ベースとしての大事な考えだと感じた。
ただ、上記はこれまで経験してきたプロジェクトや契約の習慣とは大きく異なっていて、それがアジャイルをイマイチ有効活用できてない原因なのかもと。
もう一度本書を元にチームで原点に立ち返ってみようかと思う。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

いくつかアジャイル本を読んでいるので内容は既知で、重なる部分が多かった。それでも、いくつかは意識してないプラクティスがありメモしました。

メモしたいプラクティス
・設計は指針であって、指図ではない。
　設計は実装を始められるだけ詳細であればいい
・受け入れテストを自動化する
　受け入れ評価する担当がSeleniumかければよいのかなぁ
・アーキテクトもコードを書くべき
　PowerPointでコードはかけない
・答えを見つけられるように力を貸す
　メンターになってチームを育てる。
　いじめっ子(Tormentor)にならないように。