How to be an agile programmer

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月18日日曜日


Definition of Agile Programmer

Think about

in this session


Agenda

Learn about other definitions

Discussion

Conclusion


Learn aboutother

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


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

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

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.


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


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




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


http://www.icagile.com/index.html

http://www.icagile.com/index.html

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.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


five objectives andpractices

Agile Programmer’s mandatory skill Map

Five Objectives

Practices


http://simple-architect.blogspot.jpPlease get documents from


http://simple-architect.blogspot.jp

http://simple-architect.blogspot.jp

Discussion


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 principles12年11月18日日曜日

Conclusion


I’ll share your conclusions later in English.

Thank you!

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




We thoughtThis is the

Agile Programmer’sSkill set

Workshop Results in 10 minutes


Team Golden Circle

Collective Ownership

Team Building

Self Organizing Team

Visualization

Kaizen

Working Software

Trust & Respect

Rhythm

Coding Standard

CodeReview

WhiteBoard Refactoring Planning

Burn downchart Retrospective

Repository

PairProgramming

Design

War-Room

Dairy Meeting

CeremonyDrink Party


Team Door Side

Collaboration with customerCollaboration with team members

Identify customer’sPower Structure

Listening Skill

ability to think

ability to think realization

Vagrant &chef!!!


Team 7

Design Test

ability to read someone’s code

coarse grained designarchitecture

UnderstandBusiness Requirement

Communication Skill

Embrace Change

Stout heart

ambitionsincerity


Team Maid

Recognize requirement

communication

proposal

Continuous Delivery

Pair Programming

Design Test

SimpleRefactoring

Design

mix up the ideas that written in some papers

Simple Design


Team Ushio LOVE

embrace change

Test Driven Development

Frequent feedback

Continuous delivery of valuable software

Continuous Integration

Continuous Delivery

Object Oriented

Retrospective

Passion

Face-to-Face Communication

UMLCommon Language or something..

Communication Skill

Ability to Keep on something!


Summary


Summary


Appendix.Technical element

ofiCAgile

Agile Software Design + Programming

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

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


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)


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)


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)




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.




1.3. Technical Debt

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



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)


1.5. Legacy code

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


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


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)


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: Refactoring Test CodeGerard Meszaros (2007)


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)


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




3.2. Collective accountability

3.2.1. Collective accountability3.2.2. Collective Ownership


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

Extreme Programming Explained: Embrace ChangeKent Beck (1999)


3.3. Team activity

3.3.1. Reflection workshops3.3.2. Daily meetings


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


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)


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)


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)


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

メソッド屋の日記

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

Sorry Japanese only




Documents

How to be an agile programmer