Extreme Programming Methodology

... konulu sunumlar: "Extreme Programming Methodology"— Sunum transkripti:

1 Extreme Programming Methodology
Emin BORANDAĞ Department of Informatics, Maltepe University,Turkey

2 Klasik Metotlara Olan Eleştiriler
Sürüm yani çalışan program çok geç ortaya çıkıyor. Sürüm çok geç çıktığı için hatalar çok geç anlaşılıyor. Verimli değil. Esnek değil, yeni gelen isterler doğrultusunda kendi yapısını değiştiremediği için yeni isterleri karşılayamıyor. Değişiklik geç ve zor yapılıyor.

3 Extreme Programing Scrum Crystal Family Rup
Agile Metodolojiler Extreme Programing Scrum Crystal Family Rup

4 What is Xp? XP’s 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 Programing Avantajları
Hata oranını azaltma Yazılımın erken safhasında somut gelişmeler sağlaya bildiğinden, oluşan hataların farkına varabilir.Bu hataları da kendi içerisinde oluşturduğu küçük yaşam döngüleri ile telafi edebilir. Projenin gelişme süresini kısaltır. Artırımsal yaklaşım sayesinde hızlı bir şekilde genel planın oluşması sağlanır.Burada aynı bütün ekip tarafından proje süresi tahmini de yapılır. Değişikliklere izin verir. Esnek iş yürütme ve fonksiyonellik sayesinde, işletmenin değişen ihtiyaçlarına cevap verir Yazılımsal olarak ortaya çıkabilecek tıkanıklıkları azaltır. Müşteriler ile birlikte monitörlerden programcılar ve müşteriler ortak bir şekilde test yaparak ileride tıkanıklıkların ortadan kaldırılmasını sağlarlar.

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 Değişim Maliyeti

9 Extreme Programing 4 Temel Noktası
İletişim Basitlik Geri Besleme Cesaret

10 İletişim XP in ilk temel taşı iletişimdir. Projelere baktığımızda ortaya çıkan önemli problemlerin insanların birbirleriyle tam olarak anlaşamaması nedeniyle olduğunu görünür. Bazen programcılar sormaları gereken doğru soruyu soramazlar. Bazen de projenin yapısıyla ilgili önemli bir gelişmeyi söylemezler. Bu yüzden projelerde çeşitli tıkanma noktaları olabilir. Bazen de proje yöneticileri programcılara belirtmeleri gerekenleri tam olarak belirtemezler. Bu da projenin gelişme sürecilerini olumsuz etkiler. XP de iletişim yüz yüze olmalıdır. İletişim sürekliliği olmalıdır. Yazılım ekibi ile yazılımı kullanacaklar arasında sıkı bir iletişim bağı olması esastır. Bu sayede sorunlar erken fark edilir.

11 Basitlik XP in ikinci temel taşı basitliktir. Aslında basitlik sağlanması zor olan bir konudur. Basitlik, zorunlu işlerin yapılmasıdır. Gerekli olmayan bir şey varsa, kesinlikle bu konu XP basitlik ilkesi içerisinde olmamalıdır. Dünyadaki en zor şey gelecekte ne gibi ihtiyaçlarla karşılaşacağımızı bilmemektir. Bu nedenden dolayı oluşturulacak yapı, gelecekte ne gibi isterlerin ortaya çıkacağını tam olarak bilmeden oluşur. Buna göre esnek zaman ve maliyeti göz önüne alınmış bir yapı oluşturmak gerekmektedir. XP en iyi şekilde bu basitliği sağlamak için, bu günün ihtiyaçlarını hedef alarak esnek ve basit bir sistem gerçekleştirmeye çalışır.

12 Geri Besleme Sistemlerin geri dönüşümü olması sistemler için paha biçilemez bir fırsat yaratır. Geri dönüşüm sayesinde optimizasyonun oluşmasına engel olan tehlikeler ortadan kaldırılır. Öncelikle programcılar bütün sistemin mantıksal yapısını içeren bölüm testleri oluşturur. Programcılar sistem hakkında somut bilgiler elde ederler. Müşteriler yeni bir “stories” hikâye ile geldikleri zaman, programcılar hemen bu yeni gelen hikâyenin gerçekleşmesi ile ilgili çalışma yapıp bu “stories” e uygun bir çalışma gerçekleştirirler.

13 Cesaret XP in dört temel noktasından en zoru cesarettir. Projelerin üzerine yılmadan gidilmesi projelerin geliştirilmesi açısından son derece önemlidir. Cesaretin olmadığı projelerde korku gelişir ve gelişen bu korku projeyi başarısızlığa iter. Yazılım işlerindeki başarısızlık ise; yazılımın çöpe gitmesidir ve maalesef genel duruma da baktığımızda yazılımların büyük bir kısmının çöpe gittiğini görünyorur. Başarısızlık, genel tabiat içerisinde olan bir durumdur. Başarısızlıktan korkmak yerine başarısızlığı oluşturan nedenler üzerine gitmek yerinde olacaktır. Başarısızlıkla mümkün olunan en kısa sürede karşılaşmak, daha sonra telafi etme şansını arttırır.

14 Extreme Programming Korkmadıkları
Kodlama Değişen fikirler Geleceği bilmeden yol alabilmek Çalışan bir sistemin yapısının değişmesi Testler yazılması

15 Extreme Programing Roller
Müşteri Yazılım geliştirme sorumlusu Test sorumlusu Ölçüm sorumlusu Koç Danışman Yönetici

16 Extreme Programing Çalışma Mantığı

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 team’s 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 XP’s 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. 135–137. Figure 1 is an irrefutable proof of the axiom test early and test often.

34

35

36 Riskler ve Risk çözümleri
Gecikmeler Kısa sürüm zamanları Projenin iptal edilmesi İş acısından en önemli süreçlere önem verilmesi. Yama tutmayan sistemler Anlaşılır test senaryoları (otomatik test) Yanlış anlaşmalar Müşterinin takımın ayrılmaz bir üyesi olması sayesinde yanlış anlamaların büyük bir kısmı önlenir. İş dünyasındaki değişiklikler İhtiyaç duyulmayan birçok özellik Sadece en öncelikli işlerin yapılması İşten çıkmalar Çift programcı

37 References (1/2) Schach, S., R., “Object-Oriented & Classical Software Engineering”, 7th Ed., McGraw Hill, 2007. Borandağ, E., “Basamaklı CMMI Modeli ile Extreme Programming Metodunun Değerlendirilmesi”, Maltepe Üniversitesi, Fen Bilimleri Enstitüsü, Yüksek Lisans Tezi, 2006. Randell, B., “The 1968/69 NATO Software Engineering Reports”, 2009, World Wide Web: Sarıdoğan, E., “Yazılım Mühendisliği”, Papatya Yayıncılık, 2004. Beck, K., “eXtreme Programming”, Addison-Wesley, 2002. Agile Team 2005 “12 Practice”, 2009, World Wide Web: Acar, Ö., “Extreme Programming”, Pusula Yayıncılık, 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, Pages: , 2002. Paulk, M., C., “Extreme Programming from CMM Perspective”, IEEE Software, 2001. Borandağ, E., Yücalar, F., Erdoğan, Ş. Z., İnce, F., “Basamaklı CMMI Modeli ile Extreme Programming Metodunun Değerlendirilmesi”, Trakya Üniversitesi Fen Bilimleri Dergisi, ISSN: , 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. Kalaycı, O., “Uygulamalı CMMI/XP Eğitimi”, Nitelik Danışmanlık, 2006.

39 Additional Resources Mailing Lists Books
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 Sites AgileAlliance.com ExtremeProgramming.org Blogs