無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中！
無料マンガ・ラノベなど、豊富なラインナップで200万冊以上配信中！
※アプリの閲覧環境は最新バージョンのものです。
Posted by ブクログ
感想として一番思ったことは，丁寧に書かれた本だなぁということです．アジャイルなソフトウェア開発の初学者向けの導入を構成しながら，中盤から後半にかけて多くのノウハウを披露している点は，初学者だけでなく実際にアジャイルな開発をおこなっている人々も多くのことを学べると思います．
また，「アジャイルを現場に定着させよう」のように，特定技法ではなく考え方を，開発現場で展開・定着させることにフォーカスを当てて話を述べているのは，他ではあまりなく，珍しく貴重ではないかと思います．
展開・定着に向けたワークショップも8つが具体的な方法まで紹介されており，素振りなどをやっていこうと思います．
ということで，この本は，アジャイルなソフトウェア開発の初学者および開発現場で展開・定着を考えている人におすすめしたいと思います．
Posted by ブクログ
その名の通り、アジャイル開発の教科書である。著者の方々は実際に、アジャイル開発を行っており、そのノウハウについても記載されており、非常に参考になる。
私自身は、プログラマからマネージャーへの移行中という状況で、かつ、いわゆるウォーターフォールしかやった事がなかったため、とても新鮮に写った。
アジャイル開発は、ソフトウェア工学が否定してきたプロセスやツール重視の考えから、人間重視への方向転換、いわゆるルネサンス的な動きだと思う。結局、ソフトウェアが自動生成されない＝人間が関わる、ことからコミュニケーションを密にとり、フィードバックを密にすることで、人間を成長させていかないと、生産性も品質も上げにくいという、現実があると思う。PMPなども、その辺を考え、個人を高めるPSPなどの活動を行ってきたが、他人からのフィードバックプロセスが不十分であったのではないか？その辺りをアジャイル開発は、プロセス内に上手く取り込んでいる気がした。
また、人重視の考えから、ファシリテーションとの関連が、書かれていたことも興味深かった。そう言った意味でも、様々なヒントが載っているので、オススメです。
Posted by ブクログ
アジャイルは「考え方」「姿勢」であり、「手法」として捉えると失敗するということがよく分かった。かつては要求はほぼ決まっており仕様の変化もあまりなかったが、要求が曖昧であり仕様も大きく変化するのが現在のソフトウェア開発の状況である。また、ユーザの使用感も重要な要素であり、その手直しも非常に多い。そういう状況であるにもかかわらず、開発する側が変わらないというのはやはりおかしく、アジャイルという考え方を導入するのは理にかなっていると言える。とはいうものの「変化を嫌う」風土は根強く、特にマイコンではその傾向があるように思う。しかし、マイコンこそアジャイルを適用すべき領域であるように感じた。マイコンは一度製品として出荷されるとアップデートが困難であり、また実際に動作させてみないとどのような結果になるのかわからないという側面もある。そのため頻繁に仕様変更が発生するが、細かくタイムボックスを設定することで顧客、開発側双方で柔軟な対応ができるのではないかと思う。
本書はアジャイル開発の教科書名乗っているだけあり、プラクティスの解説も充実しているが、特に「テスト駆動」と「リファクタリング」の解説は非常に丁寧で充実している。これはアジャイル開発の根幹ともいえるプラクティスであると同時に誤解を招きやすいプラクティスでもあるからではないかと思う。誤解を招きやすいといえばドキュメント作成もその一つであり、それについても「何故作らないか」に加え、「どんなドキュメントを作るか」を取り上げている。
アジャイル開発は強力であるものの誤解も多い開発手法である。その誤解を解き、どのように導入すればよいのかを知る手がかりになる1冊である。
Posted by ブクログ
コンサルに行って返答に困る質問の一つに「うちの開発は今V字モデルです。あきやまさんはウォーターフォールの人と聞いていますが、そろそろうちの開発もアジャイルに移るべきでしょうか？」というのがあります。
ちょっと質問してみると、V字モデルではないことがすぐに分かるので、“ああ、アジャイルを導入したら魔法のようにコストが抑えられ、納期が短縮したうえで品質の高いソフトウェアが開発されると夢見ているんだな”と思います（心の中だけで口には出しません）。
ま、そんなことは、ないわけで、これまで経験したことを話します。
「開発者の技術力とモチベーションが大切です」とか「アジャイル憲章はいいですね」とかそういう話です。
さて、本書はアジャイル開発を実践されている人が平易に書いた本です。読みやすいし、グッとくる記述もおおいです。
でも、本ではなく講演で耳から聞いた方が良いと思いました。
Posted by ブクログ
引き続き、アジャイル開発のお勉強。改めて共感。
・ソフトウェアの価値を高めるには
１．変化を受け入れる
２．変化に対応する
３．人にフォーカスする
・アジャイルソフトウェア開発宣言
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
・いま必要なものだけを実装する
「YAGNI」とは「You Aren't Going to Need It.」の頭文字をとったものです。
直訳すれば「いま、いらないでしょ？という感じです。
・一定の固定された期間を「タイムボックス」とし、プロジェクトの基本リズムとする。
・タイムボックスでは毎回リリースを行い、動くソフトウェアを通してお客様と一緒に価値を確認する。
・「合意形成」よりも「承認」を目標にしてすり合わせていくと、どうしても対立構造や無駄な指摘も多くなってしまう傾向があり、手続きも煩雑化されてしまう可能性がある。このような煩雑さから、コミュニケーションロスが増えることになる。
・アジャイル開発では、なぜドキュメントをなるべく作りたくないのか？
その理由の一つは、ドキュメントの維持コストです。ドキュメントを作成すると、設計が変わるたびにドキュメントへの反映を行う必要が出てきます。アジャイル開発のような周期の短い反復開発では、ドキュメントを反復のたびに変更することは、開発のスピードを損なう原因になります。
※アプリの閲覧環境は最新バージョンのものです。
ビジネス・実用
