Ultimate agilisttokyo

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

Think about

Deﬁnition of Agile Programmer

in this session


Agenda

Learn about other deﬁnitions

Discussion

Conclusion


Learn about
other
definitions


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 ﬂexible 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


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.

Analyze it


XP practices

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


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


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


ICAgile
ICAgile exists to support education in the agile space.
Use ICAgile’s deﬁnitive learning roadmap to ﬁnd 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


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


five objectives and
practices
Five Objectives

Practices

Agile Programmer’s mandatory skill Map

Discussion


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)


Conclusion


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

I’ll share your conclusions later in English.
Thank you!


Appendix.
Technical element
of
iCAgile
Agile Software Design +
Programming
every books are referenced by Amazon.co.jp or Amazon.com

1. Designing & Programming
1.1. Test Driven Development

1.1.1. The value of test-driven development
1.1.2. Identifying usage patterns to deﬁne 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

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)


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)

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


1.3. Technical Debt

1.3.1. Recognizing technical debt
1.3.2. Discussing technical debt choices with stakeholders.


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)


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. Retroﬁtting test onto legacy code

「派生開発」を成功させるプロセス改善の技術と極意
Working Effectively With Legacy Code
Michael Feathers (2004) 清水吉男(2007)


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 Speciﬁcation 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)

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 Veriﬁcation
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)


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)


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


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)


3.3. Team activity

3.3.1. Reﬂection workshops
3.3.2. Daily meetings

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


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)


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)


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)


Sorry Japanese only
メソッド屋の日記

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

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


Ultimate agilisttokyo

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (11)

Similaire à Ultimate agilisttokyo

Similaire à Ultimate agilisttokyo (20)

Plus de Tsuyoshi Ushio

Plus de Tsuyoshi Ushio (17)

Ultimate agilisttokyo