Praktyki techniczne
•
0 likes•616 views
Prezentacja z drugiego Jesiennego Wieczoru Scrum organizowanego przez Fluid Circle (fluidcircle.net).
![Jesienne Wieczory ze Scrum “ Praktyki techniczne ” ,[object Object]](https://image.slidesharecdn.com/2011-09-20jesiennywieczrzescrum-ii-110925132053-phpapp02/85/Praktyki-techniczne-1-320.jpg)
![Jesienne Wieczory ze Scrum O nas ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
Viewers also liked
Viewers also liked (8)
Similar to Praktyki techniczne
Similar to Praktyki techniczne (20)
More from Michał Parkoła
More from Michał Parkoła (16)
Praktyki techniczne
- 4. Wprowadzenie Jesienne Wieczory ze Scrum
- 13. Cechy dobrego projektu Jesienne Wieczory ze Scrum
- 14. Czynniki porażki Jesienne Wieczory ze Scrum
- 23. Przebieg procesu Jesienne Wieczory ze Scrum
- 24. Cechy dobrego projektu Jesienne Wieczory ze Scrum
- 25. Czynniki porażki Jesienne Wieczory ze Scrum
- 26. Praktyki techniczne Jesienne Wieczory ze Scrum
- 28. The Joel Test by Joel Spolsky Jesienne Wieczory ze Scrum
- 33. Funkcja 1 Funkcja 2 … Unit Test Unit Test Unit Test Integration Test T est D riven D evelopment Jesienne Wieczory ze Scrum
- 51. Prototypowanie Jesienne Wieczory ze Scrum
- 60. Jesienne Wieczory ze Scrum
- 62. Zakończenie Jesienne Wieczory ze Scrum
- 66. Dziękujemy! Jesienne Wieczory ze Scrum
Editor's Notes
- http://allankelly.blogspot.com/2011/01/scrum-technical-practices-xp.html http://allankelly.blogspot.com/2009/05/thoughts-after-jeff-sutherland-at-accu.html http://www1.standishgroup.com/newsroom/chaos_2009.php
- http://en.wikipedia.org/wiki/Joel_Spolsky http://www.joelonsoftware.com/articles/fog0000000043.html
- http://en.wikipedia.org/wiki/Joel_Spolsky http://www.joelonsoftware.com/articles/fog0000000043.html
- http://pl.wikipedia.org/wiki/Test-driven_development http://pl.wikipedia.org/wiki/Kent_Beck http://www.youtube.com/watch?v=f60aIlNhMoE TDD jest techniką tworzenia oprogramowania polegająca na utworzeniu testu metody wymaganej do poprawnego funkcjonowania naszego oprogramowania zanim napiszemy faktyczny kod wykonujący pożądane operacje. http://www.youtube.com/watch?v=uGaNkTahrIw&feature=related http://www.youtube.com/watch?v=SO_Pl7Khiw4
- http://pl.wikipedia.org/wiki/Test-driven_development http://pl.wikipedia.org/wiki/Kent_Beck http://www.youtube.com/watch?v=f60aIlNhMoE http://www.youtube.com/watch?v=uGaNkTahrIw&feature=related http://www.youtube.com/watch?v=SO_Pl7Khiw4
- http://pl.wikipedia.org/wiki/Test-driven_development http://pl.wikipedia.org/wiki/Kent_Beck http://www.youtube.com/watch?v=f60aIlNhMoE TDD jest techniką tworzenia oprogramowania polegająca na utworzeniu testu metody wymaganej do poprawnego funkcjonowania naszego oprogramowania zanim napiszemy faktyczny kod wykonujący pożądane operacje. http://www.youtube.com/watch?v=uGaNkTahrIw&feature=related http://www.youtube.com/watch?v=SO_Pl7Khiw4
- Analogia do Samochodu
- http://pl.wikipedia.org/wiki/Test-driven_development http://pl.wikipedia.org/wiki/Kent_Beck http://www.youtube.com/watch?v=f60aIlNhMoE TDD jest techniką tworzenia oprogramowania polegająca na utworzeniu testu metody wymaganej do poprawnego funkcjonowania naszego oprogramowania zanim napiszemy faktyczny kod wykonujący pożądane operacje. http://www.youtube.com/watch?v=uGaNkTahrIw&feature=related http://www.youtube.com/watch?v=SO_Pl7Khiw4
- http://pl.wikipedia.org/wiki/Test-driven_development http://pl.wikipedia.org/wiki/Kent_Beck http://www.youtube.com/watch?v=f60aIlNhMoE TDD jest techniką tworzenia oprogramowania polegająca na utworzeniu testu metody wymaganej do poprawnego funkcjonowania naszego oprogramowania zanim napiszemy faktyczny kod wykonujący pożądane operacje. http://www.youtube.com/watch?v=uGaNkTahrIw&feature=related http://www.youtube.com/watch?v=SO_Pl7Khiw4
- http://pl.wikipedia.org/wiki/Test-driven_development http://pl.wikipedia.org/wiki/Kent_Beck http://www.youtube.com/watch?v=f60aIlNhMoE TDD jest techniką tworzenia oprogramowania polegająca na utworzeniu testu metody wymaganej do poprawnego funkcjonowania naszego oprogramowania zanim napiszemy faktyczny kod wykonujący pożądane operacje. http://www.youtube.com/watch?v=uGaNkTahrIw&feature=related http://www.youtube.com/watch?v=SO_Pl7Khiw4
- Ale po co to wszystko? Jakie są z tego korzyści? A jak najbardziej są. Do 3 podstawowych można wymienić, chociażby: Zapewnienie jakości – poprzez ten punkt rozumiem jakość kodu która jest istotna od strony wytwarzania oprogramowania oraz sama jakość produktu z perspektywy oceny biznesowej, ponieważ jeżeli test pojawia się na początku mamy pewność że oddajemy klientowi przetestowane oprogramowanie, eliminując znacznie ilość potencjalnych błędów, zwiększamy zadowolenie z produktu, zmniejszamy nakład czasu potrzebny na bug fixing
- TODO: Dodać grafikę repozytoriów Dodac grafikę grafu zmian, branch, label itp
- http://pl.wikipedia.org/wiki/Subversion http://pl.wikipedia.org/wiki/TortoiseSVN http://en.wikipedia.org/wiki/Team_Foundation_Server http://www.youtube.com/watch?v=FUKfAOtTLI8 http://en.wikipedia.org/wiki/Revision_control Opisać sposób tworzenia nowych branch’y na podstawie etykiet Narysować to co było w wideo !!! TODO: - grafika do scentralizowanego repozytorium
- http://www.youtube.com/watch?v=RDGzF2M-zlo http://www.youtube.com/watch?v=xSGxV1pc21M&feature=related http://www.youtube.com/watch?v=OFkgSjRnay4&feature=related Git vs Mercurial http://stackoverflow.com/questions/35837/what-is-the-difference-between-mercurial-and-git http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/ http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/ http://mercurial.selenic.com/wiki/GitConcepts http://www.youtube.com/watch?v=MLLkJ2rngk0 – Bardzo ważne wyjaśnienie różnicy P1 http://www.youtube.com/watch?NR=1&v=dDJOb2wGLjY – Bardzo ważne wyjaśnienie różnicy P2 TODO: - grafika do rozproszonego repozytorium
- Ale po co to wszystko? Jakie są z tego korzyści? A jak najbardziej są. Do 3 podstawowych można wymienić, chociażby: Zapewnienie jakości – poprzez ten punkt rozumiem jakość kodu która jest istotna od strony wytwarzania oprogramowania oraz sama jakość produktu z perspektywy oceny biznesowej, ponieważ jeżeli test pojawia się na początku mamy pewność że oddajemy klientowi przetestowane oprogramowanie, eliminując znacznie ilość potencjalnych błędów, zwiększamy zadowolenie z produktu, zmniejszamy nakład czasu potrzebny na bug fixing
- http://www.youtube.com/watch?v=ET3Q6zNK3Io TODO: Grafika z wyścigów, Grafika 2 osoby przy komputerze
- http://www.youtube.com/watch?v=ET3Q6zNK3Io
- http://www.youtube.com/watch?v=ET3Q6zNK3Io
- http://www.youtube.com/watch?v=ET3Q6zNK3Io
- http://www.youtube.com/watch?v=ET3Q6zNK3Io
- http://www.youtube.com/watch?v=ET3Q6zNK3Io
- - Jak to się przekłada na Scrum -
- Jak to się przekłada na Scrum - http://en.wikipedia.org/wiki/Continuous_integration http://www.youtube.com/watch?v=RcTFpNlkiUs http://www.youtube.com/watch?v=wGfsv4CmJwg
- Jak to się przekłada na Scrum - http://en.wikipedia.org/wiki/Continuous_integration http://www.youtube.com/watch?v=RcTFpNlkiUs http://www.youtube.com/watch?v=wGfsv4CmJwg
- Jak to się przekłada na Scrum - http://en.wikipedia.org/wiki/Continuous_integration http://www.youtube.com/watch?v=RcTFpNlkiUs http://www.youtube.com/watch?v=wGfsv4CmJwg
- Jak to się przekłada na Scrum - http://en.wikipedia.org/wiki/Continuous_integration http://www.youtube.com/watch?v=RcTFpNlkiUs http://www.youtube.com/watch?v=wGfsv4CmJwg
- http://www.12meses12katas.com/
- What is a Code Kata? Code Katas were originally created by Dave Thomas of the Pragmatic Programmers as small exercises/problems to solve. They were generally small with an interesting twist, or two. You can find more information on the Code Katas site . Over time, the concept of katas grew from a problem to solve to a solution to practice. Uncle Bob Martin (among others) began talking about the idea of practicing the solution to a kata until the steps and keystrokes became like second nature, and you could do them without thinking. In this way, you can internalize the process/technique you are practicing until it is ‘under your fingers.’ I gave a lightning talk at Acts As Conference 2009 on this idea.