投資家たぬきちのブログ

株式メインの兼業投資家。学生時代から株式投資を始め、ビットコインをはじめとする仮想通貨投資で数千万稼ぐ。趣味はサーフィンとスノボとお酒。

一気に要約アジャイルサムライ!- 達人プログラマになろう!

アジャイルサムライ−達人開発者への道−は、アジャイル開発に関する書籍の中で、いろいろな面で群を抜く書籍である。

そんなアジャイルサムライを一気に要約してみたので共有したい。

価値ある成果を毎週届けるために

1大きな問題は小さくする
2本当に大事なことに集中して、それ以外のことは忘れる
3ちゃんと動くソフトウェアを届ける
4フィードバックを求める
5必要とあらば進路を変える
6成果責任を果たす

アジャイル開発の原則

・顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供する
・動くソフトウェアこそが進捗の最も重要な尺度
・顧客と日々一緒に働く
・最良のアーキテクチャ・要求・設計は自己組織的なチームから生み出される
・意欲に満ちた人々を集めて構成。環境と支援を与え、仕事が完了するまで彼らを信頼する。
・情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすること。
・要求の変更はたとえ開発の後期であっても歓迎する。変化を味方につけることによって、お客様の競争力を引き上げます。
・シンプルさが本質です。(機能の20%が80%の価値を生み出す)
・チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整する
・技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます

アジャイルな計画づくりが上手く良く理由

・マスターストーリーリスト(プロジェクトのToDoリスト。顧客が実現したい機能(ユーザーストーリー)のリスト)
・ベロシティ(1回のイテレーションで完了させられるストーリーの量)を測る
・スコープを柔軟にしておく

ソフトウェア開発の3つの真実

・プロジェクトの開始時点に、すべての要求を集めることはできない
・集めたところで、要求はどれも必ずといっていいほど変わる
・やるべきことはいつだって、与えられた時間と資金よりも多い

チームをアジャイルにするためのコツ

・同じ仕事場で働く
・積極的に深くかかわる顧客の存在
・自己組織化
・成果責任と権限移譲
・職能横断型チーム

ドラッカー風エクササイズ(プロジェクト開始時点で行う)

・自分は何が得意なのか?
・自分はどうやって貢献するつもりか?
・自分が大切に思う価値観は何か?
・チームメンバーは自分にどんな成果を期待してると思うか?

チームメンバーを探すコツ

・ゼネラリスト
・曖昧な状況に抵抗がない人
・我をはらないチームプレイヤー

プロジェクト開始の注意点

・手強い質問をする
 インセプションデッキ
 1我々はなぜここにいるのか?
 230秒以内にプロジェクトのアピールができるか?(エレベーターピッチ)
 3パッケージデザインを作る
 4やらないことリストを作る(やる、やらない、あとでやる)
 5プロジェクトの関係者を探す
 6解決案を描く(概要レベルのアーキテクチャ設計図)
 7夜も眠れなくなるような問題は何か?
 8期間を見極める
 9何を諦めるのかをはっきりさせる
 10何がどれだけ必要なのか(期間と費用)

・エレベーターピッチのテンプレート
 ・[潜在的なニーズを満たしたり]したい
 ・[対象顧客]向けの
 ・[プロダクト名]というプロダクトは
 ・[プロダクトの具体]ある。
 ・これは[重要な利点、対価に見合う説得力のある理由]ができ、
 ・[代替手段の最右翼]とは違って、
 ・[差別化の決定的な特徴]が備わっている。
 例
 建設現場の作業を把握したい
 現場責任者向けの
 CSWPというプロダクトは
 危険作業許可証発行システムである
 これは作業許可証を申請・追跡・監査することができ
 現行の紙ベースのシステムとは違って、
 ウェブ経由で、いつでもどこからでも利用できる機能が備わっている

・トレードオフスライダー
 時間、予算、品質、スコープ
 変えるべきはスコープ

よく書けているユーザーストーリー INVEST

 Independent 独立している
 Negotiable  交渉の余地がある
 Valuable   価値のある(技術よりではなくメリットを明確に)
 Estimatable  見積もれる(短い期間なら精度が上がる)
 Small    小さい
 Testable   テストできる

ユーザーストーリーのテンプレート

 <ユーザーの種類>として
 <達成したいゴール>をしたい
 なぜなら<理由>だからだ
 (誰のためのストーリーで、何をしたいのか、なぜそうしたいのか)

見積り

・条件
 今後の予定を立てられる
 見積りは当てずっぽうだという前提を踏まえている
 ソフトウェア開発の複雑さを認めている
・ストーリーそれぞれを互いに相対的なサイズで見積もる
・数値の単位をポイントにし、それをもとにして進捗を追跡する

アジャイルな計画づくり

・アジャイルな計画づくりとは、チームの開発速度を計測して、その速度をもとに完了時期を見通せるようにする
・4つの基準
 1顧客にとって価値ある成果を届けられる計画
 2わかりやすくありのままを伝える、誠実な計画
 3約束したことを守り続けられる計画
 4必要に応じて変更できる計画
・イテレーション数=作業量の合計/チームの予想ベロシティ
・ステップ
 1マスターストーリーリストを作る
 2プロジェクト規模を見極める
 3優先順位をつける
 4チームのベロシティを見積もる
 5期日を仮決めする
・バーンダウンチャート
 縦軸:残っている作業量
 横軸:イテレーション
 次の4つが明確になる
 ・どれだけ仕事を完了させたのか
 ・どれだけ仕事が残っているのか
 ・チームのベロシティ
 ・いつ頃すべてを完了させられそうか

アジャイルなプロジェクト運営

3のステップ
 1分析して設計する(作業の段取りをする)
  ・ジャストインタイムの分析「必要な分だけを、必要なときに」
  ・まずはフローチャートを作る
  ・ペルソナをつくる(ユーザーがどんな人で、どんなことをしようとするのか)
  ・ペーパープロトタイプをどんどん作る
  ・受入れテストを書いて、ストーリーの満足条件を定義
 2開発する(実際に作業する)
  ・自動化されたテストを書く。
  ・設計を継続的に発展させていき、改善し続ける。
  ・ちゃんと動くソフトウェアであり続けるために、コードを継続的にインテグレーションする
  ・顧客がシステムについて語る言葉にあわせてコードを書く。
  イテレーション・ゼロ(ソースコード管理、ビルドの自動化、開発環境やテスト環境、おまけ)
 3テストする(作業の結果を確認する)

イテレーションで行うこと

1今回のイテレーションの作業に備える
2今回のイテレーションのフィードバックを得る
3次回のイテレーション計画をたてる
4次回のイテレーションで改善できる余地を探す

デイリースタンドアップ

・昨日、世界をどう変えたか
・今日、世界をどう変えるか
・どんな難問が行く手を阻んでいるか

アジャイルなプログラミング

 問答無用で実施すべきプラクティス
 ・ユニットテスト
 ・リファクタリング
 ・テスト駆動開発(TDD)
 ・継続的インテグレーション

テストコードを書く利点

・素早いフィードバックが得られる
・極めて低コストにリグレッションテストを実行できる
・デバック時間を大幅に削減できる
・自身をもってデプロイできる

バグを修正する前に、失敗するテストを書く

・バグの本質を理解したことを示せる
・自信をもってバグを修正したといえる
・君のプログラムに同じバグが二度と現れないことを保証できる

テスト駆動開発

1レッド:失敗するユニットテストを書く
2グリーン:テストに成功するコードを書く
3リファクタリング:実装を見直し、明瞭でわかりやすいコードにする

要約というより、要点の箇条書き?

面白く、一気に読めちゃってイメージに残る良書なので、気になる方はポチることをおすすめします。

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

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

  • 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未
  • 出版社/メーカー: オーム社
  • 発売日: 2011/07/16
  • メディア: 単行本(ソフトカバー)
  • 購入: 42人 クリック: 1,991回
  • この商品を含むブログ (257件) を見る


ほらあなより愛をこめて
たぬきち

※免責事項:投資は自己責任でお願いします。当ブログはあくまで個人的見解を述べているだけであり、当ブログを元にした投資による損失等の責任は、当ブログは一切負いません。