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

  • オーム社
4.25
  • (24)
  • (12)
  • (12)
  • (0)
  • (0)
本棚登録 : 331
感想 : 20
本ページはアフィリエイトプログラムによる収益を得ています
  • Amazon.co.jp ・電子書籍 (454ページ)

感想・レビュー・書評

並び替え
表示形式
表示件数
絞り込み
  • 改めてアジャイルについて学ぶ必要があったため再読。
    とても読みやすくかつアジャイルの基本的な考え方が網羅されていて非常に良い!
    名著です☺️

  • 読みやすかった

  • アジャイル開発の最高の解説書です!

  • インセプションデッキやプランニングポーカーなど、なんとなくやっていたプラクティスの詳細について知ることができます。

  • 怠惰な自分が途中でしばらく読むのをやめていたせいで(YouTubeにかまけていた)、読了まで時間を要してしまった。
    内容は文句なし。
    アジャイルという概念、そしてその裏にある「思い」が、面白おかしく学べる一冊。
    本書の内容を常に頭に置いた上で、実務に必要なところだけ応用できるようになりたい。
    それが一番難しいけど。。。

  • ・P20: 2.2 チームをアジャイルにするためのコツ
    同じ仕事場で働く
    積極的に深くかかわる顧客の存在
    自己組織化
    成果責任と権限委譲
    職能横断型チーム

    ・P63: 4.4 やらないことリストを作る
    うまくやるには

    ・P66: 4.5 「ご近所さん」を探せ
    大規模プロジェクトでやらかした大失敗
    進め方
    次章予告

    ・P80: 5.3 期間を見極める
    小さく考える
    プロジェクトの長さへの期待をマネジメントする

    ・P84: 5.4 何を諦めるのかをはっきりさせる
    試験
    荒ぶる四天王
    トレードオフ・スライダー
    期日と予算を守るだけでは十分ではないのだ

    プロジェクトには、守らなければならない決まりや、無視できない影響力を及ぼす力(フォース)が存在している。例えば、予算と期日は厳守すべきとされる傾向が強く、スコープは見境なく気ままに広がり続けていきがちだ。そしてもちろん、品質は常に最優先事項だ。
    こうしたフォースのそれぞれは対立する事も多い。どれか一つのフォースに圧倒されると、残りのフォースに手が回らなくなる。フォースのバランスが欠けた状態が続くと、プロジェクトへの負荷がどんどん高くなっていく。最終的には、それが原因となってプロジェクトは完全に空中分解することになるだろう。
    だから何かを諦めなきゃならない。問題は、何かを諦めるかだ。

    荒ぶる四天王
    太古の昔より、あらゆるプロジェクトは4つの固く結びついたフォースによって統治されている。それが荒ぶる四天王、すなわち時間、予算、品質そしてスコープだ。どんなプロジェクトにもこれらが待ち受けており、いつも必ず破壊と混乱を起こす。すなわち、
    スケジュールは圧縮される
    予算は削減される
    バグのリストは長くなる
    やるべきことは際限なく沸き出てくる

    荒ぶる四天王のパワーは圧倒的だ。しかしこれらを手懐けることも出来る。その為には、プロジェクトにおいて四天王の一人一人と調和を保ちながらうまく付き合っていく方法を学ばなければならない。

    時間、予算、品質。アジャイルサムライはこの三者のいずれをも固定する。するとたった一つだけ、動かすことのできるフォースが残る。それがスコープだ。
    やるべきことが多すぎるとき、アジャイルサムライはどうするか?やることを減らすのだ。計画が現実にそぐわなくなっているのであれば、アジャイルサムライは計画を変える。現実を変えようとしてはいけない。
    期日を動かすことは無理かもしれない。だからといって、計画も動かせないとは限らない。

    トレード・オフ・スライダー
    アジャイルサムライたるもの、時間、予算、品質について、顧客がどう考えているかをきちんと把握しておきたいものだ。スコープを柔軟にしておくことの重要性についても、ある程度はあらかじめ顧客に納得しておいてもらいたい。
    これを実現する為には、プロジェクトのToDoリスト(マスターストーリーリスト)に載っているフィーチャ(ユーザストーリー)だけに囚われすぎないように気を付ける必要がある。

    スコープは諦めてもらう場合があることに納得して貰うのだ

    こうやって四天王たちにラベルをつけて、一目見ればすぐわかるようにしておくのだ。こうしておけば、相対的な重要度の順にツマミを調整することを顧客に頼めるはずだ(これなら、「どれも最優先」にはできない)。

    「どれも最優先」はまかりならない!
    同じ目盛りの項目があってはいけない!

    ・P150: 8.2 アジャイルな計画づくり

    ・P154: 8.4 初回の計画づくり
    ステップ1:マスターストーリーリストを作る
    ステップ2:プロジェクト規模を見極める
    ステップ3:優先順位をつける
    ステップ4:チームのベロシティを見積もる
    ステップ5:期日を仮決めする

    ・P165: 8.5 バーンダウンチャート
    バーンアップチャート

    ・P198: 9.7 カンバン
    次章予告

    ・P213: 10.6 デイリースタンドアップ

    ・P226: 11.3 チームの意思を明確にする
    「チームの約束(Working Agreements)」はチームとしてまとめる為の取り決めであり、「私たちはチームとしてこうやって作業したい」という宣言を文字にしたものだ。これは、現在のチームメンバーにとってはどんなチームを目指しているかを言葉で表すことになるし、これからチームに参加するメンバーにとってはチームメンバーとして求められる条件を明示するツールになる。

    もうひとつは「チームが大事にすること(Shared Values)」だ。趣旨はチームの約束と同じだが、もっと感覚的な表現になる。もしも過去にプロジェクトが炎上した経験があって、品質を危うくするような窮地にはもう追い込まれたくないとか、手を抜いたグダグダなコードは二度と書きたくない、といった思いがチームにあるのなら、それを「チームが大事にすること」として目に見えるかたちにしておくとよい。

    ex)チームの約束
    午前9時から午後4時までがコアタイム
    デイリースタンドアップは午前10時丁度に開始
    テストを済ませたら完了
    ビルドをだいじに
    誰かに助けを求められたら「はい、よろこんで」と返事しよう
    毎週火曜日午前11時からデモをする
    午後1時から3時まではお客さんが時間を割いてくれる

    ex)チームが大事にすること
    手を抜かない
    「割れ窓」を放置しない
    異論は認める
    真実と向き合う
    勝手な想定をしないで確認する
    疑わしいと思ったらテストを書く
    フィードバックを求める
    我を張らない

  • ■読んだ動機
    社内であるプロジェクトの開発が期限ギリギリになって、コードの品質やコードレビュ、テストが普段より疎かになった、と言う話が出て、そのいい解決策はないかと思い、読み始めた。

    ■感想
    時間、予算、品質、スコープの4つはいずれも大切だが、全てを最優先にはできない、変更可能になるのは、スコープだけ、と言う話が出てきて、参考になった。

    また以下3点は、特に印象に残った言葉だった。
    『アジャイルサムライは計画を変える。現実を変えようとしてはならない。』

    『見積もりは、絶対的ではなく、相対的に見積もる方が、正確に見積もれる。』

    『ユニットテストの肝はテストの網羅性ではない。チームが自分たちのコードに自信を持てるようになることだ。』

    そのほか気になった箇所のまとめは以下に。


    ■以下気になった箇所

    もしお客さんから「じゃあリリースしてください」と言われたら、すぐにリリースできるように備えておくということなんだ。 もしも君の作業がそうなってない、つまり蓋を開けてみるまでリリース可能かどうかわからないんだとしたら、その作業は「完了」じゃない。そんなことにならないように、私たちはアジャイル開発者として、このアジャイル開発の原則を受け入れねばならない。


    ここは大事なところなので、まとめておく。アジャイルチームに見られる光景の特徴は次の3 つだ。
    - きっちりと区別しない役割分担。
    - 継続的な開発工程
    - チームで成果責任を果たそうとすること



    太古の昔より、あらゆるプロジェクトは4 つの固く結びついたフォースによって統治されておる。それが荒ぶる四天王、すなわち時間、予算、品質そしてスコープだ。 どんなプロジェクトにも奴らが待ち受けており、いつも必ず破壊と混乱を引き起こすのだ。



    そのためには、プロジェクトにおいて四天王の一人一人と調和を保ちながらうまく付き合っていく方法を学ばねばならない。



    時間、予算、品質。アジャイルサムライはこの三者のいずれをも固定する。するとたった1 つだけ、動かすことのできるフォースが残る。それがスコープだ。 やるべきことが多すぎるとき、アジャイルサムライはどうするか? やることを減らすのだ。計画が現実にそぐわなくなっているのであれば、アジャイルサムライは計画を変える。現実を変えようとしてはならない。



    「……ソフトウェア開発は『要件』という用語によって誤った方向に導かれてきた。辞書を引けば『要件』には『必要条件』とか『必須のもの』という意味が載っている。『要件』という用語は言外に絶対不変であるとか、変化を受け入れることを食い止めるといった意味合いも伝えている。つまり『要件』という用語はあきらかに間違っている。 分厚い要件定義書に記述されている要件のうちの5% か 10%、あるいは 20% 程度の機能を顧客に届けてみれば、実はそれがシステム全体で想定していたビジネス上の利益のほとんどを提供していることに気づくことになるだろう。では、残りの 80% は一体何なのだろうか? これらは『要件』とは呼べない———なぜなら必要条件でもなければ必須のものでもないからだ。

    よく書けているユーザーストーリーの特徴の1 つ目は、顧客にとって何かしらの価値が書かれていることだ。「価値がある」とはどういうことか? 君のお客さんが対価を払ってもいいと思えるものが価値だ。



    よく書けているユーザーストーリーの2 つ目の特徴は、エンドツーエンドになっているということだ。エンドツーエンドというのは、わかりやすく言うなら、ユーザーストーリーの切り口が「ケーキを切る」ようにスライスされているってこと。



    ちょっと立ち止まって、現実の見積りプロセスについて考えてみよう。アジャイル界に社交辞令は無用だ。アジャイル手法が私たちに突きつける事実は、プロジェクトで最初に出す初期見積りは実に———そう、実にひどい当てずっぽうに過ぎないってことなんだ。 これを踏まえてアジャイルな見積り手法を学べば、精度や精密さという意味では何も得るものがない事前見積りに頼ることはなくなるだろう。そんなことよりも、本当に大事なこと、すなわち君と君のお客さんが一緒になって信じられる計画を立てることに気持ちを集中させるようになるはず。



    研究調査によると、人間は相対見積りならうまくこなせるらしい。たとえば、目の前に岩が転がっていたとしよう。このとき、片方の岩がもう片方の岩に対してどれぐらい大きいかは、非常に正確に見積もれるそうだ。



    チーム全員が定期的に集まって、すごくうまくいったことや、もっとうまくやるためにどうすればいいかを話し合うんだ。 有意義なふりかえりにするために一番大切なルールは、みんなが安心できる雰囲気を作ることだ。もしそこに問題があるようなら「ふりかえり最重要条項」の 出番だ。これができなきゃ始まらないってことを肝に銘じておこう。



    ユニットテストの肝はテストの網羅性ではない。チームが自分たちのコードに自信を持てるようになることだ。ソフトウェアがきちんと動作しており、リリースできるプロダクトとして準備が整っていると確信を持てることこそが大事なのだ。



    プロジェクトマネージャがリファクタリングの重要性を理解しておくことはとても大切だ。もしチームが、緊急のバグ修正や、システムに大きな影響をおよぼす変更を加えねばならないときに、きちんと、早く、低コストに対応できたとしたら、それはこれまでのリファクタリングの成果だからだ。



    私たちは、ソフトウェア開発の実践あるいは実践を手助けする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値と。

  • "お客様に価値を提供し続ける"のは口で言うほど簡単なことではないと思う。だかこそ、そのためにどうすべきか、どう考えるべきか、を追求し続けることこそが"アジャイル開発"なのではないかと感じた。

  • これは何回も読み返したい数少ないビジネス書(まあ技術書のジャンルに入るんだろうけど)になりそう。
    根本的な考え方から進め方、それを改善していくことも含めてわかりやすい言葉で書かれている。

    特にインセプションデッキ、プロダクトオーナーの話が刺さった。この手のことって概念としては知っていても、その重さを共有できていることが少ないから失敗するんじゃないかと思う。

  • ■関連サイト:https://pragprog.com/titles/jtrap/the-agile-samurai/

    ●ソフトウェア開発の3つの真実
    ・プロジェクトの開始時点に全ての要求を集めることはできない
    ・集めたところで、要求はどれも必ずといっていいほど変わる
    ・やるべきことはいつでも、与えられた時間と資金よりも多い
    ●ソフトウェアの64%の機能は、ほとんどあるいは全く使われていない。
    --->このことからも、本当に重要なことだけに集中すべき
    ●アジャイル開発の原則として、ビジネス側の人と開発者は、プロジェクトを通じて日々一緒に働かなければいけない

    ■プロジェクト運営

    ●インプレッションデッキでの10の質問
    ①我々はなぜここにいるのか
     顧客は誰で、このプロジェクトが始まった目的は何なのか?
    ②エレベーターピッチを作成する
     2センテンスでプロジェクトをアピールするとしたら何?
    ③パッケージデザインを作成する
     何気なくめくった雑誌に自分のプロダクトの広告を入れるならどんな内容?
    ④やらないことリストを作る
    ⑤「ご近所さん」を探せ
     プロジェクトの関係者範囲は自分たちの想定以上に広いもの。積極的に情報を
     shareしFB機会を得る。
    ⑥解決案をかく
     チーム全体の認識が揃っているかを確認するために、概念レベルのアーキテクチャ
     設計図を書く。
    ⑦夜も眠れなくなるような問題は何か
     プロジェクトが暗礁に乗り上げるとしたらどんなリスクか?目を背けず話し合う。
    ⑧期間を見極める
     1ヶ月なのか半年なのか1年なのか?
    ⑨トレードオフスライダー(何を諦めるのか)
     期間、スコープ、予算、品質。譲れないものは何で変動しうるのは何?
     --->スコープ以外は基本的に固定。
    ⑩何がどれだけ必要か
    必要なリソース(期間、人員、コストなど)

    ●良いユーザーストーリーの6つの要素:INVEST
     ✓独立している(Independent):ストーリーが互いに独立していると、必要に
      応じてスコープを柔軟に調整しやすい
     ✓交渉の余地がある(Negotiable):予算などに応じて実現方法を選択できる
     ✓価値がある(Valuable):顧客が対価を払っていいと思えるもの
     ✓見積もれる(Estimatable)
     ✓小さい(Small):1週間や2週間といったイテレーションに収まるようにする
     ✓テストできる(Testable):完了の基準が明確になる

    ●ユーザーストーリーのテンプレート
    〈ユーザーの種類〉として、〈達成したいゴール〉をしたい。なぜなら〈理由〉だあから。テンプレートを使うことで誰が/何を/なぜ、という重要な疑問を明確にできる

    ●ベロシティはチームとしての生産性を計測する。個人の生産性を測るのは良くない。個人の生産性を測ると、協調しようとか知見を共有しようという気持ちがなくなり、各人が何としても自分自身の生産性を確保しようと躍起になってしまう
    プロジェクトの完了時期の見通しを立てるにはバーンダウンチャートが便利。ただ、バーンダウンチャートだと途中でのストーリー追加がわかりづらいので、途中でのストーリー追加をわかりやすくしたければバーンアップチャートが便利

    ●リスクは経過時間(プロジェクトサイズ)に比例する=小さく区切って考える

    ●継続的インテグレーション:ソースコードリポジトリ(単一のコードベース)に対して機能追加・性能改善・バグの修正・ライブラリの新バージョンなどを順次追加

全20件中 1 - 10件を表示

西村直人の作品

この本を読んでいる人は、こんな本も本棚に登録しています。

有効な左矢印 無効な左矢印
ロバート キヨサ...
マイケル・C・フ...
ジェームス W....
ヴォーン・ヴァー...
岸見 一郎
エリック・リース
有効な右矢印 無効な右矢印
  • 話題の本に出会えて、蔵書管理を手軽にできる!ブクログのアプリ AppStoreからダウンロード GooglePlayで手に入れよう
ツイートする
×