Scrum alliance regional gathering tokyo 2013 pub

2,344 views

Published on

0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,344
On SlideShare
0
From Embeds
0
Number of Embeds
45
Actions
Shares
0
Downloads
9
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide

Scrum alliance regional gathering tokyo 2013 pub

  1. 1. Scrum Alliance Regional Gathering Tokyo 2013あなたのプロジェクトでは、アンドンを引けますか。Smalltalkという源流に学ぶ --- 僕だってCoplienの話を聞きたいよん --- 今野 睦(a.konno@gxp.co.jp)
  2. 2. アジャイルコミュニティでもTPSコミュニティでも 無所属旧人 1
  3. 3. こんな人らしい 2
  4. 4. 1990年代のとある開発チームの一日 作業履歴 • sssssssssshttp://aokilab.kyoto-su.ac.jp/documents/SmalltalkSoftwareDevelopment/SAscii02.html より引用。 3
  5. 5. 1990年代とは 1994 • Java 1.0a 1995 • Scrum OOPSLA 1997 • UML 1.0 • XP 1999 • J2EE 1.2 2002 • Java 1.4 (Fix and Continue) 2006 • Java 6(リフレクション) 4
  6. 6. スクラムの原点(Scrum:It’s All About Common Sense*より) ジェフ・サザーラン ド たちが、いろんな 考えを取り入れて Smalltalk で動作する フレームワークを作り Smalltalkを取り去っ て「なんでも入る箱」 にした。* http://silab.fon.rs/index2.php?option=com_docman&task=doc_view&gid=238&Itemid=5 http://www.danube.com/docs/certifiedScrum/csm.pdf 5
  7. 7. 古文書の読み解きThe New New Product Development Game(1986) http://jeffsutherland.com/ScrumPapers.pdf • 不安定な状態を保つ • プロジェクトチームは自ら組織化する • 開発フェーズを重複させる • マルチ学習 • 柔らかなマネジメント • 学びを組織で共有するBorland Quattro Pro Windows (1993) http://users.rcn.com/jcoplien/Patterns/Process/QPW/borland.html • ひとりあたり週1000ステップ(C++)の生産性 • 組織パターン • 朝会の概念インクリメンタルとイテレーティブ • ラウンドトリップ開発 booch、 Rumbaugh -RUP • RUPからリバースを対象に?タイムボックス • プロトタイピング、RAD 6
  8. 8. アンドンを引けますか 活き活きと働いています • 自働 ラインが止まります • あんどん(多能工) 7
  9. 9. “The New New Product Development Game”の事例で紹介されている企業の共通点 – 富士ゼロックス – キヤノン – 本田技研工業 – 日本電気 – セイコーエプソン – ブラザー工業 – 3M – ゼロックス – ヒューレット・パッカードなど 8
  10. 10. かんばん方式の実施の前提条件 生産に継続性、反復性がある • 個別注文生産などには向かない 生産の小ロット化、平準化 • サイクルタイムの遵守 工程・品質の安定 • 不良が多い工程には使えない 9
  11. 11. TPSをIT分野でトヨタのように成功させた企業をご存知ですか– リーンソフトウェア開発の提唱者は、以下のように述べている*。 • 製造工程に適用されているリーンのプラクティスを、そのま まソフトウェア開発に移植できない 。 • ソフトウェアを作り出す活動は「製造プロセス(レシピに従っ て料理をつくること)」ではなく、「開発プロセス(レシピの 作成)」であって、試行錯誤を含む学習プロセスだからだ。 • また、具体的適用については、「あるチームには薬でも、そ れが別のチームにとっては毒となる」。どのツールからどの ようなプラクティスを 導き出し、どの程度実践するかは状況 に応じて行われるべきだ。 * Lean Software Development: An Agile Toolkit 10
  12. 12. リーンソフトウェア開発22のツール1. ムダを認識する2. バリューストリーム・マップ3. フィードバック4. イテレーション5. 同期6. 集合ベース開発7. オプション思考8. 最終責任時点9. 意思決定10. プルシステム11. 待ち行列理論12. 遅れのコスト13. 自発的決定14. モチベーション15. リーダーシップ16. 専門知識17. 認知統一性18. コンセプト統一性19. リファクタリング20. テスティング21. 計測22. 契約 11
  13. 13. こんな人でもあります 12
  14. 14. とあるスクラムマスターからの忠告• Scrumを説くのにSmalltalkがどうのこうのと 言っている輩は、 – 現実と対峙する方法であるScrum、 – 対峙する立場のマスターという認識ではなく、 – Scrumという方法がどこかにあって、それを 適用するという考えに囚われている。 – そのような理解をしていると、外部の組織と チームとの間に立って、外部と対峙する役目 はうまく果たせないでしょう。 13
  15. 15. パロ・アルト研究所の成果• ALTO• WIMP (windows, icons, menus, pointers) インタフェース• WYSIWYGテキストエディタ• InterPress(解像度非依存のグラフィカルページ記述言語。 PostScriptの先駆け)• イーサネット• Smalltalk 14
  16. 16. Smalltalkとは• Dynabookのソフトウェア環境 – VM上で稼働させる• Xerox Palo Alto Research Cente Dynabookプロ ジェクト – Alan Kay – Dan Ingalls – L Peter Deutsch – Adele Goldberg – Ted Kaehler – Scott Wallace – Glen Krasner 15
  17. 17. Smalltalkを取り去るということ 開発環境 言語 Art Smalltalk (OS)処理系としてのSmalltalkは取り去り、Artは残す 16
  18. 18. The Art and Science ofSmalltalkSCIENCE ART第1章 はじめにいくつかのアドバイス 第11章 Smalltalkのアートとは第2章 オブジェクトとは 第12章 Smalltalkによる設計第3章 Smalltalkとは 第13章 Smalltalkのコーディング第4章 Smalltalk言語 第14章 開発ツールの利用第5章 Smalltalk開発環境 第15章 Smalltalkコードのデバッグ第6章 Smalltalkクラスライブラリ 第16章 Smalltalkプロジェクトの管理第7章 コレクションクラス第8章 ディペンデンシィ機構第9章 MVCアーキテクチャ第10章 プラガビリティとアダプタ 17
  19. 19. 環境としてのSmalltalk ブラウザといってもwebブラウザとは違う すべての変更点が自動的にバージョン管理 Smalltalkのデバック バイトコード 18
  20. 20. ブラウザといってもwebブラウザとは違う 19
  21. 21. すべての変更点が自動的にバージョン管理 20
  22. 22. Smalltalkのデバック 21
  23. 23. バイトコード(イメージファイル) 22
  24. 24. 言語としてのSmalltalk すべてのものは オブジェクト すべてのオブ すべてはメッ ジェクトはクラ セージ送信 スのインスタン Smalltalk ス のオブジェ クトモデル すべてのクラス 継承の連鎖をた にスーパークラ どってメソッド ス 探索 23
  25. 25. すべてのものはオブジェクト• つまり、クラスもオブジェクト – (1 to: 10). – Interval from: 1 to:10 by: 1. – (1/3)+(1/3)+(1/3)• プロッククロージャ – 遅延評価、制御構造、カプセル化、再帰 – | red | red := [Transcript cr; show: 赤]. red value. – #(赤 青 黄 ) do: [:each | Transcript cr; show: each printString]. – result := a > b • ifTrue:[ aはbよりが大きい ] • ifFalse:[ aはbよりl小さいか等しい ]. 24
  26. 26. すべてのオブジェクトはクラスのインスタンスクラスはオブジェクトということは、すべてのオブジェクトはクラスのインスタンスしたがって、クラスもまた、あるクラスのインスタンスクラスをインスタンス化するクラスはメタクラス• メタクラス• クラスに関するメタプログラミングが行える• リフレクション• 文字列(クラス名)を使ってクラスを生成したり、 メソッド名の文字列を使ってメソ ッドを呼び出したりできる。 25
  27. 27. すべてのクラスにはスーパークラスがあるインスタンス・クラスの別なく、オブジェクトとしての普遍的な振る舞 い Objectクラスの最低限の振る舞い(コンパイルされたメソッドの保持や インスタ Behaviorンス生成)(抽象クラス) - クラスの振る舞い(メソッドのコンパ イルやカテゴリ管 ClassDescription理)通常のクラスの振る舞い(スーパークラスとしての振る舞い やクラスカテ Classゴリ)メタクラス独自の振る舞い(一部メッセージをクラスへ リダイレク Metaclassト) 26
  28. 28. すべてはメッセージ送信で すべてのメッセージを無視するNULLオブジェクトを生成できる 必要なメッセージだけを処理するイベントハンドラを実装できる 受け取ったメッセージをフィールドに委譲し一種の多重継承を実現できるフィールドへの委譲を利用し、動的な継承を実現できる( すべてのオブジェクトに対し使用可能なProxyオブジェクトを生成できる メッセージを遅延送信できる 27
  29. 29. 継承の連鎖をたどってメソッド探索 Object Morph initialize defaultColor openInWorld fullPrintOn: ④ anEllipse openInWorld BorderedMorph ① initialize fullPrintOn: ③ ② anEllipse EllipseMorph メッセージ送信 継承 defaultColor lookup 28
  30. 30. 失われたSmalltalk 不可逆性 • 汎化→特化 残せなかったアート • オープンなソースコード • クラスごとの例題 • Smalltalkベストプラクティス・パターン • たとえば、 • イテレータに渡すブロックの引数には、each を使おう。 • HowではなくWhatを名前にしよう 29
  31. 31. とあるXBreed開発チームの一日 XPのプラクティス ×計画ゲーム ○短期リリース ○メタファ ○シンプルな設計 • ssssssssss ○テストファースト ○リファクタリング △ペアプログラミング マスタ ○共同所有 ○継続的インテグレー ション △40時間労働 ×オンサイトのユーザー ○コーディング規約 メンバ スプリント プロダクト スプリント バックログ バックログ 30
  32. 32. その他の源流 哲学者kuhn 知的創造プロセス 複雑系科学 人類学 システム力学 心理学 アメリカンフットボールのメタファ 31
  33. 33. まとめトヨタ工場見学に最低3回、いきましょうTPSのソフトウェア開発への導入についてはメアリーらにScrumは新しいものではないXBreedとなる?継続的改善
  34. 34. ご清聴ありがとうございます• Amber Smalltalk – http://amber-lang.net/• Smalltalkのオープンソース実装”Pharo” – http://www.pharo-project.org/home 33

×