アジャイルサムライ の商品レビュー
「毎週、価値ある成果を届けられているか?」何度も繰り返されているが、アジャイルかどうかはこれに尽きると思う。 インセプションデッキ、イテレーションが〜のような難しそうなワードを聞くたびにアジャイルから避けて来てたが、これらはあくまで手段。チームによって必要なものを取り入れていけ...
「毎週、価値ある成果を届けられているか?」何度も繰り返されているが、アジャイルかどうかはこれに尽きると思う。 インセプションデッキ、イテレーションが〜のような難しそうなワードを聞くたびにアジャイルから避けて来てたが、これらはあくまで手段。チームによって必要なものを取り入れていけばいい。 開発者であれば12章〜の内容は基本スキル。 以下は引用 P22 これから2週間で課題を解決すると宣言。 P25 お客さんを目の前にしてデモをする。 P64 今回は気にしない。→今回がプロジェクトを指してるのか、スプリントなのか不明。 P68 助けを求めたくなる前から知り合いになっておくんだ。 P106 しかる時が来たら詳細を検討するが、それは本当に必要だと確信をもてるようになってからの話だ。 P191 ペルソナがいるとシステムに人間味を持たせることができる。 P214 デイリースタンドアップでの報告の仕方をこんなふうにしてみたら〜。 P216 ストーリは完了したか、してないか。そのどちらかだ。 P226 チームの意思を明確にする
Posted by
陽気な達人プログラマーに教えてもらった気分だった。 めっちゃいいです! いきなりページを開くと(厳密には数ページだけど) 1. 君は学ぶことが心から好きだ。 2. 君はソフトウェアのことを大切に思っている めちゃくちゃ歓迎ムードである笑 いろいろ面白い内容が盛り沢山だった...
陽気な達人プログラマーに教えてもらった気分だった。 めっちゃいいです! いきなりページを開くと(厳密には数ページだけど) 1. 君は学ぶことが心から好きだ。 2. 君はソフトウェアのことを大切に思っている めちゃくちゃ歓迎ムードである笑 いろいろ面白い内容が盛り沢山だったけど印象的なところだけ上げておく(なるべくソフトウェア開発以外にも通ずるような部分を、、、) 1. チームメンバーを探すコツ ・ゼネラリスト →なんでもそつなくこなせる人。器用貧乏⁈) ・曖昧な状況に抵抗がない人 →どっしりと構えてくれる、臨機応変 ・我をはらないチームプレイヤー →ありのままの姿で、調和できるように 2. エレベーターピッチ エレベーターで一緒に乗った友達に自分の仕事を30秒で説明してみよう 3. どのリスクには取り組む価値があって、そうじゃないのらどれなのかを決める →願わくばわたしに、変えることのできない物事を受け入れる落ち着きと、変えることのできる物事を変える勇気と、その違いを常に見分ける知恵とをさずけたまえ -ニーバーの祈り- 4. 計画の立て方 ・顧客にとって価値ある成果を届けられる計画 ・わかりやすく、ありのままを伝える、誠実な計画 ・約束したことを守り続けられる計画 ・必要に応じて変更できる計画 5. 本当に重要なものだけをまずは実装 ここまで読んでいただきありがとうございます。 でもアジャイルって一体なんやねん!と思った方は是非読んでみてください。 読んだその日からあなたも私もアジャイルです。
Posted by
アジャイル開発についての理念やら進め方について短くまとまっている。 手法そのものよりも「なぜ、何のためにやるのか」を説明しておりわかりやすい。
Posted by
質の高いソフトウェアを高速に届け続けるための開発手法、アジャイル。 変化が多く、スピーディなアウトプットが求められる環境ではめちゃくちゃぴったりな手法だと思う。
Posted by
アジャイル開発に興味があるなら一度読んでみると良いと思う。マネージャーや現役のエンジニアだけではなく、これから開発をやっていくような人にもオススメしたい。
Posted by
- ネタバレ
※このレビューにはネタバレを含みます
直近ではやっており実際に業務にも取り入れられ始めており、読了。思想としても実施方法としてもWFより良いことしかないにもかかわらず、これまで取り入れが遅かったのは、やはり個人の能力に帰結するような気がしている。 どうやっても自主的な発想やスキルセットがある程度ないと、ペアプログラミングなどの教育とセットでないと回らないところが出てくる。 ツールやIT技術の底上げやユーザ企業側の理解も進んだことで、ようやく日本でも可能にしてきたのと、そういった企業がWWで伸びているところから、アプローチ手法として取り入れざるを得ないのだろう。 プロジェクト制にピッタリなので、多様な雇用形態にもマッチする。まさに、今後の核となる手法だと想定される。 ネックは上にも書いたが、ベンダ側だけでは回らないこと。顧客の理解があってこその手法だということ。IT部門が外部に依存している日本では、なかなか手ごわいことは変わらないだろう とはいえ、システムだけでなく、通例の業務でも取り入れられる内容であることや、カンバンなど派生形態もあり、とにかく顧客に機能という単位でリリースを続ける、という継続的手法という理解をした
Posted by
# 読む前 3年半前にアジャイル開発を始めることになった時にアジャイル入門書として読んだ本。自身の役割が初めてプロダクトオーナーになったので違う目線で改めて読んでみる。 # 内容 アジャイルな方向づけ アジャイルな開発プロセス(計画・運営) アジャイルにやるためのプラクティス...
# 読む前 3年半前にアジャイル開発を始めることになった時にアジャイル入門書として読んだ本。自身の役割が初めてプロダクトオーナーになったので違う目線で改めて読んでみる。 # 内容 アジャイルな方向づけ アジャイルな開発プロセス(計画・運営) アジャイルにやるためのプラクティス アジャイルにやれてるかどうかを確認する問い ・継続的に価値ある成果をあげてるか? ・カイゼンを続けているか? # 所感 初めてこの本を手にした時、入門書と思って読んでいたけれど、改めて読み返してみると、具体的な手法が多く書かれているわけでもなく、アジャイル開発を経験していない人には少しとっつきにくいかもと思った。決まったルール、お作法があるわけではなく、原則(マインド?)に従いやり方はチームや環境に合わせていくというのがアジャイルの考え方だから仕方のないことなんだと思うけど。 アジャイル開発にしばらく慣れて、やり方、考え方が固定化してきちゃってるかなぁ、という時に立ち返るために読み返すのにも適していそうだと思った。 今回の改めての気づきというか意識しておきたいなと思ったのは「期間を見積もる」の章で触れられていた、プロジェクトそのものも長期になると不確実性やリスクが増すということ。(開発サイクル(イテレーション)としての「短く期間を区切る」という考え方だけでなくプロジェクトも短く。) もう1個の気づき(本書に対する気づき)、もともとPO側の視点で、が再読のきっかけだったけど、本書の中ではPOは「お客様」という表現でちょっと外の人の扱いだった。。。
Posted by
顧客とプロジェクトの状況を正直に包み隠さずに共有出来ることが、ベースとしての大事な考えだと感じた。 ただ、上記はこれまで経験してきたプロジェクトや契約の習慣とは大きく異なっていて、それがアジャイルをイマイチ有効活用できてない原因なのかもと。 もう一度本書を元にチームで原点に立ち返...
顧客とプロジェクトの状況を正直に包み隠さずに共有出来ることが、ベースとしての大事な考えだと感じた。 ただ、上記はこれまで経験してきたプロジェクトや契約の習慣とは大きく異なっていて、それがアジャイルをイマイチ有効活用できてない原因なのかもと。 もう一度本書を元にチームで原点に立ち返ってみようかと思う。
Posted by
2011年の出版。それでも色あせていない。インセプションデッキという考え方。相対サイズの見積、リファクタリング、テスト駆動開発、継続的インテグレーションといったアジャイルならではの手法。「イテレーション計画ミーティング」「ショーケース」「デイリースタンドアップ」「ミニふりかえり」...
2011年の出版。それでも色あせていない。インセプションデッキという考え方。相対サイズの見積、リファクタリング、テスト駆動開発、継続的インテグレーションといったアジャイルならではの手法。「イテレーション計画ミーティング」「ショーケース」「デイリースタンドアップ」「ミニふりかえり」というイテレーションの運営。アジャイルに必須の要素が詰まっている。お陰様でアジャイル検定レベル1に合格できた。実践に使えるかはこれから。
Posted by
アジャイル開発の概要を理解したいときに読む本。 事例を踏まえて学びたいときは、次に「アジャイルな見積りと計画づくり」を読むとよい。 アジャイル開発は、実態を可視化しづらいウェブアプリを前提としており、実態やプロトタイプを作る組み込みの世界にそのまま適用できなさそう。 特に、エン...
アジャイル開発の概要を理解したいときに読む本。 事例を踏まえて学びたいときは、次に「アジャイルな見積りと計画づくり」を読むとよい。 アジャイル開発は、実態を可視化しづらいウェブアプリを前提としており、実態やプロトタイプを作る組み込みの世界にそのまま適用できなさそう。 特に、エンドユーザが直接的に価値を感じ取れないデバイス系や、Tire2サプライヤの開発には適用が難しいと思った。 組み込みの世界に適用できないところ。 1.部分発注 2.途中からの機能ドロップ 3.ストーリベースの開発 ハードウェア上でソフトウェアが動くので、 どうしてもソフトウェア階層の下位から上位へ開発が進むので、エンドユーザへリリースできない。 組み込みの世界に適用できるところ。 1.インセプションデッキでプロジェクトの外観を知る 2.TDD 検証基準で顧客と合意しておく。
Posted by