アジャイルと私
1 like1,108 views
Agile and I. Material for Lightning Talk in study meeting of company.
More Related Content
What's hot (20)
Similar to アジャイルと私 (20)
Recently uploaded (11)
アジャイルと私
- 1. (ライトニングトーク) 中年の主張 アジャイルと スクラムと わたし (7年前にアジャイル開発やってて 考えたこと)
- 4. 現場で開発していると。。。 ● ああすればよかった ● あの時感じた不安が現実に ● なんで、 あのときだまっていたんだろう ● このソース直すなんて思ってなかっ たから、動けばいいと思ってたんだ
- 8. アジャイル
- 10. 次には
- 11. アジャイル宣言 の 4つの 価値 ● プロセスやツールよりも個人との対話を ● 包括的なドキュメントよりも動くソフトウェ アを ● 契約交渉よりも顧客との協調を ● 計画に従うことよりも変化への対応を
- 12. アジャイル宣言 の 4つの 価値 ● プロセスやツールよりも個人との対話を 個人との対話 ● 包括的なドキュメントよりも動くソフトウェ アを ● 契約交渉よりも顧客との協調を 顧客との協調 ● 計画に従うことよりも変化への対応を 変化への対応 左側の大切さは理解しながらも、 右側がより大事 右側
- 13. 次には
- 14. アジャイル宣言の原则 我々は以下の原則に従います 1.我々は価値のあるソフトウェアをできるだけ早い段階から継続的に引き渡すことによってお客様の満 足度を高めることをもっとも優先します。 2.要件の変更は例え開発の後期であっても受け入れます。アジャイル?プロセスは変化を味方につける ことによってお客様の競争力を引き上げます。 3.動くソフトウェアを2~3週間から2~3ヶ月というできるだけ短い時間間隔で繰り返し引き渡します。 4.ビジネスをする人と開発者はプロジェクトを通して日々一緒に働かなければなりません。 5.意欲に満ちた人々を集めてプロジェクトを構成します。ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 6.開発チームに対して、あるいは開発チーム内部で情報を伝えるもっとも効率的で効果的な方法は面 と向かって話をすることです。 7.動いているソフトウェアこそが進捗の最も重要な尺度です。 8.アジャイル?プロセスは持続可能な開発を促進します。スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 9.卓越した技術と優れた設計に対する不断の注意こそが機敏さを高めます。 10.単純さ - 作業せずに済む量を最大限に引き上げる技量 - が本質です。 11.最良のアーキテクチャ、要件、設計は自己組織的なチームから生み出されます。 12.どうしたらチームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分た ちのやり方を最適に調整します。 ●
- 15. 12条あります 覚えられません L
- 16. まずは ４つだけでも ● プロセスやツールよりも個人との対話を ● 包括的なドキュメントよりも動くソフトウェ アを ● 契約交渉よりも顧客との協調を ● 計画に従うことよりも変化への対応を
- 19. アジャイルは
- 20. アジャイルは 原则主义
- 21. アジャイルプロセスは
- 22. XP だとか スクラム だとか クリスタル だとか 軽量なUP だとか
- 23. いろいろあるけ れど
- 24. 大事なことは
- 25. アジャイル宣言の原则 我々は以下の原則に従います 1.我々は価値のあるソフトウェアをできるだけ早い段階から継続的に引き渡すことによってお客様の 満足度を高めることをもっとも優先します。 2.要件の変更は例え開発の後期であっても受け入れます。アジャイル?プロセスは変化を味方につけ ることによってお客様の競争力を引き上げます。 3.動くソフトウェアを2~3週間から2~3ヶ月というできるだけ短い時間間隔で繰り返し引き渡します。 4.ビジネスをする人と開発者はプロジェクトを通して日々一緒に働かなければなりません。 5.意欲に満ちた人々を集めてプロジェクトを構成します。ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 6.開発チームに対して、あるいは開発チーム内部で情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 7.動いているソフトウェアこそが進捗の最も重要な尺度です。 8.アジャイル?プロセスは持続可能な開発を促進します。スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 9.卓越した技術と優れた設計に対する不断の注意こそが機敏さを高めます。 10.単純さ - 作業せずに済む量を最大限に引き上げる技量 - が本質です。 11.最良のアーキテクチャ、要件、設計は自己組織的なチームから生み出されます。 12.どうしたらチームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分た ちのやり方を最適に調整します。
- 26. アジャイル宣言の原则 我々は以下の原則に従います 1.我々は価値のあるソフトウェアをできるだけ早い段階から継続的に引き渡すことによってお客様の 満足度を高めることをもっとも優先します。 2.要件の変更は例え開発の後期であっても受け入れます。アジャイル?プロセスは変化を味方につけ ることによってお客様の競争力を引き上げます。 3.動くソフトウェアを2~3週間から2~3ヶ月というできるだけ短い時間間隔で繰り返し引き渡します。 4.ビジネスをする人と開発者はプロジェクトを通して日々一緒に働かなければなりません。 5.意欲に満ちた人々を集めてプロジェクトを構成します。ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 6.開発チームに対して、あるいは開発チーム内部で情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 と 7.動いているソフトウェアこそが進捗の最も重要な尺度です。 8.アジャイル?プロセスは持続可能な開発を促進します。スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 9.卓越した技術と優れた設計に対する不断の注意こそが機敏さを高めます。 10.単純さ - 作業せずに済む量を最大限に引き上げる技量 - が本質です。 11.最良のアーキテクチャ、要件、設計は自己組織的なチームから生み出されます。 12.どうしたらチームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分た ちのやり方を最適に調整します。
- 27. アジャイル宣言 の 4つの 価値 ● プロセスやツールよりも個人との対話を ● 包括的なドキュメントよりも動くソフトウェ アを ● 契約交渉よりも顧客との協調を ● 計画に従うことよりも変化への対応を
- 28. アジャイル宣言 の 4つの 価値 ● プロセスやツールよりも個人との対話を ● 包括的なドキュメントよりも動くソフトウェ アを ● 契約交渉よりも顧客との協調を ● 計画に従うことよりも変化への対応を と
- 29. アジャイル
- 31. 原则主义 っていいます
- 32. ＞ アジャイル12の原则
- 34. アジャイル ＞ 4つの価値 ＞ アジャイル12の原则
- 36. 原则主义 です
- 39. スクラム 紹介
- 41. スクラム出演者 ● プロダクトオーナー ??? 顧客 (??★) ● スクラムチーム ??? 開発担当 (??★) ● スクラムマスター ??? マネジメント (??★) ● ニワトリ (それ以外の人々) (??★)
- 42. スクラムの決まりごと ● ゲーム前計画および準備 (「プロダクトバックログ」作成「リリースバックログ」も) ● スプリント計画 (スプリントの終わりにリリースするものを決める。そして、少し掘り下げたりもする) ● スプリント （1ヶ月、1回の開発期間、「タイムボックス開発」なんていったりします（??★）） ● 自立的な自己組織化チーム (スクラムチームは自ら考え問題を解決する。自立的に) スクラムチーム ● スクラムミーティング(スタンドアップミーティング) (昨日何をした？今日何をする？何か問題あった？) ● イテレーションに追加してはならない ● 自立的な自己組織化チーム（ニワトリとブタ） ● スクラムマスターのファイアウォール ● 1時間以内の判断 ● 1日以内の障害排除 ● ニワトリとブタ (例外は、経営陣の製品の目的やビジョンについての発言) ● 7人のチーム ● 共通の部屋 ● 日次ビルド ● スプリントレビュー
- 43. スクラム紹介 以上
- 46. 配役 ● プロダクトオーナー ??? 柳川（プロキシー） +エンドユーザ ● スクラムチーム ??? Kさん、Yさん、柳川 (3名) ● スクラムマスター ??? 柳川 ● ニワトリ (それ以外の人々)
- 47. やったこと ● スクラムミーティング ● 1週間のスプリント ● 「スプリントバックログ」と「バーンダウンチャート」 ● タスクは割り当てない ● ガントチャートを捨てる ● プロダクトバックログ ● 継続ビルド
- 48. スクラムミーティング ● 3つの質問 ● 昨日なにをしましたか？ ● 今日はなにをしますか？ ● 問題が発生していたらおしえてください？
- 49. 1週間のスプリント ● 次の1週間でできることを選ぶ ● 優先度の高い機能から順番に選ぶ
- 50. 「スプリントバックログ」と 「バーンダウンチャート」 ● 日々の実測値（残り工数の量）を採取 ● プロジェクトが楽観的が悲観的か一目瞭然
- 51. タスクは割り当てない ● メンバーがタスクを選ぶ ● XPのプラクティスです ● これが一番やりたかった気がする
- 52. ガントチャートを捨てる ● ガントチャートからは 残っているタスクの量（工数）は読み取れない ● ガントチャート嫌い
- 53. プロダクトバックログ ● 本来の意味では、実現したいユーザ機能の一覧 ● そこまでやりきれなかった（理解してなかった） ので、 WBS（Work Breakdown Structure）のように タスク一覧化して使った
- 54. 継続ビルド ● CI って呼ぶ(??★) ● CruiseControl （Hudson なんてなかったので） ● ViewとControler以外は全部Unitテストする ● 壊れたら真っ先に直す。 （テストエラー、コンパイルエラー）
- 55. 感触
- 56. おおむね良好 ● タスクの情報を十分共有すれば、 タスク割り当てなくても大丈夫。 やるべきことの誤解も少なくなる ● スクラムミーティングは、情報共有にすごく有効 トップダウンの連絡事項中心の朝会なんて 目じゃない ● CI は、開発を安定させる。 リファクタリングは怖くない
- 57. きっと、 こんな感覚が 大事！ と思う
- 58. すぐに決めて、すぐに実行する ● 今やりたいことは わからなくても、すぐに決める。 後回しにしない ● 間違ってることがわかったら、やり直す
- 59. 正直であれ！ ● 「わからないこと」 「間違ってしまったこと」を認める。 ● できていることと、できていないことを把握する ● 情況報告をごまかさない
- 60. 考えることをやめない！ ● 「書いてあるから」 とか 「決まったから」 とか 「聞いてないから」 とかは言い訳だ。 ● 知った瞬間から、どうすべきか真摯に考える
- 61. アジャイルにも 明暗あります
- 62. でも、 きっと いいことあります
- 63. おわり
- 64. ご清聴 ありがとう ございました