Ultimate agilisttokyo(japanese)

906 views

Published on

Ultimate Agile Tokyo の英語の資料を一部日本語化しました。ICAgileの体系の部分は日本語化しています。このブログと一緒に見ると他の資料もゲットできます。
http://d.hatena.ne.jp/simplearchitect/20121117/1353181189

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

No Downloads
Views
Total views
906
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
8
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Ultimate agilisttokyo(japanese)

  1. 1. Ultimate Agilist Tokyo Nov 17, 2012 アジャイルプログラマーになるためには! 日本語ガイド How to be an Agile Programmer T s u y o s h i U s h i o12年11月21日水曜日
  2. 2. 12年11月21日水曜日
  3. 3. Think about Definition of Agile Programmer アジャイルプログラマの定義を考えてみよう in this session12年11月21日水曜日
  4. 4. Agenda Learn about other definitions 他の定義について学ぶ Discussion ディスカッション Conclusion 結果のまとめ12年11月21日水曜日
  5. 5. Learn about other definitions12年11月21日水曜日
  6. 6. What is Agile Development?Agile software development is a group of software development methods based on iterative andincremental development, where requirements and solutions evolve through collaboration betweenself-organizing, cross-functional teams. It promotes adaptive planning, evolutionary developmentand delivery, a time-boxed iterative approach, and encourages rapid and flexible response tochange. It is a conceptual framework that promotes foreseen interactions throughout the developmentcycle. The Agile Manifesto[1] introduced the term in 2001. WIKIPEDIA http://en.wikipedia.org/wiki/Agile_software_development アジャイルソフトウェア宣言でGoogleすると、日本語の定義が出てきます! http://agilemanifesto.org/iso/ja/12年11月21日水曜日
  7. 7. アジャイルソフトウェア宣言でGoogleすると、日本語の定義が出てきます! http://agilemanifesto.org/iso/ja/principles.html Agile Manifesto Value Principle 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Individuals and interactions Agile processes harness change for the customers competitive advantage. over processes and tools 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. Working software over comprehensive 5. Build projects around motivated individuals. Give them the environment documentation and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Customer collaboration 7. Working software is the primary measure of progress. over contract negotiation 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. Responding to change over 10. Simplicity--the art of maximizing the amount of work not done--is essential. following a plan 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, hen tunes and adjusts its behavior accordingly.12年11月21日水曜日
  8. 8. Analyze it ごめん、これは勘弁して ただし、ブログにこれの後さらに 分析して日本語化したTreeあり https://s3-ap-northeast-1.amazonaws.com/ultimateagilisttokyoupload/アジャイルプログラマのスキルマップ.png12年11月21日水曜日
  9. 9. XP practices XPのプラクティス http://ullizee.wordpress.com/2009/11/02/extreme-programming-revisited-part-i/12年11月21日水曜日
  10. 10. five objectives for agile programmer アジャイルプログラマーが達成すべき5つの目的 Continuous Delivery of valuable software Embrace change Deliver Working Software frequently Continuous attention to Technical Excellence and Good Design Create the best architecture, requirements and design emerge form Self-Organization-Team Programmer related Agile Manifesto 12 principles 価値あるソフトウェアを継続的にデリバリーする 変化を抱擁する 頻繁に動作するアプリケーションを届ける 技術的に卓越することと、よいデザインにずっと注意を払う 最高のアーキテクチャ、要求、設計は、自己組織化された チームから生まれる プロブラマーに関係するアジャイルソフトウェア宣言の12の原則からピックアップしました12年11月21日水曜日
  11. 11. Manifesto for software craftsmanship Not only working software, but also well-crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships ソフトウェア職人宣言 http://manifesto.softwarecraftsmanship.org 動作するソフトウェアだけではなく、しっかり作られたソフトウェアを 変化に対応するだけではなく、着実に価値を付加していくことを 個人と相互作用だけでなく、プロフェッショナルたちのコミュニティを 顧客との強調だけでなく、生産的なパートナーシップを12年11月21日水曜日
  12. 12. ICAgile ICAgile exists to support education in the agile space. Use ICAgile’s definitive learning roadmap to find accredited courses that recognize students as they progress along their specialty paths. ICAgileは、アジャイル分野に関する教育を助けるために存在します ICAgileの定義されたロードマップをつかうことで、公式なコースを見つける事ができます 進路に応じて、生徒がどのように成長していけばいいか、理解することができます Fundamentals of Agile アジャイルの基本 Agile Business Analysis +Value Management ビジネスアナリシスとバリューマネジメント Agile Project Management アジャイルプロジェクトマネジメント Agile Facilitation + Coaching アジャイルファシリテーションとコーチング Agile Software Design + Programming アジャイルソフトウェア設計とプログラミング Agile Testing http://www.icagile.com/index.html アジャイルテスト12年11月21日水曜日
  13. 13. Learning Areas Agile Software Design +Programming 1.1. Test Driven Development 1.1. テスト駆動開発 1.2. Good Design 1.2. よい設計 1.3. 技術的負債 1. Designing & Programming 1.3. Technical Debt 1.4. リファクタリング 1.4. Refactoring 1.5. レガシーコード 設計とプログラミング 1.5. Legacy Code 2.1. Acceptance Test 2.1. 受入テスト 2. Testing 2.2. テストのプログラミング 2.2. Programming the test テスト 3.1. Collaboration 3.1. コラボレーション 3.2. 共同責任 3. Teams and Behaviors 3.2. Collective Accountability 3.3. チームアクティビティ チームと振る舞い 3.3. Team Activity 4.1. Function-Based Development 4. Structuring Work 4.1. 機能ベース開発 4.2. Planning 4.2. プランニング 作業を構造化する 5. Environment 5.1. Leveraging Tools 環境 5.1. ツールを活用する12年11月21日水曜日
  14. 14. five objectives and practices Five Objectives Practices 日本語版 https://s3-ap-northeast-1.amazonaws.com/ultimateagilisttokyoupload/アジャイルプログラマのスキルマップ.png Agile Programmer’s mandatory skill Map12年11月21日水曜日
  15. 15. Please get documents from http://simple-architect.blogspot.jp 日本語版 http://d.hatena.ne.jp/simplearchitect/20121117/135318118912年11月21日水曜日
  16. 16. Discussion12年11月21日水曜日
  17. 17. Golden Circle Why is Vision is our gut has emotion and heart create something bigger then your self How is Mission brings up guiding principle Why What is Rules How has practices What is dynamic organic Why time to market(ex) How 12 principles What priactices 1. Post What (Practice ex. TDD) 2. Post How (Principles ex 12 principles) 3. Post Why (Guts, Visions ex. time to market)12年11月21日水曜日
  18. 18. Conclusion12年11月21日水曜日
  19. 19. http://newtechusa.net/culture-con/ I’ll share your conclusions later in English. Thank you!12年11月21日水曜日
  20. 20. We thought This is the Agile Programmer’s Skill set Workshop Results in 10 minutes12年11月21日水曜日
  21. 21. Team Golden Circle Rhythm Collective Ownership Repository Coding Standard Team Building Code Review Self Organizing Team PairProgramming Visualization WhiteBoard Refactoring Planning Dairy Meeting Kaizen Burn down Design Working Software Retrospective chart Ceremony Trust & Respect Drink Party War-Room12年11月21日水曜日
  22. 22. Team Door Side Collaboration with customer Collaboration with team members ability to think realization Identify customer’s Power Structure ability to think Listening Skill Vagrant & chef!!!12年11月21日水曜日
  23. 23. Team 7 Understand Business Requirement Embrace Change Design Test Stout heart ability to read someone’s code ambition sincerity Communication Skill coarse grained design architecture12年11月21日水曜日
  24. 24. Team Maid Simple Design mix up the ideas that written in some papers Refactoring Simple Design Test Design Recognize requirement communication Pair Programming Continuous Delivery proposal12年11月21日水曜日
  25. 25. Team Ushio LOVE Ability to embrace change Frequent feedback Keep on something! Test Driven Development Passion Continuous delivery of valuable software Object Oriented Continuous Retrospective Integration Face-to-Face Communication Continuous Delivery UML Common Language or something.. Communication Skill12年11月21日水曜日
  26. 26. Summary12年11月21日水曜日
  27. 27. Summary12年11月21日水曜日
  28. 28. Appendix. Technical element of iCAgile Agile Software Design + Programming every books are referenced by Amazon.co.jp or Amazon.com12年11月21日水曜日
  29. 29. 1. Designing & Programming 1. 設計とプログラミング 1.1. テスト駆動開発 1.1. Test Driven Development 1.1.1. The value of test-driven development 1.1.2. Identifying usage patterns to define the object or function interface 1.1.1. テスト駆動開発の価値 1.1.3. Identifying completeness of conditions that drive usage patterns in the code 1.1.2. オブジェクトや関数のインターフェイスの利用パターンを探し出す 1.1.4. Avoiding duplication in the conditions 1.1.3. コードの中の条件の完全性の利用パターンを探し出す 1.1.5. Red-Green-Refactor 1.1.4. 条件の重複を避ける 1.1.6. Test Speed 1.1.5. レッド、グリーン、リファクタリングパターン 1.1.6. テストのスピード Test Driven Development: By Example Test-Driven iOS Development Growing Object-Oriented Software, Guided by Tests Kent Beck (2002) Graham Lee (2012) Steve Freeman, Nat Pryce (2009) required knowledge12年11月21日水曜日
  30. 30. 1. Designing & Programming Architecture (1.2.1) 1.2. Good Design 1. 設計とプログラミング 1.2. よい設計 Beck’s 4 rules of simple design(1.2.2) McCabe complexity (1.2.2) DRY (1.2.3.) SOLID (1.2.3.) 1.2.1. Role of Design-in-the-Large 1.2.2. Simple design 1.2.3. Evaluating Design and Design Principle 1.2.4. Design Patterns 1.2.1. 大きな設計の役割 1.2.5. Clean Programming 1.2.2. シンプルな設計 1.2.3. 設計の評価と、設計原則 1.2.6. Listening to your tests 1.2.4. デザインパターン 1.2.5. クリーンプログラミング 1.2.6. あなたのテストに聞いてみよう Agile Software Development The Art of Readable Code Robert C. Martin (2011) Dustin Boswell, Trevor Foucher (2011)12年11月21日水曜日
  31. 31. BECKのシンプルデザインの4つのルール 全てのテストがパスしていること continue... 重複が無い事 プログラマの意図が表現されていること クラスとメソッドの数が最小化されていること Beck’s 4 rules of simple design Pass all tests Contains no duplications Express the intent of the programmers Minimizes the number of classes and methods http://theholyjava.wordpress.com/2011/02/14/clean-code-four-simple-design-rules/ Patterns of Enterprise Application Architecture Martin Fowler (2002) SOILD Single responsibility principle Open/Closed Principle Liskov substitution principle Interface segregation principle Dependency Inversion Principle If you want to understand SOLID , Read Agile Software Development!Design Patterns: Elements of 増補改訂版Java言語で学ぶReusable Object-Oriented Software デザインパターン入門 Erich Helm, Richard Johnson,Ralph Vissides, John Gamma(1994) 結城浩(2004) SOLID 単一責任の原則 オープンクローズ原則 リスコフ置換の原則 インターフェイス分離の原則 Pattern-oriented software architecture 依存姓反転の原則 Frank Buschmann, etc (1996)12年11月21日水曜日
  32. 32. continue... もし、オブジェクト指向がわからないなら、これしたら? If you can’t understand OO, try these. Just Enough Software Architecture: A Risk-Driven Approach オブジェクト脳のつくり方 George Fairbanks (2010) 牛尾 剛 (2003) Agile Education by Object Game AGILE2011 session http://enterprisezine.jp/iti/detail/3385?p=212年11月21日水曜日
  33. 33. 1. Designing & Programming 1.3. Technical Debt 1.3. 技術的負債 1.3.1. Recognizing technical debt 1.3.2. Discussing technical debt choices with stakeholders. 1.3.1. 技術的負債を理解する 1.3.2. 技術的負債の選択について利害関係者と議論する12年11月21日水曜日
  34. 34. 1. Designing & Programming DB, HTML refactoring (1.4.4. 1.4. Refactoring 1.4. リファクタリング 1.4.1. リファクタリングの原則 1.4.1. Principles of refactoring 1.4.2. 不吉な香り 1.4.2. Code smells 1.4.3. 一般的なリファクタリング 1.4.3. Common refactorings 1.4.4. 広がるリファクタリングの世界 1.4.4. The larger world of refactoring 1.4.5. リファクタリング(そのもの) 1.4.5. Refactoring Refactoring: Improving the Design of Existing Code Refactoring Workbook Refactoring Databases: Martin Fowler , Kent Beck, John Brant, William C. Wake (2003) Evolutionary Database Design William Opdyke, Don Roberts(1999) Scott W. Ambler (2006)12年11月21日水曜日
  35. 35. テストコードが無い時(1.5.2.) 1. Designing & Programming リファクタリングツールを使う 静的型付け言語の場合   ・エラーをコンパイラが見つけてくれる witout test code (1.5.2.)    レベルに小さなステップに分解する 1.5. Legacy code refactoring tools 動的型付け言語の場合   ・エラーがほとんど起こらない程度の 1.5. レガシーコード statically typed langage    小さなステップに分解する breaking down into steps catch errors with compiler dynamic language 1.5.1. Approaching legacy code breaking down into steps 1.5.2. Refactoring without test which are likely less error 1.5.3. Retrofitting test onto legacy code 1.5.1. レガシーコードへのアプローチ 1.5.2. テストなしでリファクタリングする 1.5.3. レガシーコードにテストをつける 「派生開発」を成功させるプロセス改善の技術と極意 Working Effectively With Legacy Code Michael Feathers (2004) 清水吉男(2007)12年11月21日水曜日
  36. 36. 2. Testing 2.1. Acceptance Testing ユニットテスト(2.1.1.) 2.1. 受入テスト コンポーネントテスト Unit Test (2.1.1.) 受入テスト 2.1.1. Types of tests to automate Component Test 非機能テスト 2.1.2. Test as Specification and Documentation Acceptance Test 2.1.3. ATDD as aid to design thinking non-functional Test 2.1.4. Tester-Business-Developer Collaboration 2.1.5. ATDD Process ATDD 3 different forms (2.1.6.) a text based form ( cucumber) 2.1.6. ATDD Styles & Tools table (FIT) ATDDの3形態(2.1.6) 2.1.7. Testing the system bypassing the user interface in code (xUnit) テキストベース(cucumber) 2.1.8. Testing the system through the user interface テーブル形式(fit) 2.1.9. Cross-functional testing cucumber (2.1.8.) コードに記述(xUnit) 2.1.1. 自動化するテストの種類 2.1.2. 仕様、ドキュメントとしてのテスト Robot Framework 2.1.3. ATDD がデザインシンキングを助ける 2.1.4. テスターとビジネスの人と開発者の non-functional tests(2.1.9.)   コラボレーション capacity 2.1.5. ATDDプロセス response time 2.1.6. ATDDのスタイルとツール security 非機能テスト(2.1.9) 2.1.7. ユーザインターフェイスをバイパスしたテスト etc... キャパシティ 2.1.8. ユーザインターフェイスを介したテスト 応答速度 2.1.9 機能横断テスト セキュリティ ATDD by Example: A Practical Guide to Acceptance Test-Driven Development などなど Markus Gartner (2012)12年11月21日水曜日
  37. 37. 2. Testing 2.2. Programming the tests 2.2. テストをプログラミングする test doubles (2.2.6.) stub 2.2.1. Coding Tests by Intention mocks 2.2.2. Testing the tests fakes 2.2.3. Test execution time spies 2.2.1. プログラマの意図をもったテストコードを書く 2.2.4. Fixture Setup 2.2.2. テストをテストする 2.2.5. Result Verification 2.2.3. テスト実行時間 2.2.6. Use test doubles 2.2.4. フィクスチャのセットアップ 2.2.7. Refactoring Test 2.2.5. 評価の結果 2.2.6. テストダブルを使う(例えばデータベースを直接つかわないでテストする事等) 2.2.7. テストのリファクタリング at least 3 different ways of verifying the test code (2.2.2.) 少なくとも、3つの違った方法でテストコードを確認すること xUnit Test Patterns: Refactoring Test Code Gerard Meszaros (2007)12年11月21日水曜日
  38. 38. 3. Teams and behaviors Class Diagrams (3.1.5.) Sequence Diagram 3.1. Collaboration Instance and Deployment diagrams CRC cards and similar 3.1.1. Collaboration Skills task and kanban board (3.1.6.) 3.1.2. Work allocation story maps 3.1.3. Stakeholder Conversations burn chart 3.1.4. Pair Programming cumulative flow diagrams 3.1.5. Communication design physical and electronic radiators 3.1.6. Information Radiators 3.1.1. コラボレーションスキル 3.1.7. Working spaces 3.1.2. 仕事の割り当て タスクとカンバン(3.1.6) 3.1.8. Distributed teams 3.1.3. 利害関係者との会話 ストーリマッピング バーンチャート 3.1.4. ペアプログラミング 累積フロー図 3.1.5. コミュニケーションを設計する あんどん 3.1.6. あんどんの情報 3.1.7. 作業場所 3.1.8. 分散したチーム UML Distilled: A Brief Guide to the Standard Object Modeling Language Agile Software Development: The Cooperative Game Martin Fowler (2003) Alistair Cockburn (2006)12年11月21日水曜日
  39. 39. 3. Teams and behaviors 3.1. Collaboration コミュニケーションスキル(3.1.1.) アクティブリスニング 共同もしくは個人のファシリテーション オープンな提案と、批判ができること Communication Skills (3.1.1.) 建設的な批判ができること 正直でいることが良い事であるムードを作れる active listening 失敗をしても責められないこと self- or shared facilitation 尊敬しあうこと being open for suggestions & criticisms クリーンであること constructive criticism 自分の意見をいうことhttp://www.wikihow.com/Speak-Up making sefe-to-be-honest 黙っていること safe-to-fail ディベート giving respect (何かをコラボレーションで)生産すること hygiene コミュニケーションスタイルの違いを理解する speaking up staying silent debating yielding recognizing defferent communication styles http://cte.uwaterloo.ca/teaching_resources/tips/teamwork_skills.html12年11月21日水曜日
  40. 40. 3. Teams and behaviors 3.2. Collective accountability 3.2.1. Collective accountability 3.2.2. Collective Ownership 3.2.1. 共同責任 3.2.2. 共同所有 three models (3.2.2.) owner-only any-pair any-one 3.2.2. 共同所有3つのモデル  オーナーのみ  どんなペアでもよい  誰もいい Extreme Programming Explained: Embrace Change Kent Beck (1999)12年11月21日水曜日
  41. 41. 3. Teams and behaviors 3.3. Team activity 3.3.1. Reflection workshops 3.3.1. ふりかえり 3.3.2. Daily meetings 3.3.2. デイリーミーティング Agile Retrospectives: Making Good Teams Great Esther Derby ,Diana Larsen (2006)12年11月21日水曜日
  42. 42. 機能単位(4.1.1.) 主なWBS 4. Structuring Work 粗粒度、中粒度、細粒度の機能の理解の必要性 ユースケース、ストーリマップ MMF (最低限のマーケット化可能な機能)もしくは機能リスト 良い仕事のための統計 4.1. Function-Based Development function units (4.1.1.) Primary work breakdown structure understanding the need for coarse-, 4.1.1. Developing in function units medium-, and fine-grained function 4.1.2. Slicing use case, story maps minimum- 4.1.3. Cross-functional constraints marketable features or feature lists 4.1.4. Technical risk reduction heuristic for good work unit 4.1.1. 機能単位で開発する Risk reduction (4.1.4.) 4.1.2. 分解する spikes 4.1.3. 機能横断的な制約 prototypes 4.1.4. 技術的リスクの軽減 walking skeleton others Writing Effective Use Cases Alistair Cockburn (2000) リスクの軽減(4.1.4.) スパイク プロトタイプ ウォーキングスケルトン(とりあえず一通り度長する小さ User Stories Applied 要求開発 User Story Mapping な実装)http://alistair.cockburn.us/Walking+skeleton Mike Cohn (2004) 山岸耕二他(2006) Jeff Patton (2013) その他12年11月21日水曜日
  43. 43. 4. Structuring Work 4.2. Planning 4.2.1. Sizing 粗い粒度で長期的に、 4.2.2. Planning at different granularities 細粒度で短期的に 計画するのがアジャイルのやり方 4.2.3. Scheduling Risk Mitigation Items 開発側も、ビジネス側も 4.2.1. 見積もり 4.2.4. Sequencing work 4.2.2. 異なるグラニュリティを計画する 4.2.3. リスク軽減アイテムをスケジュールする 4.2.4. 仕事を繰り返す Agile Estimating and Planning Mike Cohn (2005)12年11月21日水曜日
  44. 44. 5. Environment 5.1. Leveraging tools 5.1. ツールを活用する 5.1.1. バージョン管理ツール 5.1.1. Version Control 5.1.2. ビルドツール 5.1.2. Build Tools 5.1.3. 継続的インテグレーション 5.1.3. Continuous Integration 5.1.4. 継続的デリバリ 5.1.4. Continuous Delivery Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Continuous Integration: Improving Software Jez Humble, David Farley (2010) Quality and Reducing Risk Paul M. Duvall, Steve Matyas, Andrew Glover (2007) Pragmatic Guide to Git Travis Swicegood (2010)12年11月21日水曜日
  45. 45. Sorry Japanese only メソッド屋の日記 こんなプログラマはアジャイル出来ますって言ったらアカンやろ http://d.hatena.ne.jp/simplearchitect/20120810/134461541512年11月21日水曜日

×