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.

How to be an agile programmer.


Published on

This slide is for Ultimate Agilist Tokyo in Japan. 2012.Nov.

I want to think about agile programmer's skill set. and I want to introduce ICAgile to Japan.

I analyzed agile value, principles, practices and ICAgile.
and participant members created some mandatory skill set in this session.

See this blog entry , that will be better.

  • Be the first to comment

How to be an agile programmer.

  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月18日日曜日
  2. 2. 12年11月18日日曜日
  3. 3. Think about Definition of Agile Programmer in this session12年11月18日日曜日
  4. 4. Agenda Learn about other definitions Discussion Conclusion12年11月18日日曜日
  5. 5. Learn about other definitions12年11月18日日曜日
  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月18日日曜日
  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月18日日曜日
  8. 8. Analyze it12年11月18日日曜日
  9. 9. XP practices年11月18日日曜日
  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月18日日曜日
  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月18日日曜日
  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月18日日曜日
  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月18日日曜日
  14. 14. five objectives and practices Five Objectives Practices Agile Programmer’s mandatory skill Map12年11月18日日曜日
  15. 15. Please get documents from http://simple-architect.blogspot.jp12年11月18日日曜日
  16. 16. Discussion12年11月18日日曜日
  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月18日日曜日
  18. 18. Conclusion12年11月18日日曜日
  19. 19. I’ll share your conclusions later in English. Thank you!12年11月18日日曜日
  20. 20. We thought This is the Agile Programmer’s Skill set Workshop Results in 10 minutes12年11月18日日曜日
  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月18日日曜日
  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月18日日曜日
  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月18日日曜日
  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月18日日曜日
  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月18日日曜日
  26. 26. Summary12年11月18日日曜日
  27. 27. Summary12年11月18日日曜日
  28. 28. Appendix. Technical element of iCAgile Agile Software Design + Programming every books are referenced by or Amazon.com12年11月18日日曜日
  29. 29. 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月18日日曜日
  30. 30. 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月18日日曜日
  31. 31. 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月18日日曜日
  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年11月18日日曜日
  33. 33. 1. Designing & Programming 1.3. Technical Debt 1.3.1. Recognizing technical debt 1.3.2. Discussing technical debt choices with stakeholders.12年11月18日日曜日
  34. 34. 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月18日日曜日
  35. 35. 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月18日日曜日
  36. 36. 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月18日日曜日
  37. 37. 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 at least 3 different ways of verifying the test code (2.2.2.) xUnit Test Patterns: Refactoring Test Code Gerard Meszaros (2007)12年11月18日日曜日
  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.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月18日日曜日
  39. 39. 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月18日日曜日
  40. 40. 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月18日日曜日
  41. 41. 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月18日日曜日
  42. 42. 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月18日日曜日
  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.4. Sequencing work Agile Estimating and Planning Mike Cohn (2005)12年11月18日日曜日
  44. 44. 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月18日日曜日
  45. 45. Sorry Japanese only メソッド屋の日記 こんなプログラマはアジャイル出来ますって言ったらアカンやろ年11月18日日曜日