アジャイル開発の勉強メモ
Agile勉強メモ。
アジャイルソフトウェア開発の１２の原則
http://agilemanifesto.org/principles.html
1.顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2.要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによってお客様の競争力を引き上げます。
3.動くソフトウェアを２～３週間から２～３ヶ月というできるだけ短い時間間隔でリリースします。
4.ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かれなければなりません。
5.意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6.情報を伝える最も効率的で効果的な方法はF2Fで話をすることです。
7.動くソフトウェアこそが進捗の最も重要な尺度です。
8.アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
9.技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10.シンプルさ（ムダなく作れる量を最大限にすること）が本質です
11.最良のアーキテクチャ・要求・設計は自己組織的なチームから生みだれます。
12.チームがもっと効率を高めることできるを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します
この２つの問いへの答えが「YES」なら君はアジャイルだ
Question.1 毎週、価値ある成果を届けられているか？
Question.2 たゆまぬ改善のための努力を惜しまず続けているか？
アジャイル開発手法の起源
１９９０年代のプロセス重視の管理手法のアンチテーゼとして考えだされたソフトウェア開発手法。理論的背景としては、人間の相互作用を重視する、暗黙知を重視する、創発の作用を利用する、などといった人の共同の営みに関心を集める考え方に立脚している。
変化を受け入れるアジャイル開発手法
アジャイル開発手法においては顧客の本当に欲しいものは、事前の計画では分からないという状況を想定している。
変化にも様々な原因があるが、何でも受け入れるのではなく「顧客の本当のニーズに近づくための変化」以外の不確実性（仕様の取り違え、知識不足・経験不足に起因する誤差、開発者の作業効率見積もりの誤差など）は排除することを目指す。
仕様の変更はよりソフトウェアの価値を高めるものとして積極的に実施すべきものと考える。
探索型のプロジェクトに適用可能
１：仕様の変更を吸収して、品質を確保する仕組み（品質面での優位性）
＞テストで品質を確保する。人手による検査を充実させる以外に、自動化テストを初期段階から導入する（テストファーストなど）
＞コードの共同所有のプラクティスにより誰か特定個人がコードを抱え込むがなくなり、チームとしてコードの品質を管理できるようになる
２：創発の仕組みによる創造的ソフトウェア開発の実現（機能面での優位性）
３：必要な機能だけの早期リリースを可能にする段階的リリースの仕組み（期間面での優位性）
事前にアーキテクチャ設計をきちんと行うべき。
従来開発との違いは、必要最低限のコンパクトなアーキテクチャを設計し、ソフトウェアの設計と共にアーキテクチャを成長させる、進化するアーキテクチャの考え方を取り入れる点。
イテレーション～タイムボックス～
時間を区切って終了時間を厳守する方法がある。つまり、終了時間に必ず成果物が出せるようにする。成果物の完成度自体は中途半端であったとしても時間内で出てきた成果物を「是」として次の工程に進む方法。このような方法をタイムボックスと呼ぶ。
最初の検討（スプリント）で納得のいく成果物を出そうとしないことがポイントです
その他メモ
- 開発チームの自律性はアジャイル開発の根幹です
- 自己組織的なチームを創る魔法は「成果責任」と「権限委譲」
- ４つの質問をチームで共有してはどうだろうか？
（１） 自分は何が得意なのか？
（２） 自分はどうやって貢献するつもりか？
（３） 自分が大切に思う価値は何か？
（４） チームメンバは自分にどんな成果を期待していると思うか？
第４３回すくすくスクラム東京に参加してきた
http://sukusuku-scrum.doorkeeper.jp/events/6993
内容としては、スクラムをあまり知らなかったり経験が少ない人とある程度の経験がある人がチームになって、"知識"を共有していくことにより、知らない人は勉強になり、知っている人は知識の整理だったりができることを目的としてワークショップでした。
僕はとりあえず「知っている側」での参加でした。
よくあがってきた疑問と自分なりの回答をまとめてみました。
(整った環境でスクラムしていると忘れがちな基本的なことが多く、勉強になりました）
[Question.01]
プロダクトオーナーは誰がやるべきか？発注元にお願いできる？そんなことは可能なの？
Answer
発注元も巻きこむのが可能ならすべきだし、無理そうならチーム内にプロダクトオーナーを窓口としておいて始めるといい。
[Question.02]
突発的な仕事（バグや運用系の仕事）はどうスプリント内でさばくべきか？
Answer
あらかじめ突発的な仕事をする時間を確保しておく か そもそもカンバンで進める
[Question.03]
スプリントの長さは１週間ではダメなのか？（教科書的には２～４週間）
Answer
ダメじゃない。とくにスクラム導入したばかりは短いほうがいい場合もある。（はじめのほうは、軌道修正が頻繁に必要になるので
[Question.04]
乗り気じゃないメンバーはどうすればいいか？
Answer
スクラムやろうぜ！で進めると、そういうメンバーは特についてこれないと思います。だから、まずはそれぞれのメンバーから現状の問題点や不満やもっとこうしたいみたいな意見を個別でもいいので聞きだすといいなと思います。それらの問題などの解決策としてスクラムのやり方が通じそうであれば、そこを糸口に「スクラム」という言葉は使わずに改善していけばいいと思います。
（不満がもしないなら・・・。わざわざスクラムを始める必要はないのでは？）
[Question.05]
結局、どうやってスクラム導入するのが正解なの？
Answer
正解はない。ケースバイケース。
リーン開発の現場 カンバンによる大規模プロジェクトの運営
読みました。実例に沿って、学べる良書。
- 作者: Henrik Kniberg,角谷信太郎,市谷聡啓,藤原大
- 出版社/メーカー: オーム社
- 発売日: 2013/10/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
以下、個人的なメモ。
★頻繁なリリースの重要性
ある程度のコストはかかるが、リリースしてこそニーズとマッチしていたのかどうか、気がつくことができる。リリースの間隔があくほどバグや思い込みが埋め込まれる機会も増える。小さく頻繁を繰り返すのがいい
★カンバンを進める上でのポイント
キューの数を制限するのが大切。次のプロセスへの負荷的な意味でも重要（いっきに、前のプロセスから仕事がやってきたら、たぶん回らない）
WIP(Work in Progress：作業中）のタスクの数を制限するためには、ときどきいつもと違う作業をメンバーにはやってもらう必要がでてくる。例えば、新しい機能を開発する代わりに、テストしてもらうとか。この部分がもしかしたら現場との意識の差がでるかもしれない。でも、カンバンはチームのものだから、そういう意識を根付かせるための良い機会にもなるかもしれない。
★プロセスメトリクス
・ベロシティ一週間に開発した機能の数
・サイクルタイム1機能の開発にかかった週
ストーリーポイントじゃなくて機能の数をつかうのは、実際はそのストーリーポイントには50%程度の見積もり誤差があったりしたため、うまく使えない場合もあるから。この点に関しては、チームやプロジェクトによりケースバイケースかも。
・累積フロー図
・プロセスサイクル効率=作業日数/経過日数
はじめてのペアプログラミング、すすめかた
今の現場でペアプログラミングを導入しています。
スムーズに実施するため、はじめて実施するときの手順表をつくりました。
主に以下のページを参考にさせていただき作成しました。
Flow 「はじめてのペラプログラミング」
0. 役割の確認
| Role | What to do |
|---|---|
| Driver | キーボードを叩く人 |
| Navigator | driverの書くコードを眺め、エラーや設計を吟味する |
1.作業を決める
- 規定した時間内に終わりそうな明確なゴールを決める
2. ルールの確認
- 喋ること
- 考えや、これからすることを言葉にして発する
- お互い丁寧に。ミスの指摘も丁寧に。指摘されたら礼を言う。別にその人の能力が欠けているわけではないのだ
- ミスに気づいても、その行を書き終わるまで指摘を待つ
- お互い集中すること。2人で集中する方が1人で集中するより簡単なはず。片方が話している間はものを食べたりメールを見たりしない。どっちかが飽きたら1人でプログラムしているのと同じになる。
- お互いが何をやっているか把握すること（パートナーが今なにをやっているかわからなくなったり、今なにをするべきか見失ったりすることはよく起こる。認識がズレだしたら１分以内に話し合って頭の中の同期を取ること。）
- 喜ぶ
3.実施する
3.1 小さなゴールを決める( Driver 主導）
- 数分でできるようなことを考える。
- 問題や実施することを言葉にしてパートナーに伝える
3.2 プログラミング
- パートナーを頼りにし、支えあう
driver側
- プログラム全体の問題はnavigatorが考えてくれる。作業を終わらすことだけに専念すること。 navigatorに言われたとおりにコードを打ち込むようなことはしない。
navigator側
- driverのコードを横から確認し、バグ・デザインの改善や簡潔化、対局的な問題について考える 。指摘するタイミングは考える
3.3 喜ぶ
- 小さなゴールを達成したらお互いに喜ぶ
3.4 繰り返す
- 最初に決めた作業が完了するまで繰り返す。
- 必要に応じてdriverとNavigatorを交代してもいい。
- 3.1へ
4.ラップアップ
- "作業"を完了したら、振返りを行う。
- 気がついた点や今後のことなど、なんでもＯＫ
アジャイルチームビルディング
Agile Team Builidingのセミナーに参加してきました。
体験型セミナーで「実感」「体感」を大切にした良いセミナーでした。
http://www.tech-arts.co.jp/news-and-topics/events/2013/785
チームビルディングとは？
関係性の構築。個々が「思考（アジャイル的な考えとか」と「行動（スタンドアップミーティングしてみたりとか）」の質を変えても「関係性の質」が変わらなければ結果の向上は望めない。その関係性を構築するのがチームビルディング
チームワークからチームビルディングへの意識変換
「一緒にワークする」から「異質も認め」幅として強みを捉えていく。
チームワークできるようにしていくのではなく、異質が混ざった状態からチームをつくっていく（関係性を構築する）ことが大切。
チームビルディングする
（セミナーでは対立構造のあるチームの各メンバーを演じたりしながら、チームがつくられていく過程を体感できるロールプレイを実施しました。これは文章にしにくい、得られがたい経験でした）
原則
チームがつくられるとき、そこには「変革（エッジ）」がある。
考える
変革（エッジ）を超えるために、超えるまえの状態（１次プロセス）と超えた向こうにある状態（２次プロセス）を考える。変革（エッジ）が山のイメージ、山を超える感じ。
例）
１次プロセス：個人プレイの集団
変革（エッジ）：お互いを知ること。タスクを分担すること。
２次プロセス：チームで動く集団。ナレッジの共有ができる。助け合いができる。
変革（エッジ）を超えるためのきっかけを作る
これは、具体的なやりかたはたぶん色々な方法があるとは思います。マインドは以下。
・価値観の共有をする（価値観は優先度よりも大事）
・「プロセスをいれる/いれない」 から 「何が大変」で「どう変える」へ
・チームの肯定性（強み）を上げる
・対立の解決と協調関係の構築（話し合いさせてたり、目の前のタスクの期限をのばしたりして時間つくる。相手の立場になって意見を言うゲームとかも面白い）
・本音や小さい声をだせるように促進する（１対１で話すところから話してもいいし。セミナーでもやったけど関係ない椅子とりゲームしたりするのもいい。）
・チーム状態に自覚的になるように促す
・まず仲間をつくる（知識の質よりもまずは関係の質が大事。そこからチームをつくっていく。）
その他、自分へのメモ
「みなさんのことを教えてください」的言葉の強さ
「何かできることありますか」的言葉の強さ
自分一人でどうするか考えるのではなく、チームの強みをひきだすのがリーダーの仕事だったりする。（忘れないようにね）
たくらむ技術
- 作者: 加地倫三
- 出版社/メーカー: 新潮社
- 発売日: 2012/12/15
- メディア: 新書
- 購入: 2人 クリック: 64回
- この商品を含むブログ (14件) を見る
面白かった。テレビの仕事以外にも通じる考え方が多くあり、勉強になります。
「矛盾」は人をしらけさせる
その通り。これはチーム運営でも同じ。リーダーの言動に矛盾があればメンバーはしらけるのだ。
つまり、まだ悩む段階ではないのに悩んでいる人、悩むタイミングが分かっていない人は仕事が遅くなります
どこに時間を使うべきか、考えて動く。どうせ後で考えるようなことは、途中で深く悩み続けない。
「言った」「言わない」で揉めているスタッフがいます。こういう時、僕は「実際にこっちが言ったかどうかが問題ではない。相手の脳、心に伝わる言い方をしなければダメなんだ」と言い聞かせています。
議事録を残せ、とかの方法が恥ずかしくなる。上記が真実。（議事録は残したほうがいいと思います。）
魂を込めて、伝えること。忘れないようにしよう。
最後に。
予習と復習で進化する
まさにScrumですね。
振返り（レトロスペクティブ）技法
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き
- 作者: Esther Derby,Diana Larsen,角征典
- 出版社/メーカー: オーム社
- 発売日: 2007/09
- メディア: 単行本
- 購入: 10人 クリック: 1,282回
- この商品を含むブログ (114件) を見る
スクラムの中でもっとも重要なアクティビティーは「振返り」だと思います。
まずは認識。
改善を継続的に行うには最高のチームでもまだ改善の余地があることを認識しなければなりません
次に、レトロスペクティブの構成の基本（重要！）をまとめます
１.場を設定する・まずは、時間を割いてくれた参加者に対して歓迎と感謝の意を簡単に述べることから始める。・レトロスペクティブの目的と今回の目標を口に出して再確認する。・所要時間の確認を忘れずに行う２.データを収集する・目に見える記録を作る（イテレーションをまわすときに大切）３.アイデアを出す４.何をすべきかを決定する・何もしないレトロスペクティブは回避する。外部のグループを悪の根源と見なし、彼らが変わることを望んでいるチームは結局はフラストレーションをためてしまうだけだ。５.レトロスペクティブを終了する・レトロスペクティブのレトロスペクティブを行うこと
レトロスペクティブで結果として、チームの新しい目標をたてていくことになる。
その目標は注意が必要。有用な目標はたとえば以下のようなものである。ポジティブなやつ。
・プラクティスを改善する方法を見つける・うまくできているものを見つける・目標を達成できなかった理由を理解する・顧客への対応を改善する方法を見つける・関係を修復する
しかし、不適切なのは「テストでうまくいかなったことを解明する」などの目標は
チームを間違った方向に導き、非難への扉を開いてしまう。ここはスクラムマスターが十分に注意すべきところ。
最後に、本書に載っていたアクティビティのクイックリファレンスのメモ。使い分けやそのチームにあったアレンジが結局大切なのです、です。
| フェーズ | アクティビティ | 概要 他 |
| 場を設定する | チェックイン | 参加者を歓迎し目標とアジェンダのレビューを行ったあとで レトロスペクティブのリーダーが簡単な質問を１つする。 メンバーは順番に答える。（事前に質問を用意すること） 例：このMTGに求めていることは？いま、心に浮かぶことは？ |
| フォーカスオン/フォーカスオフ | 参加者を歓迎し、目標とアジェンダのレビューを行ったあとで レトロスペクティブのリーダーが生産的なコミュニケーションの パターンと非生産的なコミュニケーションのパターンについて 説明する。参加者たちは、その説明を聞いたあとで今回の レトロスペクティブにおいてそれが何を意味するのか議論する 例：質問＞主張、対話＞議論、会話＞口論、受容＞防御 |
|
| ESVP | 参加者はレトロスペクティブに望む自分の立場をExplorer(探検家) Shopper(買い物客)、Vacationer(行楽客）、Prisoner（囚人）の ４つのタイプを使って匿名で報告する。 リーダーは結果を集めて、データを表すヒストグラムを作る。 そのあと、結果がグループにとってどんな意味があるのか 議論してもらう 探検家：新しいアイデアを見つけ出すことに熱心な人 買物客：情報をくまなく見渡している人 行楽客：レトロスペクティブに興味はないが、日々の仕事から 逃げれるのでありがたいと思っている人のこと 囚人：参加を強制されていると感じている人のことだ ・議論の後、最後に「日々の業務に対する私たちの態度は、どの カテゴリに当てはまりますか？」と質問する （行楽客が多いのであれば、それをメイントピックに変更もあり） |
|
| チームの約束 | 効果的に仕事をするための振る舞いについて、チームでアイデアを出し合う。 その中から５〜７つ選び、チームの相互作用あプロセスの手引きとする。 （人が多ければサブチームで議論してもらって発表みたいな感じ） 多数決は賛成、グループに従う、反対で票を集める |
|
| 温度計 | 終了する の方を参照 | |
| 満足ヒストグラム | データを収集する の方を参照 | |
| データを収集する | タイムライン | グループメンバーがイテレーション、リリース、など プロジェクトで起きた、記憶に残ったり個人的に意味があったり そうでなくても重要だったりするイベントをカードに書く それらを（大まかに）時間順に並べる。事実や感情を理解するため にリーダーはプロジェクト中に起きたイベントを議論してもらう （長期のイテレーションとなで何があったか思い出す） |
| ５５５ | ５人程度の小さいグループを作る。各人が５分間ブレインストーミング をしてアイデアを書き出す。５分経過したらアイデアを書いた紙を 右隣の人に渡す。紙を渡された人は５分かけて書かれたアイデアに 関連したアイデアを書き加え、元の持ち主に戻るまで紙を回し続ける アイデアを読み上げ感想を聴く（気づいたことは？驚いたことは？ 欠けているものは？もっと掘り下げるべきものは？） |
|
| カラーコードドット | メンバーはカラーコードドットを使って、感情が高ぶったり沈んだりした イベントをタイムライン上に示す |
|
| 喜怒哀 | メンバーがカラーカードや付箋紙を使って、プロジェクトの最中に 喜んだり、怒ったり、悲しかったりした時間をあらわす。 発表→グループ化→質問（気になったことは？次のステップは？等） |
|
| 強みを見つける | メンバーがプロジェクトの良かったポイントについてお互いにインタビューする。 目標はこれらの良かったポイントを作り出した原因や状況を 理解することである。事前に以下のような質問を用意する ・その人の専門分野や会社の魅力について質問する ・イテレーションにおいてその人がベストだと思った 最高のポイントについて質問する ・それが最高のポイントである理由を質問する ・他の人と一緒だったか、どんな状況だったかを質問する ・今後のプロジェクトに対する希望について質問する このアクティビティはみんなが打ちひしがれているときに使うとよい 最悪のイテレーションであっても良いときあったことを思いださせて くれるからだ。 |
|
| 満足ヒストグラム | チームメンバーはヒストグラムを使って、プラクティスやプロセスに対する 個人やグループの満足度を計測する テーマ例：チームワークの満足度 など |
|
| チームレーダー | 調査したいプロセスや開発のプラクティスの要素について個人やグループ の評価を計測する（レーダー図を作成する） チームの価値：フィードバック、勇気、シンプルさ、コミュニケーション |
|
| ライクトゥライク | 「性質」カードに一番よく合っているイテレーションのイベントや 要因がどれかをメンバーが順番に判定する。カードを評価すると 同時に同じイベントや状況に対する観点の違いを学ぶ |
|
| アイデアを出す | ブレスト | （略） |
| フォースフィールドアナリシス | チームは達成したいと望む状態を定義する。小さなグループを創り、 望ましい変更をサポートまたは抑制する要因を特定する。それらの 要因を用紙に書き出す。サポートする要因間の相対的な強さを評価 する。同様に、抑制する要因間の相対的な強さを評価する。チーム はサポートする要因を強めたり、抑制する要因を弱めたりすること で影響を与えられる要因はないか議論する。 |
|
| ５つのなぜ | チームメンバーは問題を調べるためにペアまとは小さなグループで 作業する。「なぜ？」を５回繰り返すことで習慣的な考えを突破する |
|
| フィッシュボーン図 | チームは問題の状況を作り出した要因のなかから、最も可能性の 高いものを探し出す。可能性の高い要因を特定したら、それを変更 したり操作したりする方法を探す。 フィッシュボーン図 →問題や課題を魚の頭の部分に書く。そこには５つのW（What,Who,When,Where,Why) を含めるようにする。魚の骨の部分にはカテゴリをつける カテゴリ例：手法、機材、道具、人、場所、テヅ付き、方針、環境 下請け業者、システム、スキル 等 |
|
| パターンとシフト | データを収集したあとに、データを分析するために議論をファシリテートして イベント、振る舞い、感情などのパターンを探す。また、シフトが起きた時期 を探す。たとえば、すべてがスムーズに進んでいるときに急にエネルギーが落 ちたようなときだ。フリップチャートなどにアイデアをためる。 |
|
| ドットによる優先付け | チームメンバーは課題、アイデア、提案を優先づける | |
| まとめレポート | 各グループは成果をチーム全体で共有する。レトロスペクティブのリーダは、 レポートが時間内に収まるようプログレスバーを管理する。最後のレポートが 提出されたら共通の話題やテームを探し、取り組みたいことを特定する。 |
|
| テーマの特定 | 「強みをみつける」アクティビティのあおとで、ペアはグループをつくって インタビューから学んだことを報告する。チームメンバーはそこから共通の テーマや説得力のあるアイデアを見つける。テーマを特定したら、アイデア の書かれたカードを仕分ける。各グループは自分たちでカードの山を１つ 選択し、アイデアをさらに詳細化する。 |
|
| 学習マトリクス | ４つの観点からデータをマッピングし、課題を素早く洗い出す ・良かったこと/続けたいこと ・変えたいこと ・新しいアイデア ・感謝したい人 |
|
| 何をすべきか決定する | レトロスペクティブ計画ゲーム | チームメンバーは個人またはペアで試み、改善、提案などを完遂するために必要な すべてのタスクを洗い出す。一通り済んだら、余分なタスクは削除し、不足してい るタスクがあれば追加する。タスクは順番に並べられ、メンバーがタスクに サインアップする |
| SMARTな目標 | Specific（明確な）、Measurable（計測可能な）、Attainable（達成可能な） Relevant（適切な）、Timely（タイムリーな）目標を作れるようにする。 |
|
| しつもんの輪 | 次のステップに対する全員の意見を一致させるために、チームメンバーが お互いに質問する。 左隣の人に質問する。質問が十分に件とされたことに満足し、アクションに 対するコンセンサスがとれるまで順番に質問を繰り返す |
|
| 短い話題 | フリップチャートの指示に従って、チームはアクションのアイデアを 洗い出す。たとえば、以下のようなもがあげられる。 ・うまくいったこと/次回はやり方を変えたいこと ・続えけること/問題点/試してみること（KPT) ・ニコニコ/イライラ |
|
| ５５５ | ||
| フォースフィールドアナリシス | ||
| レトロスペクティブを終了する | プラス/デルタ | チームは（今以上にやるべき）強みや、次のレトロスペクティブで変更 することを見つける テーマ（例：プロセス改善）についてプラスとデルタ（改善点）を あげていく |
| 感謝 | 助けてくれたり、貢献してくれたり、問題を解決してくれたりしたメンバーに 感謝する。 |
|
| 温度計 | チームメンバーが、チームに起きていることを、 のぞむことをほうおくする。 温度計 ：感謝 ：パズル（理解していないが、興味のあること。） ：提案付きの苦情 ：新しい情報 ：希望と願望 |
|
| 役立った、邪魔だった、仮定した | フィードバックを集める。 これによって、セッションなかで一緒に作業したり学んだりする際に 役立ったことを発見したり、邪魔になったことを見つけたり、 今後のレトロスペクティブで試してみることのアイデアを手に入れたりする。 |
|
| 投資時間対効果 | レトロスペクティブの終了時に時間を有効に使えたかどうかの フィードバックを求める |
|
| 満足ヒストグラム | ||
| チームレーダー | ||
| 学習マトリクス | ||
| 短い話題 |
