ultimate agilisttokyo

36
How to be an Agile Programmer Tsuyoshi Ushio Ultimate Agilist Tokyo Nov 17, 2012 121116日金曜日

Upload: tsuyoshi-ushio

Post on 20-Aug-2015

334 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Ultimate agilisttokyo

How to be an Agile Programmer

T s u y o s h i U s h i o

Ultimate Agilist TokyoNov 17, 2012

12年11月16日金曜日

Page 2: Ultimate agilisttokyo

12年11月16日金曜日

Page 3: Ultimate agilisttokyo

Definition of Agile Programmer

Think about

in this session

12年11月16日金曜日

Page 4: Ultimate agilisttokyo

Agenda

Learn about other definitions

Discussion

Conclusion

12年11月16日金曜日

Page 5: Ultimate agilisttokyo

Learn aboutother

definitions

12年11月16日金曜日

Page 6: Ultimate agilisttokyo

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.

http://en.wikipedia.org/wiki/Agile_software_developmentWIKIPEDIA

12年11月16日金曜日

Page 7: Ultimate agilisttokyo

Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Value Principle1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

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.

5. Build projects around motivated individuals. Give them the environment 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.

7. Working software is the primary measure of progress.

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.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

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日金曜日

Page 8: Ultimate agilisttokyo

Analyze it

12年11月16日金曜日

Page 9: Ultimate agilisttokyo

XP practices

http://ullizee.wordpress.com/2009/11/02/extreme-programming-revisited-part-i/

12年11月16日金曜日

Page 10: Ultimate agilisttokyo

five objectives for agile programmer

Continuous Delivery of valuable softwareEmbrace change

Deliver Working Software frequentlyContinuous attention to Technical Excellence and Good DesignCreate the best architecture, requirements and design emerge

form Self-Organization-Team

Programmer related Agile Manifesto 12 principles

12年11月16日金曜日

Page 11: Ultimate agilisttokyo

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月16日金曜日

Page 12: Ultimate agilisttokyo

ICAgileICAgile 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月16日金曜日

Page 13: Ultimate agilisttokyo

Learning Areas

1. Designing & Programming

1.1. Test Driven Development

1. Designing & Programming1.2. Good Design

1. Designing & Programming 1.3. Technical Debt1. Designing & Programming1.4. Refactoring

1. Designing & Programming

1.5. Legacy Code

2. Testing2.1. Acceptance Test

2. Testing2.2. Programming the test

3. Teams and Behaviors3.1. Collaboration

3. Teams and Behaviors 3.2. Collective Accountability3. Teams and Behaviors3.3. Team Activity

4. Structuring Work4.1. Function-Based Development

4. Structuring Work4.2. Planning

5. Environment 5.1. Leveraging Tools

Agile Software Design +Programming

12年11月16日金曜日

Page 14: Ultimate agilisttokyo

five objectives andpractices

Agile Programmer’s mandatory skill Map

Five Objectives

Practices

12年11月16日金曜日

Page 15: Ultimate agilisttokyo

Discussion

12年11月16日金曜日

Page 16: Ultimate agilisttokyo

Golden CircleWhy is Vision

is our gut has emotion and heart create something bigger then your self

How is Mission

brings up guiding principle

What is Rules

has practices is dynamic organic

Why

How

What

Why time to market(ex)How 12 principlesWhat priactices

1. Post What (Practice ex. TDD)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日金曜日

Page 17: Ultimate agilisttokyo

Conclusion

12年11月16日金曜日

Page 18: Ultimate agilisttokyo

I’ll share your conclusions later in English.

Thank you!

http://newtechusa.net/culture-con/

12年11月16日金曜日

Page 19: Ultimate agilisttokyo

Appendix.Technical element

ofiCAgile

Agile Software Design + Programming

every books are referenced by Amazon.co.jp or Amazon.com12年11月16日金曜日

Page 20: Ultimate agilisttokyo

1.1. Test Driven Development

1.1.1. The value of test-driven development1.1.2. Identifying usage patterns to define the object or function interface1.1.3. Identifying completeness of conditions that drive usage patterns in the code1.1.4. Avoiding duplication in the conditions1.1.5. Red-Green-Refactor1.1.6. Test Speed

1. Designing & Programming

Test Driven Development: By ExampleKent Beck (2002)

Test-Driven iOS DevelopmentGraham Lee (2012)

required knowledge

Growing Object-Oriented Software, Guided by TestsSteve Freeman, Nat Pryce (2009)

12年11月16日金曜日

Page 21: Ultimate agilisttokyo

1.2. Good Design

1.2.1. Role of Design-in-the-Large1.2.2. Simple design1.2.3. Evaluating Design and Design Principle1.2.4. Design Patterns1.2.5. Clean Programming1.2.6. Listening to your tests

1. Designing & ProgrammingArchitecture (1.2.1)Beck’s 4 rules of simple design(1.2.2)McCabe complexity (1.2.2)DRY (1.2.3.)SOLID (1.2.3.)

Agile Software DevelopmentRobert C. Martin (2011)

The Art of Readable CodeDustin Boswell, Trevor Foucher (2011)

12年11月16日金曜日

Page 22: Ultimate agilisttokyo

continue...Beck’s 4 rules of simple designPass all testsContains no duplicationsExpress the intent of the programmersMinimizes the number of classes and methods

http://theholyjava.wordpress.com/2011/02/14/clean-code-four-simple-design-rules/

SOILDSingle responsibility principleOpen/Closed PrincipleLiskov substitution principleInterface segregation principleDependency Inversion Principle

If you want to understand SOLID , Read Agile Software Development!

Design Patterns: Elements of Reusable Object-Oriented SoftwareErich Helm, Richard Johnson, Ralph Vissides, John Gamma(1994)

Patterns of Enterprise Application Architecture Martin Fowler (2002)

Pattern-oriented software architecture Frank Buschmann, etc (1996)

増補改訂版Java言語で学ぶデザインパターン入門 結城浩(2004)

12年11月16日金曜日

Page 23: Ultimate agilisttokyo

continue...

Just Enough Software Architecture: A Risk-Driven ApproachGeorge Fairbanks (2010)

オブジェクト脳のつくり方牛尾 剛 (2003)

Agile Education by Object GameAGILE2011 session

http://enterprisezine.jp/iti/detail/3385?p=2

If you can’t understand OO, try these.

12年11月16日金曜日

Page 24: Ultimate agilisttokyo

1.3. Technical Debt

1.3.1. Recognizing technical debt1.3.2. Discussing technical debt choices with stakeholders.

1. Designing & Programming

12年11月16日金曜日

Page 25: Ultimate agilisttokyo

1.4. Refactoring

1.4.1. Principles of refactoring1.4.2. Code smells1.4.3. Common refactorings1.4.4. The larger world of refactoring1.4.5. Refactoring

1. Designing & ProgrammingDB, HTML refactoring (1.4.4.

Refactoring Databases: Evolutionary Database DesignScott W. Ambler (2006)

Refactoring: Improving the Design of Existing CodeMartin Fowler , Kent Beck, John Brant, William Opdyke, Don Roberts(1999)

Refactoring WorkbookWilliam C. Wake (2003)

12年11月16日金曜日

Page 26: Ultimate agilisttokyo

1.5. Legacy code

1.5.1. Approaching legacy code1.5.2. Refactoring without test1.5.3. Retrofitting test onto legacy code

1. Designing & Programming

Working Effectively With Legacy CodeMichael Feathers (2004)

「派生開発」を成功させるプロセス改善の技術と極意清水吉男(2007)

witout test code (1.5.2.)refactoring toolsstatically typed langage breaking down into steps catch errors with compilerdynamic language breaking down into steps which are likely less error

12年11月16日金曜日

Page 27: Ultimate agilisttokyo

2.1. Acceptance Testing

2.1.1. Types of tests to automate2.1.2. Test as Specification and Documentation2.1.3. ATDD as aid to design thinking2.1.4. Tester-Business-Developer Collaboration2.1.5. ATDD Process2.1.6. ATDD Styles & Tools2.1.7. Testing the system bypassing the user interface2.1.8. Testing the system through the user interface2.1.9. Cross-functional testing

2. Testing

Unit Test (2.1.1.) Component TestAcceptance Testnon-functional Test

non-functional tests(2.1.9.)capacity response timesecurity etc...

ATDD 3 different forms (2.1.6.)a text based form ( cucumber)table (FIT)in code (xUnit)

cucumber (2.1.8.)Robot Framework

ATDD by Example: A Practical Guide to Acceptance Test-Driven DevelopmentMarkus Gartner (2012)

12年11月16日金曜日

Page 28: Ultimate agilisttokyo

2.2. Programming the tests

2.2.1. Coding Tests by Intention2.2.2. Testing the tests2.2.3. Test execution time2.2.4. Fixture Setup2.2.5. Result Verification 2.2.6. Use test doubles2.2.7. Refactoring Test

2. Testing

test doubles (2.2.6.)stubmocksfakesspies

at least 3 different ways of verifying the test code (2.2.2.)

xUnit Test patterns

xUnit Test Patterns: Refactoring Test CodeGerard Meszaros (2007)

12年11月16日金曜日

Page 29: Ultimate agilisttokyo

3.1. Collaboration3.1.1. Collaboration Skills3.1.2. Work allocation3.1.3. Stakeholder Conversations3.1.4. Pair Programming3.1.5. Communication design3.1.6. Information Radiators3.1.7. Working spaces3.1.8. Distributed teams

3. Teams and behaviors Class Diagrams (3.1.5.)Sequence DiagramInstance and Deployment diagramsCRC cards and similartask and kanban board (3.1.6.)story mapsburn chartcumulative flow diagramsphysical and electronic radiators

Agile Software Development: The Cooperative GameAlistair Cockburn (2006)

UML Distilled: A Brief Guide to the Standard Object Modeling LanguageMartin Fowler (2003)

12年11月16日金曜日

Page 30: Ultimate agilisttokyo

3.1. Collaboration

3. Teams and behaviors

Communication Skills (3.1.1.)active listeningself- or shared facilitationbeing open for suggestions & criticismsconstructive criticismmaking sefe-to-be-honestsafe-to-failgiving respecthygienespeaking upstaying silentdebatingyieldingrecognizing defferent communication styles

http://cte.uwaterloo.ca/teaching_resources/tips/teamwork_skills.html

12年11月16日金曜日

Page 31: Ultimate agilisttokyo

3.2. Collective accountability

3.2.1. Collective accountability3.2.2. Collective Ownership

3. Teams and behaviors

three models (3.2.2.)owner-onlyany-pairany-one

Extreme Programming Explained: Embrace ChangeKent Beck (1999)

12年11月16日金曜日

Page 32: Ultimate agilisttokyo

3.3. Team activity

3.3.1. Reflection workshops3.3.2. Daily meetings

3. Teams and behaviors

Agile Retrospectives: Making Good Teams GreatEsther Derby ,Diana Larsen (2006)

12年11月16日金曜日

Page 33: Ultimate agilisttokyo

4.1. Function-Based Development

4.1.1. Developing in function units4.1.2. Slicing4.1.3. Cross-functional constraints4.1.4. Technical risk reduction

4. Structuring Work

Risk reduction (4.1.4.)spikesprototypeswalking skeletonothers

function units (4.1.1.)Primary work breakdown structureunderstanding the need for coarse-, medium-, and fine-grained functionuse case, story maps minimum-marketable features or feature listsheuristic for good work unit

Writing Effective Use CasesAlistair Cockburn (2000)

User Story MappingJeff Patton (2013)

User Stories AppliedMike Cohn (2004)

要求開発山岸耕二他(2006)

12年11月16日金曜日

Page 34: Ultimate agilisttokyo

4.2. Planning

4.2.1. Sizing4.2.2. Planning at different granularities4.2.3. Scheduling Risk Mitigation Items4.2.4. Sequencing work

4. Structuring Work

Agile Estimating and PlanningMike Cohn (2005)

12年11月16日金曜日

Page 35: Ultimate agilisttokyo

5.1. Leveraging tools

5.1.1. Version Control5.1.2. Build Tools5.1.3. Continuous Integration5.1.4. Continuous Delivery

5. Environment

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment AutomationJez Humble, David Farley (2010)

Continuous Integration: Improving Software Quality and Reducing RiskPaul M. Duvall, Steve Matyas, Andrew Glover (2007)

Pragmatic Guide to GitTravis Swicegood (2010)

12年11月16日金曜日

Page 36: Ultimate agilisttokyo

http://d.hatena.ne.jp/simplearchitect/20120810/1344615415

メソッド屋の日記

こんなプログラマはアジャイル出来ますって言ったらアカンやろ

Sorry Japanese only

12年11月16日金曜日