Pair programming illuminated
著者
書誌事項
Pair programming illuminated
Addison-Wesley, c2003
大学図書館所蔵 全2件
  青森
  岩手
  宮城
  秋田
  山形
  福島
  茨城
  栃木
  群馬
  埼玉
  千葉
  東京
  神奈川
  新潟
  富山
  石川
  福井
  山梨
  長野
  岐阜
  静岡
  愛知
  三重
  滋賀
  京都
  大阪
  兵庫
  奈良
  和歌山
  鳥取
  島根
  岡山
  広島
  山口
  徳島
  香川
  愛媛
  高知
  福岡
  佐賀
  長崎
  熊本
  大分
  宮崎
  鹿児島
  沖縄
  韓国
  中国
  タイ
  イギリス
  ドイツ
  スイス
  フランス
  ベルギー
  オランダ
  スウェーデン
  ノルウェー
  アメリカ
注記
Includes bibliographical references and index
内容説明・目次
内容説明
At face value, pair programming appears to be a simple, straightforward concept. Two programmers work side-by-side at one computer, continuously collaborating on the same design, algorithm, code, and test. If it was as simple as plopping two skilled programmers at one desktop, there would be no need for this book. However, there are people and personalities involved, and these people are accustomed to programming alone. Pair programming offers significant benefits: quality is increased, time is saved, morale is improved, trust and teamwork grow, knowledge is shared, and learning is enhanced. However, before any pair programming can take place, participants have to accept a new way of thinking. In Pair Programming Illuminated, Laurie Williams and Robert Kessler help you fight through the exceptions, gain collective acceptance of this approach, and experience remarkable success with it. Two case studies show pair programming in practice using Extreme Programming and Collaborative Software Process as methods.
目次
Preface.
Who Should Read This Book.
Acknowledgments.
I. GAINING UNDERSTANDING.
1. Introduction.
To Pair ...
... or Not to Pair, This Is the Question.
A Fly on the Wall.
A Pair Programming Timeline.
Some Words of Caution.
2. The Seven Myths of Pair Programming.
Myth 1: It will double the workload with two doing the work one can do.
Myth 2: I'll never get to work alone. I couldn't stand that!
Myth 3: It will work well only with the right partner.
Myth 4: Pair programming is good for training. But, once you know what you're doing, it is a waste of time.
Myth 5: I'll never get credit for doing anything. I'll have to share all the recognition with my partner.
Myth 6: The navigator finds only syntax mistakes. How boring is that! Compilers can do that better than humans can anyway.
Myth 7: The only time I ever get any real work done is when I'm alone. Now, I'll never get anything done! Pair programming would drive me crazy.
3. The Seven Synergistic Behaviors of Pair Programming.
Behavior 1: Pair Pressure.
Behavior 2: Pair Negotiation.
Behavior 3: Pair Courage.
Behavior 4: Pair Reviews.
Behavior 5: Pair Debugging.
Behavior 6: Pair Learning.
Behavior 7: Pair Trust.
4. Overcoming Management Resistance to Pair Programming.
Motivations.
Goal: I want to complete my projects on time with high-quality code.
Goal: I want to reduce my risk of losing a key person.
Goal: I want my employees to be happy.
Goal:I want to reduce the amount of time it takes to train a new person.
Goal:I want my teams to work well together and to communicate more effectively and efficiently with each other.
5. Gaining Support and Acceptance from Your Peers.
6. Transitioning to Pair Programming by Choice.
Green and Hevner's Findings.
Advice for Management.
Advice for Programmers.
7. Problem, Problems.
Dependency.
Scheduling.
The Ever-Popular Expert.
Colocation.
Noise and Facility Considerations.
Concentration.
Disagreements.
Overconfidence.
Rushing.
Skill Imbalances.
Simply Not for All.
Summary: Maintenance Required.
II. GETTING STARTED WITH PAIR PROGRAMMING.
8. Workplace Layout.
The Basic Needs.
Some Suggested Workplace Enhancements.
Interpair Communications.
Development Environments.
Noise Considerations.
One Last Thing.
9. Pair Rotation: Communication, Knowledge Management, and Training.
Pairing with the Right Partner.
Partner Assigning Logistics.
Pair Rotation and Knowledge Management.
Pair Rotation and Training.
Reprisal: Pair Rotation.
10. Other Issues to Consider.
Performance Appraisals.
Group Size.
Quality Assurance.
Functional and System Testing.
Maintaining and Enhancing Code.
11. Tips 'n Tricks.
III. PAIR PROGRAMMING PARTNER PICKING PRINCIPLES.
12. Expert-Expert Pairing.
Intent.
Characteristics of Success.
Challenges.
Personal Scenarios.
13. Expert-Average Pairing.
Intent.
Characteristics of Success.
Challenges.
Personal Scenarios.
14. Expert-Novice Pairing.
Intent.
Characteristics of Success.
Challenges.
Personal Scenarios.
15. Novice-Novice Pairing.
Intent.
Characteristics of Success.
Challenges.
Personal Scenarios.
16. Extrovert-Extrovert Pairing.
Intent.
Characteristics of Success.
Challenges.
Personal Scenarios.
17. Extrovert-Introvert Pairing.
Intent.
Characteristics of Success.
Challenges.
18. Introvert-Introvert Pairing.
Intent.
Characteristics of Success.
Challenges.
Personal Scenarios.
19. Gender Nonissue.
Issue.
What This Is About.
If There Are Problems.
Personal Scenarios.
20. Culture Nonissue.
Issue.
What This Is About.
If There Are Problems.
Personal Scenarios.
21. The Professional Driver Problem.
Root Causes.
General Form.
Refactored Solution.
Personal Scenarios.
22. "My Partner Is a Total Loser" and Other Excess Ego Problems.
Root Causes.
General Form.
Refactored Solution.
Personal Scenarios.
23. "My Partner Is SO Smart" and Other Too Little Ego Problems.
Root Causes.
General Form.
Refactored Solution.
Personal Scenarios.
IV. CASE STUDIES OF PAIR PROGRAMMING IN A SOFTWARE PROCESS.
24. Pair Programming in a Software Process Case Study: Extreme Programming (XP).
A Life-Cyle Evolution.
Along Comes XP.
Requirements Definition.
System and Software Design.
Code Implementation and Unit Testing.
Acceptance Testing.
XP Needs Pair Programming.
25. Pair Programming in a Software Process Case Study: Collaborative Software Process (CSP).
CSP Overview.
Focus Area 0: Baselining Your Process.
Focus Area 1: Quality Management.
Focus Area 2: Project Management.
Summary.
V. IN CLOSING.
26. Moving Ahead, Going Beyond.
Triplets.
Multidisciplinary Pairs.
Code Inspections Obsolete?
Projection Screens.
Distributed Pair Programming.
Pair Learning.
27. Seven Habits of Effective Pair Programmers.
Habit 1: Take Breaks.
Habit 2: Practice Humility.
Habit 3: Be Confident/Be Receptive.
Habit 4: Communicate.
Habit 5: Listen.
Habit 6: Be a Team Player.
Habit 7: Hone the Balance between Compromise and Standing Firm.
Finale.
Appendix A: Pair Programming Tutorial.
Appendix B: An Economic Analysis of Pair Programming.
Appendix C: Pair Programming in the Classroom.
Appendix D: An Introduction to Test Driven Development.
Index.
「Nielsen BookData」 より