Ultimate agilisttokyo(japanese)

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

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

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

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


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

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
ごめん、これは勘弁して
ただし、ブログにこれの後さらに
分析して日本語化したTreeあり

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


XP practices
XPのプラクティス

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

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.1. テスト駆動開発
1.2. Good Design 1.2. よい設計
1.3. 技術的負債
1. Designing & Programming 1.3. Technical Debt
1.4. リファクタリング
1.4. Refactoring 1.5. レガシーコード
設計とプログラミング
1.5. Legacy Code
2.1. Acceptance Test 2.1. 受入テスト
2. Testing 2.2. テストのプログラミング
2.2. Programming the test
テスト
3.1. Collaboration 3.1. コラボレーション
3.2. 共同責任
3. Teams and Behaviors 3.2. Collective Accountability 3.3. チームアクティビティ
チームと振る舞い 3.3. Team Activity
4.1. Function-Based Development
4. Structuring Work 4.1. 機能ベース開発
4.2. Planning 4.2. プランニング
作業を構造化する

5. Environment 5.1. Leveraging Tools
環境 5.1. ツールを活用する


five objectives and
practices
Five Objectives

Practices

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

Agile Programmer’s mandatory skill Map

Please get documents from

http://simple-architect.blogspot.jp
日本語版
http://d.hatena.ne.jp/simplearchitect/20121117/1353181189


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

Conclusion


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

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


We thought
This is the
Agile Programmer’s
Skill set

Workshop Results in 10 minutes

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


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


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


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


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


Summary


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.1. テスト駆動開発

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.1. テスト駆動開発の価値
1.1.3. Identifying completeness of conditions that drive usage patterns in the code
1.1.2. オブジェクトや関数のインターフェイスの利用パターンを探し出す
1.1.4. Avoiding duplication in the conditions 1.1.3. コードの中の条件の完全性の利用パターンを探し出す
1.1.5. Red-Green-Refactor 1.1.4. 条件の重複を避ける
1.1.6. Test Speed 1.1.5. レッド、グリーン、リファクタリングパターン
1.1.6. テストのスピード

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

1. Designing & Programming
Architecture (1.2.1)
1.2. Good Design 1. 設計とプログラミング
1.2. よい設計
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.1. 大きな設計の役割

1.2.5. Clean Programming 1.2.2. シンプルな設計
1.2.3. 設計の評価と、設計原則
1.2.6. Listening to your tests
1.2.4. デザインパターン
1.2.5. クリーンプログラミング
1.2.6. あなたのテストに聞いてみよう

Agile Software Development The Art of Readable Code
Robert C. Martin (2011) Dustin Boswell, Trevor Foucher (2011)


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

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)
SOLID
単一責任の原則
オープンクローズ原則
リスコフ置換の原則
インターフェイス分離の原則
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.3.1. Recognizing technical debt
1.3.2. Discussing technical debt choices with stakeholders.
1.3.1. 技術的負債を理解する
1.3.2. 技術的負債の選択について利害関係者と議論する


DB, HTML refactoring (1.4.4.

1.4. Refactoring
1.4. リファクタリング

1.4.1. リファクタリングの原則
1.4.1. Principles of refactoring 1.4.2. 不吉な香り
1.4.2. Code smells 1.4.3. 一般的なリファクタリング
1.4.3. Common refactorings 1.4.4. 広がるリファクタリングの世界

1.4.4. The larger world of refactoring 1.4.5. リファクタリング（そのもの）

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)


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

1. Designing & Programming リファクタリングツールを使う
静的型付け言語の場合
・エラーをコンパイラが見つけてくれる

witout test code (1.5.2.) レベルに小さなステップに分解する
1.5. Legacy code refactoring tools
動的型付け言語の場合
・エラーがほとんど起こらない程度の
1.5. レガシーコード 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
1.5.1. レガシーコードへのアプローチ
1.5.2. テストなしでリファクタリングする
1.5.3. レガシーコードにテストをつける

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


2. Testing
2.1. Acceptance Testing
ユニットテスト(2.1.1.)
2.1. 受入テスト
コンポーネントテスト
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) ATDDの３形態(2.1.6)
2.1.7. Testing the system bypassing the user interface in code (xUnit) テキストベース（cucumber)
2.1.8. Testing the system through the user interface テーブル形式（ﬁt)
2.1.9. Cross-functional testing cucumber (2.1.8.) コードに記述（xUnit)
2.1.1. 自動化するテストの種類
2.1.2. 仕様、ドキュメントとしてのテスト
Robot Framework
2.1.3. ATDD がデザインシンキングを助ける
2.1.4. テスターとビジネスの人と開発者の non-functional tests(2.1.9.)
コラボレーション capacity
2.1.5. ATDDプロセス response time
2.1.6. ATDDのスタイルとツール security 非機能テスト(2.1.9)
2.1.7. ユーザインターフェイスをバイパスしたテスト etc... キャパシティ
2.1.8. ユーザインターフェイスを介したテスト応答速度
2.1.9 機能横断テストセキュリティ

ATDD by Example: A Practical Guide to Acceptance Test-Driven Development などなど
Markus Gartner (2012)

2. Testing
2.2. Programming the tests
2.2. テストをプログラミングする
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.1. プログラマの意図をもったテストコードを書く
2.2.4. Fixture Setup 2.2.2. テストをテストする
2.2.5. Result Veriﬁcation 2.2.3. テスト実行時間
2.2.6. Use test doubles 2.2.4. フィクスチャのセットアップ
2.2.7. Refactoring Test 2.2.5. 評価の結果
2.2.6. テストダブルを使う（例えばデータベースを直接つかわないでテストする事等）
2.2.7. テストのリファクタリング

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.1. コラボレーションスキル
3.1.7. Working spaces 3.1.2. 仕事の割り当て
タスクとカンバン（3.1.6)

3.1.8. Distributed teams 3.1.3. 利害関係者との会話
ストーリマッピング
バーンチャート
3.1.4. ペアプログラミング
累積フロー図
3.1.5. コミュニケーションを設計する
あんどん
3.1.6. あんどんの情報
3.1.7. 作業場所
3.1.8. 分散したチーム

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
コミュニケーションスキル(3.1.1.)
アクティブリスニング
共同もしくは個人のファシリテーション
オープンな提案と、批判ができること

Communication Skills (3.1.1.) 建設的な批判ができること
正直でいることが良い事であるムードを作れる
active listening
失敗をしても責められないこと
self- or shared facilitation
尊敬しあうこと
being open for suggestions & criticisms クリーンであること
constructive criticism 自分の意見をいうことhttp://www.wikihow.com/Speak-Up
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 3.2.1. 共同責任
3.2.2. 共同所有

three models (3.2.2.)
owner-only
any-pair
any-one
3.2.2. 共同所有３つのモデル
オーナーのみ
どんなペアでもよい
誰もいい
Extreme Programming Explained: Embrace Change
Kent Beck (1999)


3.3. Team activity

3.3.1. Reﬂection workshops 3.3.1. ふりかえり

3.3.2. Daily meetings 3.3.2. デイリーミーティング

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


機能単位（4.1.1.)
主なWBS

4. Structuring Work
粗粒度、中粒度、細粒度の機能の理解の必要性
ユースケース、ストーリマップ
MMF (最低限のマーケット化可能な機能）もしくは機能リスト
良い仕事のための統計
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
4.1.1. 機能単位で開発する Risk reduction (4.1.4.)
4.1.2. 分解する spikes
4.1.3. 機能横断的な制約 prototypes
4.1.4. 技術的リスクの軽減 walking skeleton
others

Writing Effective Use Cases
Alistair Cockburn (2000)
リスクの軽減(4.1.4.)
スパイク
プロトタイプ
ウォーキングスケルトン（とりあえず一通り度長する小さ
User Stories Applied 要求開発 User Story Mapping
な実装）http://alistair.cockburn.us/Walking+skeleton 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.1. 見積もり
4.2.4. Sequencing work 4.2.2. 異なるグラニュリティを計画する
4.2.3. リスク軽減アイテムをスケジュールする
4.2.4. 仕事を繰り返す

Agile Estimating and Planning
Mike Cohn (2005)


5. Environment
5.1. Leveraging tools
5.1. ツールを活用する
5.1.1. バージョン管理ツール
5.1.1. Version Control 5.1.2. ビルドツール
5.1.2. Build Tools 5.1.3. 継続的インテグレーション

5.1.3. Continuous Integration 5.1.4. 継続的デリバリ

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(japanese)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Ultimate agilisttokyo(japanese)

Similar a Ultimate agilisttokyo(japanese) (20)

Más de Tsuyoshi Ushio

Más de Tsuyoshi Ushio (20)

Ultimate agilisttokyo(japanese)