Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Ultimate agilisttokyo


Published on

About Agile Programmer's skill sets

Ultimate Agilist Tokyo 2012

This presentation will be used tomorrow. after that session I have a plan to update this slide.

  • Be the first to comment

Ultimate agilisttokyo

  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月16日金曜日
  2. 2. 12年11月16日金曜日
  3. 3. Think about Definition of Agile Programmer in this session12年11月16日金曜日
  4. 4. Agenda Learn about other definitions Discussion Conclusion12年11月16日金曜日
  5. 5. Learn about other definitions12年11月16日金曜日
  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年11月16日金曜日
  7. 7. 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月16日金曜日
  8. 8. Analyze it12年11月16日金曜日
  9. 9. XP practices年11月16日金曜日
  10. 10. five objectives for agile programmer 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 principles12年11月16日金曜日
  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.org12年11月16日金曜日
  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. Fundamentals of Agile Agile Business Analysis +Value Management Agile Project Management Agile Facilitation + Coaching Agile Software Design + Programming Agile Testing年11月16日金曜日
  13. 13. Learning Areas Agile Software Design +Programming 1.1. Test Driven Development 1.2. Good Design 1. Designing & Programming 1.3. Technical Debt 1.4. Refactoring 1.5. Legacy Code 2.1. Acceptance Test 2. Testing 2.2. Programming the test 3.1. Collaboration 3. Teams and Behaviors 3.2. Collective Accountability 3.3. Team Activity 4.1. Function-Based Development 4. Structuring Work 4.2. Planning 5. Environment 5.1. Leveraging Tools12年11月16日金曜日
  14. 14. five objectives and practices Five Objectives Practices Agile Programmer’s mandatory skill Map12年11月16日金曜日
  15. 15. Discussion12年11月16日金曜日
  16. 16. 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 Why time to market(ex) How How 12 principles has practices What priactices What 1. Post What (Practice ex. TDD) is dynamic organic 2. Post How (Principles ex 12 principles) 3. Post Why (Guts, Visions ex. time to market) Agile programmer can choice from 12 principles for Why. and can realize how by what. Think about Why for this session (Tsuyoshi)12年11月16日金曜日
  17. 17. Conclusion12年11月16日金曜日
  18. 18. I’ll share your conclusions later in English. Thank you!12年11月16日金曜日
  19. 19. Appendix. Technical element of iCAgile Agile Software Design + Programming every books are referenced by or Amazon.com12年11月16日金曜日
  20. 20. 1. Designing & Programming 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.3. Identifying completeness of conditions that drive usage patterns in the code 1.1.4. Avoiding duplication in the conditions 1.1.5. Red-Green-Refactor 1.1.6. Test Speed 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月16日金曜日
  21. 21. 1. Designing & Programming Architecture (1.2.1) 1.2. Good Design 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.5. Clean Programming 1.2.6. Listening to your tests Agile Software Development The Art of Readable Code Robert C. Martin (2011) Dustin Boswell, Trevor Foucher (2011)12年11月16日金曜日
  22. 22. 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 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) Pattern-oriented software architecture Frank Buschmann, etc (1996)12年11月16日金曜日
  23. 23. 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年11月16日金曜日
  24. 24. 1. Designing & Programming 1.3. Technical Debt 1.3.1. Recognizing technical debt 1.3.2. Discussing technical debt choices with stakeholders.12年11月16日金曜日
  25. 25. 1. Designing & Programming DB, HTML refactoring (1.4.4. 1.4. Refactoring 1.4.1. Principles of refactoring 1.4.2. Code smells 1.4.3. Common refactorings 1.4.4. The larger world of refactoring 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月16日金曜日
  26. 26. 1. Designing & Programming witout test code (1.5.2.) 1.5. Legacy code refactoring tools 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 「派生開発」を成功させるプロセス改善の技術と極意 Working Effectively With Legacy Code Michael Feathers (2004) 清水吉男(2007)12年11月16日金曜日
  27. 27. 2. Testing 2.1. Acceptance Testing 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) 2.1.7. Testing the system bypassing the user interface in code (xUnit) 2.1.8. Testing the system through the user interface 2.1.9. Cross-functional testing cucumber (2.1.8.) Robot Framework non-functional tests(2.1.9.) capacity response time security etc... ATDD by Example: A Practical Guide to Acceptance Test-Driven Development Markus Gartner (2012)12年11月16日金曜日
  28. 28. 2. Testing 2.2. Programming the tests 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.4. Fixture Setup 2.2.5. Result Verification 2.2.6. Use test doubles 2.2.7. Refactoring Test xUnit Test patterns at least 3 different ways of verifying the test code (2.2.2.) xUnit Test Patterns: Refactoring Test Code Gerard Meszaros (2007)12年11月16日金曜日
  29. 29. 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.7. Working spaces 3.1.8. Distributed teams 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月16日金曜日
  30. 30. 3. Teams and behaviors 3.1. Collaboration Communication Skills (3.1.1.) active listening self- or shared facilitation being open for suggestions & criticisms constructive criticism making sefe-to-be-honest safe-to-fail giving respect hygiene speaking up staying silent debating yielding recognizing defferent communication styles年11月16日金曜日
  31. 31. 3. Teams and behaviors 3.2. Collective accountability 3.2.1. Collective accountability 3.2.2. Collective Ownership three models (3.2.2.) owner-only any-pair any-one Extreme Programming Explained: Embrace Change Kent Beck (1999)12年11月16日金曜日
  32. 32. 3. Teams and behaviors 3.3. Team activity 3.3.1. Reflection workshops 3.3.2. Daily meetings Agile Retrospectives: Making Good Teams Great Esther Derby ,Diana Larsen (2006)12年11月16日金曜日
  33. 33. 4. Structuring Work 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 Risk reduction (4.1.4.) spikes prototypes walking skeleton others Writing Effective Use Cases Alistair Cockburn (2000) User Stories Applied 要求開発 User Story Mapping Mike Cohn (2004) 山岸耕二他(2006) Jeff Patton (2013)12年11月16日金曜日
  34. 34. 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.4. Sequencing work Agile Estimating and Planning Mike Cohn (2005)12年11月16日金曜日
  35. 35. 5. Environment 5.1. Leveraging tools 5.1.1. Version Control 5.1.2. Build Tools 5.1.3. Continuous Integration 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月16日金曜日
  36. 36. Sorry Japanese only メソッド屋の日記 こんなプログラマはアジャイル出来ますって言ったらアカンやろ年11月16日金曜日