Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

How to be an agile programmer.

•
•
Tsuyoshi Ushio
Tsuyoshi Ushio

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. http://simple-architect.blogspot.jp/2012/11/agile-programmers-skill-set-ultimate.html

1 of 45
Ultimate Agilist Tokyo Nov 17, 2012 How to be an Agile Programmer T s u y o s h i U s h i o 12年11月18日日曜日
12年11月18日日曜日
Think about Definition of Agile Programmer in this session 12年11月18日日曜日
Agenda Learn about other definitions Discussion Conclusion 12年11月18日日曜日
Learn about other definitions 12年11月18日日曜日
What is Agile Development? Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. The Agile Manifesto[1] introduced the term in 2001. WIKIPEDIA http://en.wikipedia.org/wiki/Agile_software_development 12年11月18日日曜日
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 customer's 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日日曜日
Analyze it 12年11月18日日曜日
XP practices http://ullizee.wordpress.com/2009/11/02/extreme-programming-revisited-part-i/ 12年11月18日日曜日
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 principles 12年11月18日日曜日
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月18日日曜日
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.html 12年11月18日日曜日
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 Tools 12年11月18日日曜日
five objectives and practices Five Objectives Practices Agile Programmer’s mandatory skill Map 12年11月18日日曜日
Please get documents from http://simple-architect.blogspot.jp 12年11月18日日曜日
Discussion 12年11月18日日曜日
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日日曜日
Conclusion 12年11月18日日曜日
http://newtechusa.net/culture-con/ I’ll share your conclusions later in English. Thank you! 12年11月18日日曜日
We thought This is the Agile Programmer’s Skill set Workshop Results in 10 minutes 12年11月18日日曜日
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-Room 12年11月18日日曜日
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日日曜日
Team 7 Understand Business Requirement Embrace Change Design Test Stout heart ability to read someone’s code ambition sincerity Communication Skill coarse grained design architecture 12年11月18日日曜日
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 proposal 12年11月18日日曜日
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 Skill 12年11月18日日曜日
Summary 12年11月18日日曜日
Summary 12年11月18日日曜日
Appendix. Technical element of iCAgile Agile Software Design + Programming every books are referenced by Amazon.co.jp or Amazon.com 12年11月18日日曜日
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 knowledge 12年11月18日日曜日
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日日曜日
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月18日日曜日
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=2 12年11月18日日曜日
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日日曜日
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日日曜日
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日日曜日
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日日曜日
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日日曜日
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日日曜日
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.html 12年11月18日日曜日
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日日曜日
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日日曜日
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日日曜日
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日日曜日
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日日曜日
Sorry Japanese only メソッド屋の日記 こんなプログラマはアジャイル出来ますって言ったらアカンやろ http://d.hatena.ne.jp/simplearchitect/20120810/1344615415 12年11月18日日曜日

More Related Content

How to be an agile programmer.

  • 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 o 12年11月18日日曜日
  • 3. Think about Definition of Agile Programmer in this session 12年11月18日日曜日
  • 4. Agenda Learn about other definitions Discussion Conclusion 12年11月18日日曜日
  • 5. Learn about other definitions 12年11月18日日曜日
  • 6. What is Agile Development? Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle. The Agile Manifesto[1] introduced the term in 2001. WIKIPEDIA http://en.wikipedia.org/wiki/Agile_software_development 12年11月18日日曜日
  • 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 customer's 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日日曜日
  • 9. XP practices http://ullizee.wordpress.com/2009/11/02/extreme-programming-revisited-part-i/ 12年11月18日日曜日
  • 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 principles 12年11月18日日曜日
  • 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月18日日曜日
  • 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.html 12年11月18日日曜日
  • 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 Tools 12年11月18日日曜日
  • 14. five objectives and practices Five Objectives Practices Agile Programmer’s mandatory skill Map 12年11月18日日曜日
  • 15. Please get documents from http://simple-architect.blogspot.jp 12年11月18日日曜日
  • 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日日曜日
  • 19. http://newtechusa.net/culture-con/ I’ll share your conclusions later in English. Thank you! 12年11月18日日曜日
  • 20. We thought This is the Agile Programmer’s Skill set Workshop Results in 10 minutes 12年11月18日日曜日
  • 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-Room 12年11月18日日曜日
  • 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. Team 7 Understand Business Requirement Embrace Change Design Test Stout heart ability to read someone’s code ambition sincerity Communication Skill coarse grained design architecture 12年11月18日日曜日
  • 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 proposal 12年11月18日日曜日
  • 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 Skill 12年11月18日日曜日
  • 28. Appendix. Technical element of iCAgile Agile Software Design + Programming every books are referenced by Amazon.co.jp or Amazon.com 12年11月18日日曜日
  • 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 knowledge 12年11月18日日曜日
  • 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. 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月18日日曜日
  • 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=2 12年11月18日日曜日
  • 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. 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. 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. 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. 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. 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. 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.html 12年11月18日日曜日
  • 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. 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. 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. 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. 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. Sorry Japanese only メソッド屋の日記 こんなプログラマはアジャイル出来ますって言ったらアカンやろ http://d.hatena.ne.jp/simplearchitect/20120810/1344615415 12年11月18日日曜日