(ライトニングトーク)中年の主張

アジャイルとスクラムと

わたし

(7年前にアジャイル開発やってて考えたこと)

アジャイルに魅力を

感じたのは

・開発者の復権

・開発者の自立

現場で開発していると。。。

● ああすればよかった● あの時感じた不安が現実に● なんで、あのときだまっていたんだろう

● このソース直すなんて思ってなかったから、動けばいいと思ってたんだ

こんな

モヤモヤ感や罪悪感を

解消したい

ところでアジャイルで

一番大事なことは

アジャイル

であることです

アジャイル

アジャイル（俊敏）

（すばやい）

次には

アジャイル宣言 の4つの　　価値

● プロセスやツールよりも個人との対話を● 包括的なドキュメントよりも動くソフトウェ

アを● 契約交渉よりも顧客との協調を● 計画に従うことよりも変化への対応を

アジャイル宣言 の4つの　　価値

● プロセスやツールよりも個人との対話個人との対話を● 包括的なドキュメントよりも動くソフトウェ動くソフトウェ

アアを● 契約交渉よりも顧客との協調顧客との協調を● 計画に従うことよりも変化への対応変化への対応を

左側の大切さは理解しながらも、、右側右側がより大事

次には

アジャイル宣言の原則

我々は以下の原則に従います1.我々は価値のあるソフトウェアをできるだけ早い段階から継続的に引き渡すことによってお客様の満

足度を高めることをもっとも優先します。

2.要件の変更は例え開発の後期であっても受け入れます。アジャイル･プロセスは変化を味方につけることによってお客様の競争力を引き上げます。

3.動くソフトウェアを2~3週間から2~3ヶ月というできるだけ短い時間間隔で繰り返し引き渡します。

4.ビジネスをする人と開発者はプロジェクトを通して日々一緒に働かなければなりません。

5.意欲に満ちた人々を集めてプロジェクトを構成します。ですから彼らが必要とする環境と支援を与え仕事が無事終わるまで彼らを信頼してください。

6.開発チームに対して、あるいは開発チーム内部で情報を伝えるもっとも効率的で効果的な方法は面と向かって話をすることです。

7.動いているソフトウェアこそが進捗の最も重要な尺度です。

8.アジャイル･プロセスは持続可能な開発を促進します。スポンサ、開発者、ユーザは一定のペースで永続的に保守できるようにしなければなりません。

9.卓越した技術と優れた設計に対する不断の注意こそが機敏さを高めます。

10.単純さ - 作業せずに済む量を最大限に引き上げる技量 - が本質です。

11.最良のアーキテクチャ、要件、設計は自己組織的なチームから生み出されます。

12.どうしたらチームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

●

12条あります

覚えられませんL

まずは ４つだけでも

● プロセスやツールよりも個人との対話を● 包括的なドキュメントよりも動くソフトウェ

アを● 契約交渉よりも顧客との協調を● 計画に従うことよりも変化への対応を

アジャイル宣言 （12条あり）もたまには読み返そう

アジャイル宣言 （12条あり）もたまには読み返そう

アジャイルサムライを読めばよりよいかも。。。

アジャイルは

アジャイルは

原則主義

アジャイルプロセスは

XPだとか

スクラムだとか

クリスタルだとか

軽量なUPだとか

いろいろあるけれど

大事なことは

アジャイル宣言の原則

我々は以下の原則に従います1.我々は価値のあるソフトウェアをできるだけ早い段階から継続的に引き渡すことによってお客様の

満足度を高めることをもっとも優先します。

2.要件の変更は例え開発の後期であっても受け入れます。アジャイル･プロセスは変化を味方につけることによってお客様の競争力を引き上げます。

3.動くソフトウェアを2~3週間から2~3ヶ月というできるだけ短い時間間隔で繰り返し引き渡します。

4.ビジネスをする人と開発者はプロジェクトを通して日々一緒に働かなければなりません。

5.意欲に満ちた人々を集めてプロジェクトを構成します。ですから彼らが必要とする環境と支援を与え仕事が無事終わるまで彼らを信頼してください。

6.開発チームに対して、あるいは開発チーム内部で情報を伝えるもっとも効率的で効果的な方法は面と向かって話をすることです。

7.動いているソフトウェアこそが進捗の最も重要な尺度です。

8.アジャイル･プロセスは持続可能な開発を促進します。スポンサ、開発者、ユーザは一定のペースで永続的に保守できるようにしなければなりません。

9.卓越した技術と優れた設計に対する不断の注意こそが機敏さを高めます。

10.単純さ - 作業せずに済む量を最大限に引き上げる技量 - が本質です。

11.最良のアーキテクチャ、要件、設計は自己組織的なチームから生み出されます。

12.どうしたらチームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

アジャイル宣言の原則

我々は以下の原則に従います1.我々は価値のあるソフトウェアをできるだけ早い段階から継続的に引き渡すことによってお客様の

満足度を高めることをもっとも優先します。

2.要件の変更は例え開発の後期であっても受け入れます。アジャイル･プロセスは変化を味方につけることによってお客様の競争力を引き上げます。

3.動くソフトウェアを2~3週間から2~3ヶ月というできるだけ短い時間間隔で繰り返し引き渡します。

4.ビジネスをする人と開発者はプロジェクトを通して日々一緒に働かなければなりません。

5.意欲に満ちた人々を集めてプロジェクトを構成します。ですから彼らが必要とする環境と支援を与え仕事が無事終わるまで彼らを信頼してください。

6.開発チームに対して、あるいは開発チーム内部で情報を伝えるもっとも効率的で効果的な方法は面と向かって話をすることです。

7.動いているソフトウェアこそが進捗の最も重要な尺度です。

8.アジャイル･プロセスは持続可能な開発を促進します。スポンサ、開発者、ユーザは一定のペースで永続的に保守できるようにしなければなりません。

9.卓越した技術と優れた設計に対する不断の注意こそが機敏さを高めます。

10.単純さ - 作業せずに済む量を最大限に引き上げる技量 - が本質です。

11.最良のアーキテクチャ、要件、設計は自己組織的なチームから生み出されます。

12.どうしたらチームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

と

アジャイル宣言 の4つの　　価値

● プロセスやツールよりも個人との対話を● 包括的なドキュメントよりも動くソフトウェ

アを● 契約交渉よりも顧客との協調を● 計画に従うことよりも変化への対応を

アジャイル宣言 の4つの　　価値

● プロセスやツールよりも個人との対話を● 包括的なドキュメントよりも動くソフトウェ

アを● 契約交渉よりも顧客との協調を● 計画に従うことよりも変化への対応を

と

アジャイル

アジャイル（俊敏）

（すばやい）

原則主義

っていいます

＞ アジャイル12の原則

＞ 4つの価値 ＞ アジャイル12の原則

アジャイル ＞ 4つの価値 ＞ アジャイル12の原則

迷ったら原則に照らして

すばやく（アジャイルに）

決定する

原則主義

です

とはいえ。。。

プロセスを参考にしないと。。。はじめられない。。。

とはいえ。。。

プロセスを参考にしないと。。。はじめられない。。。

スクラム を参考にしました

スクラム 紹介

スクラム

決まりごとが比較的少ないプロセス

(「儀式的でない」なんていったりします。 ↑専門用語入れてみた(キラ★) )

スクラム出演者

● プロダクトオーナー ・・・ 顧客(ｷﾗ★)

● スクラムチーム ・・・ 開発担当(ｷﾗ★)

● スクラムマスター ・・・ マネジメント(ｷﾗ★)

● ニワトリ (それ以外の人々)(ｷﾗ★)

スクラムの決まりごと

● ゲーム前計画および準備 (「プロダクトバックログ」作成「リリースバックログ」も)● スプリント計画 (スプリントの終わりにリリースするものを決める。そして、少し掘り下げたりもする)● スプリント （1ヶ月、1回の開発期間、「タイムボックス開発」なんていったりします（ｷﾗ★））

● 自立的な自己組織化チーム (スクラムチームスクラムチームは自ら考え問題を解決する。自立的に)● スクラムミーティング(スタンドアップミーティング)

(昨日何をした？今日何をする？何か問題あった？)

● イテレーションに追加してはならない

● 自立的な自己組織化チーム（ニワトリとブタ）

● スクラムマスターのファイアウォール

● 1時間以内の判断

● 1日以内の障害排除

● ニワトリとブタ　(例外は、経営陣の製品の目的やビジョンについての発言)● 7人のチーム

● 共通の部屋

● 日次ビルド

● スプリントレビュー

スクラム紹介 以上

儀式的でないっていっても、プラクティス（ｷﾗ★）多い大変。。。

ぜんぶできないよ。。。

できるところ とやりたいところからやろうと思いました

配役

● プロダクトオーナー ・・・ 柳川（プロキシー） +エンドユーザ

● スクラムチーム ・・・ Kさん、Yさん、柳川 (3名)

● スクラムマスター ・・・ 柳川● ニワトリ (それ以外の人々)

やったこと● スクラムミーティング

● 1週間のスプリント

● 「スプリントバックログ」と「バーンダウンチャート」● タスクは割り当てない● ガントチャートを捨てる● プロダクトバックログ● 継続ビルド

スクラムミーティング

● 3つの質問● 昨日なにをしましたか？● 今日はなにをしますか？● 問題が発生していたらおしえてください？

1週間のスプリント

● 次の1週間でできることを選ぶ

● 優先度の高い機能から順番に選ぶ

「スプリントバックログ」と「バーンダウンチャート」

● 日々の実測値（残り工数の量）を採取● プロジェクトが楽観的が悲観的か一目瞭然

タスクは割り当てない● メンバーがタスクを選ぶ

● XPのプラクティスです

● これが一番やりたかった気がする

ガントチャートを捨てる● ガントチャートからは残っているタスクの量（工数）は読み取れない

● ガントチャート嫌い

プロダクトバックログ● 本来の意味では、実現したいユーザ機能の一覧

● そこまでやりきれなかった（理解してなかった）ので、WBS（Work Breakdown Structure）のようにタスク一覧化して使った

継続ビルド

● CI って呼ぶ(ｷﾗ★)● CruiseControl

（Hudson なんてなかったので）

● ViewとControler以外は全部Unitテストする

● 壊れたら真っ先に直す。（テストエラー、コンパイルエラー）

感触

おおむね良好

● タスクの情報を十分共有すれば、タスク割り当てなくても大丈夫。やるべきことの誤解も少なくなる

● スクラムミーティングは、情報共有にすごく有効トップダウンの連絡事項中心の朝会なんて目じゃない

● CI は、開発を安定させる。リファクタリングは怖くない

きっと、こんな感覚が大事！ と思う

すぐに決めて、すぐに実行する

● 今やりたいことはわからなくても、すぐに決める。後回しにしない

● 間違ってることがわかったら、やり直す

正直であれ！

● 「わからないこと」「間違ってしまったこと」を認める。

● できていることと、できていないことを把握する

● 情況報告をごまかさない

考えることをやめない！

● 「書いてあるから」とか「決まったから」とか「聞いてないから」とかは言い訳だ。

● 知った瞬間から、どうすべきか真摯に考える

アジャイルにも明暗あります

でも、

きっといいことあります

おわり

ご清聴

ありがとう ございました