Ultimate agilisttokyo
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Ultimate agilisttokyo

  • 509 views
Uploaded on

About Agile Programmer's skill sets ...

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.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
509
On Slideshare
509
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
3
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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. 12年11月16日金曜日
  • 3. Think about Definition of Agile Programmer in this session12年11月16日金曜日
  • 4. Agenda Learn about other definitions Discussion Conclusion12年11月16日金曜日
  • 5. Learn about other definitions12年11月16日金曜日
  • 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_development12年11月16日金曜日
  • 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. Analyze it12年11月16日金曜日
  • 9. XP practices http://ullizee.wordpress.com/2009/11/02/extreme-programming-revisited-part-i/12年11月16日金曜日
  • 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. 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. 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 http://www.icagile.com/index.html12年11月16日金曜日
  • 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. five objectives and practices Five Objectives Practices Agile Programmer’s mandatory skill Map12年11月16日金曜日
  • 15. Discussion12年11月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. Conclusion12年11月16日金曜日
  • 18. http://newtechusa.net/culture-con/ I’ll share your conclusions later in English. Thank you!12年11月16日金曜日
  • 19. Appendix. Technical element of iCAgile Agile Software Design + Programming every books are referenced by Amazon.co.jp or Amazon.com12年11月16日金曜日
  • 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. 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. 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) Pattern-oriented software architecture Frank Buschmann, etc (1996)12年11月16日金曜日
  • 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 http://enterprisezine.jp/iti/detail/3385?p=212年11月16日金曜日
  • 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. 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. 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. 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. 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. 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. 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 http://cte.uwaterloo.ca/teaching_resources/tips/teamwork_skills.html12年11月16日金曜日
  • 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. 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. 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. 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. 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. Sorry Japanese only メソッド屋の日記 こんなプログラマはアジャイル出来ますって言ったらアカンやろ http://d.hatena.ne.jp/simplearchitect/20120810/134461541512年11月16日金曜日