アジャイルと私

(ライトニングトーク) 中年の主張
アジャイルと
スクラムと
わたし
(7年前にアジャイル開発やってて
考えたこと)

アジャイル
に魅力を
感じたのは

・開発者の復権

・開発者の自立

現場で開発していると。。。
●
ああすればよかった
●
あの時感じた不安が現実に
● なんで、

あのときだまっていたんだろう
● このソース直すなんて思ってなかっ

たから、動けばいいと思ってたんだ

こんな

モヤモヤ感や
罪悪感を
解消したい

ところで
アジャイルで
一番大事なことは

アジャイル

であることです

アジャイル
（俊敏）
（すばやい）

アジャイル宣言の 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.要件の変更は例え開発の後期であっても受け入れます。アジャイル･プロセスは変化を味方につけ
ることによってお客様の競争力を引き上げます。
6.開発チームに対して、あるいは開発チーム内部で情報を伝えるもっとも効率的で効果的な方法は
面と向かって話をすることです。


1.我々は価値のあるソフトウェアをできるだけ早い段階から継続的に引き渡すことによってお客様の
満足度を高めることをもっとも優先します。
2.要件の変更は例え開発の後期であっても受け入れます。アジャイル･プロセスは変化を味方につけ
ることによってお客様の競争力を引き上げます。
6.開発チームに対して、あるいは開発チーム内部で情報を伝えるもっとも効率的で効果的な方法は
面と向かって話をすることです。

と



アを


と

原則主義
っていいます

＞アジャイル12の原則

＞ 4つの価値

アジャイル
＞ 4つの価値

迷ったら原則に照らして
すばやく（アジャイルに）

決定する

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

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

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

スクラム

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

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

スクラム出演者
● プロダクトオーナー・・・顧客
(ｷﾗ★)
● スクラムチーム・・・開発担当

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

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

(ｷﾗ★)

スクラムの決まりごと
● ゲーム前計画および準備 (「プロダクトバックログ」作成「リリースバックログ」も)
● スプリント計画 (スプリントの終わりにリリースするものを決める。そして、少し掘り下げたりもする)
● スプリント（1ヶ月、1回の開発期間、「タイムボックス開発」なんていったりします（ｷﾗ★））
● 自立的な自己組織化チーム (スクラムチームは自ら考え問題を解決する。自立的に)
スクラムチーム
● スクラムミーティング(スタンドアップミーティング)
(昨日何をした？今日何をする？何か問題あった？)
● イテレーションに追加してはならない
● 自立的な自己組織化チーム（ニワトリとブタ）
● スクラムマスターのファイアウォール
● 1時間以内の判断
● 1日以内の障害排除
● ニワトリとブタ　(例外は、経営陣の製品の目的やビジョンについての発言)
● 7人のチーム
● 共通の部屋
● 日次ビルド
● スプリントレビュー

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

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

配役
● プロダクトオーナー
・・・柳川（プロキシー）
+エンドユーザ
● スクラムチーム

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

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

やったこと
● スクラムミーティング
● 1週間のスプリント
● 「スプリントバックログ」と「バーンダウンチャート」
● タスクは割り当てない
● ガントチャートを捨てる
● プロダクトバックログ
● 継続ビルド

スクラムミーティング
● 3つの質問
● 昨日なにをしましたか？
●
今日はなにをしますか？
●
問題が発生していたらおしえてください？

1週間のスプリント
● 次の1週間でできることを選ぶ
● 優先度の高い機能から順番に選ぶ

「スプリントバックログ」と
「バーンダウンチャート」
● 日々の実測値（残り工数の量）を採取
● プロジェクトが楽観的が悲観的か一目瞭然

タスクは割り当てない
● メンバーがタスクを選ぶ
● XPのプラクティスです

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

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

● ガントチャート嫌い

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

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

継続ビルド
● CI って呼ぶ(ｷﾗ★)
● CruiseControl
（Hudson なんてなかったので）

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

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

おおむね良好
● タスクの情報を十分共有すれば、
タスク割り当てなくても大丈夫。
やるべきことの誤解も少なくなる
● スクラムミーティングは、情報共有にすごく有効
トップダウンの連絡事項中心の朝会なんて
目じゃない
● CI は、開発を安定させる。
リファクタリングは怖くない

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

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

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

正直であれ！
● 「わからないこと」
「間違ってしまったこと」を認める。

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

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

考えることをやめない！
● 「書いてあるから」
とか
「決まったから」
とか
「聞いてないから」
とかは言い訳だ。

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

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

でも、
きっと
いいことあります

ご清聴
ありがとう
ございました

アジャイルと私

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie アジャイルと私

Ähnlich wie アジャイルと私 (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (9)

アジャイルと私