Extreme Programming Methodology

1
Extreme Programming Methodology
Emin BORANDAG Department of Informatics, Maltepe
University,Turkey eminb_at_maltepe.edu.tr
2
Klasik Metotlara Olan Elestiriler

• Sürüm yani çalisan program çok geç ortaya
  çikiyor.
• Sürüm çok geç çiktigi için hatalar çok geç
  anlasiliyor.
• Verimli degil.
• Esnek degil, yeni gelen isterler dogrultusunda
  kendi yapisini degistiremedigi için yeni
  isterleri karsilayamiyor.
• Degisiklik geç ve zor yapiliyor.

3
Agile Metodolojiler

• Extreme Programing
• Scrum
• Crystal Family
• Rup

4
What is Xp?

• XPs mechanism depends on some simple practices
  and applications. These practices may seem to be
  so simple and unnecessary at the beginning but
  after a while they will show their power through
  the successes gained .

5
Extreme ProgramingAvantajlari

• Hata oranini azaltma
• Yazilimin erken safhasinda somut gelismeler
  saglaya bildiginden, olusan hatalarin farkina
  varabilir.Bu hatalari da kendi içerisinde
  olusturdugu küçük yasam döngüleri ile telafi
  edebilir.
• Projenin gelisme süresini kisaltir.
• Artirimsal yaklasim sayesinde hizli bir sekilde
  genel planin olusmasi saglanir.Burada ayni bütün
  ekip tarafindan proje süresi tahmini de yapilir.
• Degisikliklere izin verir.
• Esnek is yürütme ve fonksiyonellik sayesinde,
  isletmenin degisen ihtiyaçlarina cevap verir
• Yazilimsal olarak ortaya çikabilecek
  tikanikliklari azaltir.
• Müsteriler ile birlikte monitörlerden
  programcilar ve müsteriler ortak bir sekilde test
  yaparak ileride tikanikliklarin ortadan
  kaldirilmasini saglarlar.

6
XP History

• Ward and Kent together had experienced an
  approach to software development that made every
  thing seem simple and more efficient. Kent
  contemplated on what made software simple to
  create and what made it difficult.

7
XP History

• In March of 1996 Kent started a project at
  DaimlerChrysler using new concepts in software
  development. The result was the Extreme
  Programming (XP) methodology. What Kent came to
  realise is that there are four dimensions along
  which one can improve any software project. You
  need to improve communication. You need to seek
  simplicity. You need to get feedback on how well
  you are doing. And you need to always proceed
  with courage. Communication, Simplicity,
  Feedback, and Courage are the four values sought
  out by XP programmers

8
Degisim Maliyeti
9
Extreme Programing 4 Temel Noktasi

• Iletisim
• Basitlik
• Geri Besleme
• Cesaret

10
Iletisim

• XP in ilk temel tasi iletisimdir. Projelere
  baktigimizda ortaya çikan önemli problemlerin
  insanlarin birbirleriyle tam olarak anlasamamasi
  nedeniyle oldugunu görünür. Bazen programcilar
  sormalari gereken dogru soruyu soramazlar. Bazen
  de projenin yapisiyla ilgili önemli bir gelismeyi
  söylemezler. Bu yüzden projelerde çesitli tikanma
  noktalari olabilir. Bazen de proje yöneticileri
  programcilara belirtmeleri gerekenleri tam olarak
  belirtemezler. Bu da projenin gelisme
  sürecilerini olumsuz etkiler. XP de iletisim yüz
  yüze olmalidir. Iletisim sürekliligi olmalidir.
  Yazilim ekibi ile yazilimi kullanacaklar arasinda
  siki bir iletisim bagi olmasi esastir. Bu sayede
  sorunlar erken fark edilir.

11
Basitlik

• XP in ikinci temel tasi basitliktir. Aslinda
  basitlik saglanmasi zor olan bir konudur.
  Basitlik, zorunlu islerin yapilmasidir. Gerekli
  olmayan bir sey varsa, kesinlikle bu konu XP
  basitlik ilkesi içerisinde olmamalidir. Dünyadaki
  en zor sey gelecekte ne gibi ihtiyaçlarla
  karsilasacagimizi bilmemektir. Bu nedenden dolayi
  olusturulacak yapi, gelecekte ne gibi isterlerin
  ortaya çikacagini tam olarak bilmeden olusur.
  Buna göre esnek zaman ve maliyeti göz önüne
  alinmis bir yapi olusturmak gerekmektedir. XP en
  iyi sekilde bu basitligi saglamak için, bu günün
  ihtiyaçlarini hedef alarak esnek ve basit bir
  sistem gerçeklestirmeye çalisir.

12
Geri Besleme

• Sistemlerin geri dönüsümü olmasi sistemler için
  paha biçilemez bir firsat yaratir. Geri dönüsüm
  sayesinde optimizasyonun olusmasina engel olan
  tehlikeler ortadan kaldirilir. Öncelikle
  programcilar bütün sistemin mantiksal yapisini
  içeren bölüm testleri olusturur. Programcilar
  sistem hakkinda somut bilgiler elde ederler.
  Müsteriler yeni bir stories hikâye ile
  geldikleri zaman, programcilar hemen bu yeni
  gelen hikâyenin gerçeklesmesi ile ilgili çalisma
  yapip bu stories e uygun bir çalisma
  gerçeklestirirler.

13
Cesaret

• XP in dört temel noktasindan en zoru cesarettir.
  Projelerin üzerine yilmadan gidilmesi projelerin
  gelistirilmesi açisindan son derece önemlidir.
  Cesaretin olmadigi projelerde korku gelisir ve
  gelisen bu korku projeyi basarisizliga iter.
  Yazilim islerindeki basarisizlik ise yazilimin
  çöpe gitmesidir ve maalesef genel duruma da
  baktigimizda yazilimlarin büyük bir kisminin çöpe
  gittigini görünyorur. Basarisizlik, genel tabiat
  içerisinde olan bir durumdur. Basarisizliktan
  korkmak yerine basarisizligi olusturan nedenler
  üzerine gitmek yerinde olacaktir. Basarisizlikla
  mümkün olunan en kisa sürede karsilasmak, daha
  sonra telafi etme sansini arttirir.

14
Extreme ProgrammingKorkmadiklari

• Kodlama
• Degisen fikirler
• Gelecegi bilmeden yol alabilmek
• Çalisan bir sistemin yapisinin degismesi
• Testler yazilmasi

15
Extreme ProgramingRoller

• Müsteri
• Yazilim gelistirme sorumlusu
• Test sorumlusu
• Ölçüm sorumlusu
• Koç
• Danisman
• Yönetici

16
Extreme Programing Çalisma Mantigi
17
Planning Game
XP Practices
Planning Game
On-Site Client
Testing
Simple Design
Pair Programming
Continuous Integration
Small Releases
Refactoring
Collective Ownership
Metaphor
Coding Standard
40-Hours a Week
In the initial phase of the project, tasks are
not described in detail. Only specific issues are
tried to be solved. After this phase detailed
project plan is produced for small processes
18
On-Site Client
XP Practices
Planning Game
On-Site Client
Testing
Simple Design
Pair Programming
Continuous Integration
Small Releases
Refactoring
Collective Ownership
Metaphor
Coding Standard
40-Hours a Week
Client representatives are present in the same
environment with the software development team.
Thus, it is ensured that the information software
development teams needs are accessed rapidly
19
Testing
XP Practices
Planning Game
On-Site Client
Testing
Simple Design
Pair Programming
Continuous Integration
Small Releases
Refactoring
Collective Ownership
Metaphor
Coding Standard
40-Hours a Week
Test code is written before the project code.
Thus, it is ensured that reliable software is
implemented by revealing the potential problems
sooner
20
Simple Design
XP Practices
Planning Game
On-Site Client
Testing
Simple Design
Pair Programming
Continuous Integration
Small Releases
Refactoring
Collective Ownership
Metaphor
Coding Standard
40-Hours a Week
A design that meets client requirements in the
simplest way is produced. Software is designed
according to the given requirements and future
requirements are not anticipated
21
Pair Programming
XP Practices
Planning Game
On-Site Client
Testing
Simple Design
Pair Programming
Continuous Integration
Small Releases
Refactoring
Collective Ownership
Metaphor
Coding Standard
40-Hours a Week
This is the practice in which two programmers
develop code together by sharing the same
computer. While one of the programmers is writing
the code the other one examines the code and they
alternately change places with each other.
22
Continuous Integration
XP Practices
Planning Game
On-Site Client
Testing
Simple Design
Pair Programming
Continuous Integration
Small Releases
Refactoring
Collective Ownership
Metaphor
Coding Standard
40-Hours a Week
Every module that has been developed is
integrated to the other modules. Errors that can
occur due to the conflicts are eliminated by
integrating all modules. Module integration is
done once or twice a week
23
Small Releases
The release of the program is given to the client
in short periods of time. Thus, client can follow
the progression of the project. The advantage of
XP is that an executable release is produced in a
short time compared to the other methods. Thus,
the client has the chance to see the completed
parts of the software on early phases
XP Practices
Planning Game
On-Site Client
Testing
Simple Design
Pair Programming
Continuous Integration
Small Releases
Refactoring
Collective Ownership
Metaphor
Coding Standard
40-Hours a Week
24
Refactoring
XP Practices
Planning Game
On-Site Client
Testing
Simple Design
Pair Programming
Continuous Integration
Small Releases
Refactoring
Collective Ownership
Metaphor
Coding Standard
40-Hours a Week
Design faults can cause the system not to be
corrected afterwards. Therefore, code and design
should be revised constantly
25
Collective Ownership
XP Practices
Planning Game
On-Site Client
Testing
Simple Design
Pair Programming
Continuous Integration
Small Releases
Refactoring
Collective Ownership
Metaphor
Coding Standard
40-Hours a Week
The software code that is developed is the common
asset of the team members. The fundamental of the
collective ownership practice is that any team
member can access the codes other members
produced within definite rules. It is aimed that
team members will be able, by this mean, to do
changes over the code to improve the existing
software
26
Metaphor
XP Practices
Planning Game
On-Site Client
Testing
Simple Design
Pair Programming
Continuous Integration
Small Releases
Refactoring
Collective Ownership
Metaphor
Coding Standard
40-Hours a Week
It is tried to produce software by emulating the
systems within the implementation. For example,
the software being implemented is divided into
parts and each part is emulated to another system
27
Coding Standard
XP Practices
Planning Game
On-Site Client
Testing
Simple Design
Pair Programming
Continuous Integration
Small Releases
Refactoring
Collective Ownership
Metaphor
Coding Standard
40-Hours a Week
It is useful to have a coding standard rather
than using different coding standards. It is
important that coding issues such as names of
forms and variables, locations of functions, etc.
have a standard in terms of simplicity and
comprehensibility of the code.
28
40-Hours a Week
In terms of working efficiency, 40 hours of work
time a week is set. Tasks are performed in 8
hours a weekday. There is no overtime concept in
40-Hours a week practice.Even if the team works
more than 40 hours, increase of the efficiency
will not be enough. The risk of increase in
errors also goes up.
XP Practices
Planning Game
On-Site Client
Testing
Simple Design
Pair Programming
Continuous Integration
Small Releases
Refactoring
Collective Ownership
Metaphor
Coding Standard
40-Hours a Week
29
Project Development USING XP

• Project Planning
• Revealing Existing Requirements by Examining the
  Old Version
• Determining the Main Processes and the Sub
  Processes
• Coding the Software
• Testing the Software

30
Project Planning

• Project development process started with the
  planning game favorably with XPs structure. A
  basic plan far from the details of the project
  was produced with the planning game. By means of
  the planning game, the processes that would be
  used in the development of the Automation System
  were determined.

31
Coding the Software

• In this process, requirements in the technical
  cards were transformed into program codes
  complied with the coding standard determined in
  the project plan and formed by taking advantage
  of previous experiences. The aim was to develop
  software that could be followed can be managed
  and changed easily by using simple design
  practice.

32
Testing the Software

• The test of the automation system carried out in
  three phases. In the first phase unit tests were
  applied to the codes developed complied to the
  collective ownership practice by the programmers
  and the team leader. In the second phase software
  was tested by client according to the user
  stories formed during the determination of the
  work processes.

33
Basili and Boehm, Software Defect Reduction Top
10 List, IEEE Computer Society, vol. 34, (No.
1),January 2001, pp. 135137.
Figure 1 is an irrefutable proof of the axiom
test early and test often.
34
(No Transcript)
35
(No Transcript)
36
Riskler ve Risk çözümleri
Gecikmeler Kisa sürüm zamanlari
Projenin iptal edilmesi Is acisindan en önemli süreçlere önem verilmesi.
Yama tutmayan sistemler Anlasilir test senaryolari (otomatik test)
Yanlis anlasmalar Müsterinin takimin ayrilmaz bir üyesi olmasi sayesinde yanlis anlamalarin büyük bir kismi önlenir.
Is dünyasindaki degisiklikler Kisa sürüm zamanlari
Ihtiyaç duyulmayan birçok özellik Sadece en öncelikli islerin yapilmasi
Isten çikmalar Çift programci
37
References (1/2)

• Schach, S., R., Object-Oriented Classical
  Software Engineering, 7th Ed., McGraw Hill,
  2007.
• Borandag, E., Basamakli CMMI Modeli ile Extreme
  Programming Metodunun Degerlendirilmesi, Maltepe
  Üniversitesi, Fen Bilimleri Enstitüsü, Yüksek
  Lisans Tezi, 2006.
• Randell, B., The 1968/69 NATO Software
  Engineering Reports, 2009, World Wide Web
  http//homepages.cs.ncl.ac.uk/brian.randell/NATO/N
  ATOReports/index.html
• Saridogan, E., Yazilim Mühendisligi, Papatya
  Yayincilik, 2004.
• Beck, K., eXtreme Programming, Addison-Wesley,
  2002.
• Agile Team 2005 12 Practice, 2009, World Wide
  Web www.agilemanifesto.com\12Practice.html
• Acar, Ö., Extreme Programming, Pusula
  Yayincilik, 2009.

38
References (2/2)

• Newkirk, J., Introduction to Agile Processes and
  Extreme Programming Thought Works, Proceedings
  of the 24th International Conference on Software
  Engineering, Pages695-696, 2002.
• Paulk, M., C., Extreme Programming from CMM
  Perspective, IEEE Software, 2001.
• Borandag, E., Yücalar, F., Erdogan, S. Z.,
  Ince, F., Basamakli CMMI Modeli ile Extreme
  Programming Metodunun Degerlendirilmesi, Trakya
  Üniversitesi Fen Bilimleri Dergisi, ISSN 1305
  6468, Haziran 2009.
• Layman, L., Williams, L., Daiman, D., Bures, H.,
  Essential communication practices for Extreme
  Programming in a global software development
  team, Journal of Information and Software
  Technology, Elsevier, 2006.
• Kalayci, O., Uygulamali CMMI/XP Egitimi,
  Nitelik Danismanlik, 2006.

39
Additional Resources

• Mailing Lists
• Yahoo Group testdrivendevelopment
• Yahoo Group agiledotnet
• Books
• Test-Driven Development in Microsoft .NET James
  Newkirk and Alexei Vorontsov
• Test-Driven Development, by Example Kent Beck
• Test-Driven Development, A Practical Guide
  David Astels
• Unit Testing in Java, Johannes Link

40
Community Resources

• Web Siteshttp//www.testdriven.comhttp//www.xpr
  ogramming.comAgileAlliance.com
• ExtremeProgramming.org
• Blogshttp//dotnetjunkies.com/WebLog/darrell_nort
  onhttp//www.peterprovost.orghttp//weblogs.asp.
  net/nunitaddinhttp//weblogs.asp.net/jamesnewkirk
  
• http//www,iserializable.com