Ultimate agilisttokyo(japanese)

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月21日水曜日


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

アジャイルソフトウェア宣言でGoogleすると、日本語の定義が出てきます！

http://agilemanifesto.org/iso/ja/


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.

アジャイルソフトウェア宣言でGoogleすると、日本語の定義が出てきます！http://agilemanifesto.org/iso/ja/principles.html


http://agilemanifesto.org/iso/ja/principles.html

http://agilemanifesto.org/iso/ja/principles.html

Analyze itごめん、これは勘弁して

ただし、ブログにこれの後さらに分析して日本語化したTreeあり

https://s3-ap-northeast-1.amazonaws.com/ultimateagilisttokyoupload/アジャイルプログラマのスキルマップ.png


https://s3-ap-northeast-1.amazonaws.com/ultimateagilisttokyoupload/


XP practices

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

XPのプラクティス




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ソフトウェア職人宣言動作するソフトウェアだけではなく、しっかり作られたソフトウェアを変化に対応するだけではなく、着実に価値を付加していくことを

個人と相互作用だけでなく、プロフェッショナルたちのコミュニティを顧客との強調だけでなく、生産的なパートナーシップを


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

ICAgileは、アジャイル分野に関する教育を助けるために存在しますICAgileの定義されたロードマップをつかうことで、公式なコースを見つける事ができます進路に応じて、生徒がどのように成長していけばいいか、理解することができます

アジャイルの基本

ビジネスアナリシスとバリューマネジメント

アジャイルプロジェクトマネジメント

アジャイルファシリテーションとコーチング

アジャイルソフトウェア設計とプログラミング

アジャイルテスト


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

設計とプログラミング

テスト

チームと振る舞い

作業を構造化する

環境

1.1. テスト駆動開発1.2. よい設計

1.3. 技術的負債1.4. リファクタリング1.5. レガシーコード

2.1. 受入テスト2.2. テストのプログラミング

3.1. コラボレーション3.2. 共同責任

3.3. チームアクティビティ

4.1. 機能ベース開発4.2. プランニング

5.1. ツールを活用する


five objectives andpractices

Agile Programmer’s mandatory skill Map

Five Objectives

Practices

日本語版https://s3-ap-northeast-1.amazonaws.com/ultimateagilisttokyoupload/アジャイルプログラマのスキルマップ.png






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

日本語版http://d.hatena.ne.jp/simplearchitect/20121117/1353181189


http://simple-architect.blogspot.jp

http://simple-architect.blogspot.jp

http://d.hatena.ne.jp/simplearchitect/20121117/1353181189




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月21日水曜日

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月21日水曜日

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. 設計とプログラミング1.1. テスト駆動開発

1.1.1. テスト駆動開発の価値1.1.2. オブジェクトや関数のインターフェイスの利用パターンを探し出す

1.1.3. コードの中の条件の完全性の利用パターンを探し出す1.1.4. 条件の重複を避ける

1.1.5. レッド、グリーン、リファクタリングパターン1.1.6. テストのスピード


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)

1.2.1. 大きな設計の役割1.2.2. シンプルな設計

1.2.3. 設計の評価と、設計原則1.2.4. デザインパターン

1.2.5. クリーンプログラミング1.2.6. あなたのテストに聞いてみよう

1. 設計とプログラミング1.2. よい設計


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)

BECKのシンプルデザインの４つのルール全てのテストがパスしていること

重複が無い事プログラマの意図が表現されていること

クラスとメソッドの数が最小化されていること

SOLID単一責任の原則

オープンクローズ原則リスコフ置換の原則

インターフェイス分離の原則依存姓反転の原則




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. Designing & Programming1.3. 技術的負債

1.3.1. 技術的負債を理解する1.3.2. 技術的負債の選択について利害関係者と議論する


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.4. リファクタリング

1.4.1. リファクタリングの原則1.4.2. 不吉な香り

1.4.3. 一般的なリファクタリング1.4.4. 広がるリファクタリングの世界1.4.5. リファクタリング（そのもの）


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

1.5. レガシーコード

1.5.1. レガシーコードへのアプローチ1.5.2. テストなしでリファクタリングする1.5.3. レガシーコードにテストをつける

テストコードが無い時（1.5.2.)

リファクタリングツールを使う静的型付け言語の場合　　・エラーをコンパイラが見つけてくれる　　　レベルに小さなステップに分解する動的型付け言語の場合　　・エラーがほとんど起こらない程度の　　　小さなステップに分解する


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.1. 受入テスト

2.1.1. 自動化するテストの種類2.1.2. 仕様、ドキュメントとしてのテスト2.1.3. ATDD がデザインシンキングを助ける2.1.4. テスターとビジネスの人と開発者の　　コラボレーション2.1.5. ATDDプロセス2.1.6. ATDDのスタイルとツール2.1.7. ユーザインターフェイスをバイパスしたテスト2.1.8. ユーザインターフェイスを介したテスト2.1.9 機能横断テスト

ユニットテスト(2.1.1.)

コンポーネントテスト受入テスト非機能テスト

ATDDの３形態(2.1.6)

テキストベース（cucumber)

テーブル形式（fit)

コードに記述（xUnit)

非機能テスト(2.1.9)

キャパシティ応答速度セキュリティなどなど


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)

2.2. テストをプログラミングする

2.2.1. プログラマの意図をもったテストコードを書く2.2.2. テストをテストする2.2.3. テスト実行時間2.2.4. フィクスチャのセットアップ2.2.5. 評価の結果2.2.6. テストダブルを使う（例えばデータベースを直接つかわないでテストする事等）2.2.7. テストのリファクタリング

少なくとも、３つの違った方法でテストコードを確認すること


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.1. コラボレーションスキル3.1.2. 仕事の割り当て3.1.3. 利害関係者との会話3.1.4. ペアプログラミング3.1.5. コミュニケーションを設計する3.1.6. あんどんの情報3.1.7. 作業場所3.1.8. 分散したチーム

タスクとカンバン（3.1.6)

ストーリマッピングバーンチャート累積フロー図あんどん


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

アクティブリスニング共同もしくは個人のファシリテーションオープンな提案と、批判ができること建設的な批判ができること正直でいることが良い事であるムードを作れる失敗をしても責められないこと尊敬しあうことクリーンであること自分の意見をいうことhttp://www.wikihow.com/Speak-Up

黙っていることディベート（何かをコラボレーションで）生産することコミュニケーションスタイルの違いを理解する




http://www.wikihow.com/Speak-Up

http://www.wikihow.com/Speak-Up

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.2.1. 共同責任3.2.2. 共同所有

3.2.2. 共同所有３つのモデル　オーナーのみ　どんなペアでもよい　誰もいい


3.3. Team activity

3.3.1. Reflection workshops3.3.2. Daily meetings


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

3.3.1. ふりかえり3.3.2. デイリーミーティング


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.1.1. 機能単位で開発する4.1.2. 分解する4.1.3. 機能横断的な制約4.1.4. 技術的リスクの軽減

リスクの軽減(4.1.4.)

スパイクプロトタイプウォーキングスケルトン（とりあえず一通り度長する小さな実装）http://alistair.cockburn.us/Walking+skeleton

その他

機能単位（4.1.1.)

主なWBS

粗粒度、中粒度、細粒度の機能の理解の必要性ユースケース、ストーリマップMMF (最低限のマーケット化可能な機能）もしくは機能リスト良い仕事のための統計


http://alistair.cockburn.us/Walking+skeleton

http://alistair.cockburn.us/Walking+skeleton

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)

4.2.1. 見積もり4.2.2. 異なるグラニュリティを計画する4.2.3. リスク軽減アイテムをスケジュールする4.2.4. 仕事を繰り返す

粗い粒度で長期的に、細粒度で短期的に

計画するのがアジャイルのやり方開発側も、ビジネス側も


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)

5.1. ツールを活用する5.1.1. バージョン管理ツール5.1.2. ビルドツール5.1.3. 継続的インテグレーション5.1.4. 継続的デリバリ



メソッド屋の日記

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

Sorry Japanese only




Documents

Ultimate agilisttokyo(japanese)