How to be an agile programmer.
-
Upload
tsuyoshi-ushio -
Category
Documents
-
view
989 -
download
4
description
Transcript of 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日日曜日
12年11月18日日曜日
Definition of Agile Programmer
Think about
in this session
12年11月18日日曜日
Agenda
Learn about other definitions
Discussion
Conclusion
12年11月18日日曜日
Learn aboutother
definitions
12年11月18日日曜日
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月18日日曜日
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月18日日曜日
Analyze it
12年11月18日日曜日
XP practices
http://ullizee.wordpress.com/2009/11/02/extreme-programming-revisited-part-i/
12年11月18日日曜日
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月18日日曜日
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月18日日曜日
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月18日日曜日
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月18日日曜日
five objectives andpractices
Agile Programmer’s mandatory skill Map
Five Objectives
Practices
12年11月18日日曜日
http://simple-architect.blogspot.jpPlease get documents from
12年11月18日日曜日
Discussion
12年11月18日日曜日
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
12年11月18日日曜日
I’ll share your conclusions later in English.
Thank you!
http://newtechusa.net/culture-con/
12年11月18日日曜日
We thoughtThis is the
Agile Programmer’sSkill set
Workshop Results in 10 minutes
12年11月18日日曜日
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
12年11月18日日曜日
Team Door Side
Collaboration with customerCollaboration with team members
Identify customer’sPower Structure
Listening Skill
ability to think
ability to think realization
Vagrant &chef!!!
12年11月18日日曜日
Team 7
Design Test
ability to read someone’s code
coarse grained designarchitecture
UnderstandBusiness Requirement
Communication Skill
Embrace Change
Stout heart
ambitionsincerity
12年11月18日日曜日
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
12年11月18日日曜日
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!
12年11月18日日曜日
Summary
12年11月18日日曜日
Summary
12年11月18日日曜日
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
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月18日日曜日
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月18日日曜日
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月18日日曜日
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月18日日曜日
1.3. Technical Debt
1.3.1. Recognizing technical debt1.3.2. Discussing technical debt choices with stakeholders.
1. Designing & Programming
12年11月18日日曜日
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月18日日曜日
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月18日日曜日
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月18日日曜日
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)
12年11月18日日曜日
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月18日日曜日
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月18日日曜日
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月18日日曜日
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月18日日曜日
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月18日日曜日
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月18日日曜日
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月18日日曜日
http://d.hatena.ne.jp/simplearchitect/20120810/1344615415
メソッド屋の日記
こんなプログラマはアジャイル出来ますって言ったらアカンやろ
Sorry Japanese only
12年11月18日日曜日