Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00363 010309 11037733 na godz. na dobę w sumie
Agile Development. Filozofia programowania zwinnego - książka
Agile Development. Filozofia programowania zwinnego - książka
Autor: , Liczba stron: 480
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-1614-5 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> techniki programowania
Porównaj ceny (książka, ebook, audiobook).

Zbiór praktycznych wskazówek dla producentów oprogramowania

Programowanie zwinne (Agile Development) to obecnie jedna z najpopularniejszych metodologii zarządzania projektami programistycznymi. Metodyka Agile jest szczególnie użyteczna w małych zespołach programistycznych, w których z racji ułatwionej komunikacji nie ma potrzeby tworzenia rozbudowanej dokumentacji. Programowanie zwinne opiera się na iteracyjnej realizacji kolejnych etapów projektu. Kluczem do sukcesu w tej metodzie jest efektywna współpraca między członkami zespołu projektowego.

Książka 'Agile Development. Filozofia programowania zwinnego' to przewodnik po programowaniu ekstremalnym, oznaczanym zwykle skrótem XP, które jest jedną z technik wchodzących w skład tej metodyki. Czytając ją, dowiesz się, jak wdrażać metodologię Agile w firmie, na czym polega programowanie ekstremalne i jaką rolę w procesie pełnią poszczególni członkowie grupy projektowej. Nauczysz się budować zespół i określać zakresy zadań osób biorących udział w pracach, planować harmogram udostępniania kolejnych wersji produktu oraz kierować procesem jego tworzenia. Poznasz metody testowania programu i usuwania z niego błędów, zasady pisania dokumentacji oraz reguły prowadzenia spotkań roboczych z klientami.

Od filozofii do mistrzostwa w zwinnym programowaniu!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Agile Development. Filozofia programowania zwinnego Autor: James Shore, Shane Warden ISBN: 978-83-246-1614-5 Tytu‡ orygina‡u: The Art of Agile Development Format: 168x237, stron: 480 Zbi(cid:243)r praktycznych wskaz(cid:243)wek dla producent(cid:243)w oprogramowania (cid:149) Jak wdro¿y(cid:230) metodologiŒ programowania zwinnego? (cid:149) W jaki spos(cid:243)b zaanga¿owa(cid:230) klient(cid:243)w w projekt? (cid:149) Jak kontrolowa(cid:230) jako(cid:156)(cid:230) produkt(cid:243)w? Programowanie zwinne (Agile Development) to obecnie jedna z najpopularniejszych metodologii zarz„dzania projektami programistycznymi. Metodyka Agile jest szczeg(cid:243)lnie u¿yteczna w ma‡ych zespo‡ach programistycznych, w kt(cid:243)rych z racji u‡atwionej komunikacji nie ma potrzeby tworzenia rozbudowanej dokumentacji. Programowanie zwinne opiera siŒ na iteracyjnej realizacji kolejnych etap(cid:243)w projektu. Kluczem do sukcesu w tej metodzie jest efektywna wsp(cid:243)‡praca miŒdzy cz‡onkami zespo‡u projektowego. Ksi„¿ka (cid:132)Agile Development. Filozofia programowania zwinnego(cid:148) to przewodnik po programowaniu ekstremalnym, oznaczanym zwykle skr(cid:243)tem XP, kt(cid:243)re jest jedn„ z technik wchodz„cych w sk‡ad tej metodyki. Czytaj„c j„, dowiesz siŒ, jak wdra¿a(cid:230) metodologiŒ Agile w firmie, na czym polega programowanie ekstremalne i jak„ rolŒ w procesie pe‡ni„ poszczeg(cid:243)lni cz‡onkowie grupy projektowej. Nauczysz siŒ budowa(cid:230) zesp(cid:243)‡ i okre(cid:156)la(cid:230) zakresy zadaæ os(cid:243)b bior„cych udzia‡ w pracach, planowa(cid:230) harmogram udostŒpniania kolejnych wersji produktu oraz kierowa(cid:230) procesem jego tworzenia. Poznasz metody testowania programu i usuwania z niego b‡Œd(cid:243)w, zasady pisania dokumentacji oraz regu‡y prowadzenia spotkaæ roboczych z klientami. (cid:149) Wdra¿anie programowania zwinnego (cid:149) Techniki programowania ekstremalnego (cid:149) Cz‡onkowie zespo‡u XP (cid:149) Zarz„dzanie zespo‡em (cid:149) Anga¿owanie klienta w proces wytw(cid:243)rczy (cid:149) Tworzenie raport(cid:243)w (cid:149) UdostŒpnianie kolejnych wersji systemu (cid:149) Standardy pisania kodu (cid:149) Testowanie i usuwanie b‡Œd(cid:243)w (cid:149) Optymalizacja wydajno(cid:156)ci programu Od filozofii do mistrzostwa w zwinnym programowaniu! Wydawnictwo Helion ul. Ko(cid:156)ciuszki 1c 44-100 Gliwice tel. 032 230 98 63 e-mail: helion@helion.pl Spis treļci Wprowadzenie ..............................................................................................................9 Zaczynamy Czýļë I 1. Dlaczego zwinne programowanie? ............................................................................ 19 20 21 22 23 Czym jest sukces? Poza harmonogram Znaczenie sukcesów na poziomie organizacji Wkraczanie w Ĉwiat zwinnego programowania 2. Jak byë zwinnym? ........................................................................................................25 26 27 27 28 Zwinne metody Czy warto wymyĈlaè wäasne metody? Droga do mistrzostwa Szukanie mentora 3. Zrozumieë XP ...............................................................................................................29 32 42 55 Cykl Ĕycia w XP Zespóä w XP Pojöcia zwiñzane z XP 4. Wprowadzanie XP ....................................................................................................... 61 61 71 83 Czy XP to coĈ dla nas? Naprzód! Ocena zwinnoĈci zespoäu 5 Czýļë II Stosowanie XP 5. Myļlenie ....................................................................................................................... 91 93 102 107 112 115 Programowanie w parach Energiczna praca Informacyjne miejsce pracy Analizy przyczynowo-skutkowe Retrospekcje 6. Wspóĥpraca ................................................................................................................ 123 126 137 147 152 157 161 167 174 Zaufanie Wspólna praca ZaangaĔowanie prawdziwego klienta Wspólny jözyk Krótkie spotkania robocze Standardy pisania kodu Demonstracje iteracji Raporty 7. Udostýpnianie ............................................................................................................ 183 186 191 202 211 219 229 234 „W peäni gotowe” Brak bäödów Kontrola wersji Dziesiöciominutowa kompilacja Ciñgäa integracja WspóäwäasnoĈè kodu Dokumentacja 8. Planowanie ................................................................................................................239 241 247 262 268 278 293 301 309 Wizja Planowanie wydania Gra planistyczna Zarzñdzanie ryzykiem Planowanie iteracji Zapas OpowieĈci Szacowanie 9. Wytwarzanie .............................................................................................................323 325 331 339 Stopniowe zbieranie wymagaþ Testy klienta Wytwarzanie sterowane testami 6 S P I S T R E Ļ C I Refaktoryzacja Prosty projekt Stopniowy rozwój projektu i architektury Rozwiñzania punktowe Optymalizacja wydajnoĈci Testy eksploracyjne 360 372 380 391 395 402 Czýļë III Mistrzostwo w dziedzinie programowania zwinnego 10. Wartoļci i zasady ....................................................................................................... 415 415 416 417 Wspólne elementy O wartoĈciach, zasadach i praktykach Dalsza lektura 11. Usprawnianie procesu ............................................................................................... 419 419 420 421 Zrozumienie projektu Dopracowywanie i adaptacja ãamanie reguä 12. Poleganie na ludziach ...............................................................................................425 425 427 429 Budowanie efektywnych zwiñzków Odpowiednie osoby do odpowiednich zadaþ Budowanie procesu dla ludzi 13. Eliminowanie marnotrawstwa ................................................................................. 431 431 433 435 436 Praca w maäych, odwracalnych etapach Szybkie wykrywanie niepowodzeþ Maksymalizacja liczby zadaþ, których nie trzeba wykonywaè DñĔenie do wysokiej przepustowoĈci 14. Zapewnianie wartoļci ...............................................................................................439 439 441 442 444 Wykorzystanie zwinnoĈci WartoĈè ma tylko kod gotowy do udostöpnienia Zapewnianie wyników biznesowych Czöste udostöpnianie 15. DéŜenie do doskonaĥoļci technicznej .......................................................................447 447 448 449 449 Oprogramowanie nie istnieje Projekt to narzödzie uäatwiajñce zrozumienie Równowaga w projektach Nienazwana cecha S P I S T R E Ļ C I 7 Doskonaäy projekt Ogólne zasady projektowania Zasady w praktyce DñĔenie do mistrzostwa 450 451 454 456 Literatura cytowana ..................................................................................................457 Skorowidz ..................................................................................................................463 8 S P I S T R E Ļ C I ROZDZIAĤ 1 Dlaczego zwinne programowanie? Zwinne wytwarzanie oprogramowania (ang. agile development) jest popularne. Wszystkie „fajne” firmy korzystajñ z tego podejĈcia: Google, Yahoo, Symantec, Microsoft i tak dalej1. Znam firmö, która zmieniäa nazwö na Agili-coĈtam, aby przyäñczyè siö do trendu. Organizacja ta zadzwoniäa do mnie z proĈbñ, abym usprawniä ich „zwinne procesy”, które po dokäadniejszej analizie okazaäy siö niczym wiöcej jak zlecaniem programowania firmom zewnötrznym w innym kraju niĔ zwykle. Oczekujö, Ĕe w bardzo niedalekiej przyszäoĈci w ofercie duĔych firm konsultingowych pojawiñ siö Certyfikowane zwinne procesy i Certyfikowani konsultanci do spraw zwinnego programowania. Proszö, nie dajcie siö wciñgnñè w ten baäagan. W 1986 roku Brooks zapowiedziaä, Ĕe uniwersalne rozwiñzania nie powstanñ, Ĕe do roku 1996 Ĕadna pojedyncza technologia ani technika zarzñdzania nie doprowadzi do dziesiöciokrotnego wzrostu produktywnoĈci, niezawodnoĈci lub prostoty [Brooks]. I rzeczywiĈcie, nikomu siö to nie udaäo. RównieĔ zwinne wytwarzanie oprogramowania nie jest uniwersalnym rozwiñzaniem. Co wiöcej, nie zalecam stosowania zwinnego programowania, jeĈli ma säuĔyè wyäñcznie zwiökszeniu produktywnoĈci. Zalety tego podejĈcia — takĔe moĔliwoĈè czöstszego udostöpniania oprogramowania — wynikajñ z odmiennego trybu pracy, a nie z szybszego wykonywania zadaþ. Choè wedäug anegdotycznych wzmianek zespoäy stosujñce zwinne programowanie wykazujñ siö ponadprzeciötnñ wydajnoĈciñ2, efekt ten nie powinien byè gäównñ przyczynñ wprowadzania tego podejĈcia. Zespóä potrzebuje czasu na opanowanie zwinnego wytwarzania oprogramowania. W trakcie nauki — a moĔe to zajñè kwartaä lub dwa — czäonkowie grupy bödñ pracowaè wolniej, a nie szybciej. Ponadto nacisk na produktywnoĈè czasem zachöca zespóä do stosowania uproszczeþ i mniejszego rygoru w pracy, co moĔe doprowadziè do spadku wydajnoĈci. 1 đródäo: róĔne raporty uĔytkowników na konferencjach poĈwiöconych programowaniu ekstremalnemu i zwinnemu programowaniu. 2 Zobacz na przykäad [Van Schooenderwoert], [Mah] i [Anderson 2006]. 1 9 Zwinne wytwarzanie oprogramowania jest obecnie modne, ale to nie powód, aby stosowaè to podejĈcie. W trakcie podejmowania decyzji dotyczñcej jego wprowadzenia waĔna jest odpowiedĒ na tylko jedno pytanie. Czy zwinne wytwarzanie oprogramowania pomoĔe w osiñganiu wiökszych sukcesów? Kiedy zespóä odpowie na to pytanie, bödzie wiedziaä, czy powinien stosowaè zwinne programowanie. Czym jest sukces? Tradycyjnie sukces utoĔsamiany jest z dostarczeniem produktu na czas, w oczekiwanej cenie i zgodnie ze specyfikacjñ. Standish prezentuje kilka klasycznych definicji [Standish]: Udane „Oprogramowanie ukoþczono na czas, po oczekiwanych kosztach, z mechanizmami i funkcjami zgodnymi z wyjĈciowñ specyfikacjñ”. Mimo popularnoĈci tych definicji, czegoĈ w nich brakuje. Z problemami „Oprogramowanie jest gotowe i dziaäa, ale przekroczono budĔet oraz harmonogram, a mechanizmy i funkcje sñ uboĔsze niĔ w wyjĈciowej specyfikacji”. Nieudane „W pewnym miejscu cyklu rozwoju rozwój oprogramowania anulowano”. Mimo popularnoĈci tych definicji, nie sñ one w peäni poprawne. Projekt moĔe byè udany, nawet jeĈli producent nie zarobi na nim ani grosza. Z kolei nawet jeĈli przyniesie milionowe zyski, moĔna go uznaè za problematyczny. W magazynie „CIO” znajduje siö komentarz do tej osobliwoĈci: Nawet te projekty, które speäniajñ wszystkie tradycyjne kryteria powodzenia — w zakresie czasu, budĔetu i specyfikacji — mogñ okazaè siö nieudane, poniewaĔ produkty nie sñ atrakcyjne dla uĔytkowników lub w ostatecznym rozrachunku nie zapewniajñ firmie korzyĈci. […] Podobnie, projekty uznawane za nieudane wedäug tradycyjnych miar z branĔy IT mogñ okazaè siö sukcesem, kiedy — mimo problemów w obszarze kosztów, czasu lub specyfikacji — system jest uwielbiany przez odbiorców i zapewnia nieoczekiwane korzyĈci. Na przykäad w firmie Ĉwiadczñcej usäugi finansowe nowy system […] zostaä dostarczony z szeĈciomiesiöcznym opóĒnieniem i kosztowaä ponad dwa razy wiöcej, niĔ zakäadano (ostateczny koszt wyniósä 5,7 miliona dolarów). Jednak projekt zwiökszyä elastycznoĈè organizacji (po 13 miesiñcach) i oceniono go jako wielki sukces. WysokoĈè umarzanych kredytów spadäa o 33 miliony dolarów, a krótszy czas potrzebny na zapewnienie korzyĈci i wyĔsza wydajnoĈè doprowadziäy do 50-procentowego wzrostu w liczbie jednoczeĈnie prowadzonych testów strategii Ĉciñgania wierzytelnoĈci3. 3 Nelson R. Ryan, Applied Insight — Tracks in the Snow, „CIO Magazine”. http://www.cio.com/archive/090106/ ´applied.html. 2 0 R O Z D Z I A Ĥ 1 . D L A C Z E G O Z W I N N E P R O G R A M O W A N I E ? Poza harmonogram Sukces musi zaleĔeè od czegoĈ innego niĔ mieszczenie siö w terminie, ale od czego? Kiedy byäem dzieckiem, cieszyäa mnie sama zabawa. Uwielbiaäem wyzwania zwiñzane z programowaniem. KaĔde uruchomienie aplikacji traktowaäem jak wielkie zwyciöstwo. Wtedy nawet program, który nie dziaäaä, traktowaäem jak pewnego rodzaju sukces, jeĈli tylko tworzenie go sprawiaäo mi radoĈè. Powodzenie postrzegaäem gäównie w kategoriach osobistych nagród. Kiedy nabraäem doĈwiadczenia, zaczñäem pisaè bardziej skomplikowane programy i czösto gubiäem siö w ich dziaäaniu. Musiaäem porzuciè niektóre projekty przed ich ukoþczeniem. Zaczñäem wierzyè, Ĕe kluczem do sukcesu jest äatwoĈè konserwacji. SpostrzeĔenie to potwierdziäo siö, kiedy podjñäem pracö i zaczñäem wspóäpracowaè z zespoäami innych programistów. Byäem z siebie dumny, kiedy napisaäem kod, który byä elegancki i äatwy w konserwacji. Sukces oznaczaä wtedy doskonaäoĈè technicznñ. Niektóre projekty koþczñ siö niepowodzeniem mimo dobrego kodu. Nawet doskonale przeprowadzone projekty mogñ byè nieciekawe dla uĔytkowników. Doszedäem do wniosku, Ĕe zespóä projektowy, w którym pracujö, jest czöĈciñ wiökszego systemu, obejmujñcego dziesiñtki, setki, a nawet tysiñce osób. Produkty majñ zapewniaè zadowolenie ich wszystkich, a przede wszystkim tych, którzy odpowiadajñ za wysokoĈè mojej pensji. Dla osób, które opäacajñ pracö, wartoĈè oprogramowania musi przewyĔszaè jego koszty. Sukces oznaczania zapewnianie korzyĈci firmie. Przedstawione definicje nie sñ ze sobñ sprzeczne. WaĔny jest sukces na wszystkich trzech poziomach (zobacz rysunek 1.1). Bez powodzenia na poziomie osobistym twórca bödzie miaä problemy z umotywowaniem siebie i pracowników. Bez sukcesu technicznego kod Ēródäowy w pewnym momencie zaäamie siö pod swym ciöĔarem. Przy braku powodzenia na poziomie organizacji moĔe siö okazaè, Ĕe zespóä nie jest juĔ potrzebny. Rysunek 1.1. Oblicza sukcesu P O Z A H A R M O N O G R A M 2 1 Znaczenie sukcesów na poziomie organizacji Zespoäy programistyczne czösto zaniedbujñ sukces na poziomie firmy na rzecz äatwiejszego do osiñgniöcia powodzenia technicznego i osobistego. NaleĔy jednak pamiötaè o tym, Ĕe nawet jeĈli dana osoba nie bierze odpowiedzialnoĈci za sukces organizacji, jej przeäoĔeni oceniajñ zespóä na tym poziomie. WyĔsza kadra zarzñdzajñca i dyrektorzy wykonawczy prawdopodobnie nie bödñ zwracaè uwagi na to, czy oprogramowanie jest eleganckie, äatwe w konserwacji, a nawet lubiane przez uĔytkowników. Dla przeäoĔonych liczñ siö wyniki, czyli zwrot z inwestycji w projekt. JeĈli zespóä nie osiñga sukcesów w tym obszarze, menedĔerowie podejmñ dziaäania, które zapewniñ powodzenie. Niestety, wyĔsza kadra zarzñdzajñca zwykle nie ma czasu lub odpowiedniej perspektywy, aby w kaĔdym projekcie stosowaè wyrafinowane rozwiñzania. Dlatego czöĈciej uĔywajñ miecza niĔ skalpela i säusznie oczekujñ, Ĕe to zespóä projektowy zajmie siö szczegóäami. Kiedy menedĔerowie sñ niezadowoleni z wyników zespoäu, wyciñgajñ miecze. Najbardziej oczywisty obiekt ciöè to koszty. Sñ dwa proste sposoby na ich zmniejszenie: bardzo krótkie terminy, które majñ skróciè czas wytwarzania, oraz zlecanie zadaþ firmom majñcym siedziby w paþstwach o niĔszych kosztach pracy. MoĔna teĔ zastosowaè oba te rozwiñzania jednoczeĈnie. Sñ to jednak nieeleganckie techniki. Krótkie terminy czösto wydäuĔajñ czas pracy zamiast go skracaè [McConnell 1999, s. 220], a zlecanie zadaþ firmom zewnötrznym wiñĔe siö z ukrytymi kosztami [Overby]. Czy krótkie terminy i groĒba zlecenia zadaþ firmom zewnötrznym brzmiñ znajomo? JeĈli tak, pora na wziöcie przez zespóä odpowiedzialnoĈci za sukces, i to nie tylko osobisty i techniczny, ale takĔe na poziomie organizacji. CO CENIè ORGANIZACJE? Choë wartoļë niektórych projektów wynika bezpoļrednio ze sprzedaŜy, korzyļci organizacji obejmujé takŜe czynniki inne niŜ dochody. Projekty zapewniajé wartoļë na wiele sposobów i nie zawsze moŜna wycenië je w zĥotówkach i groszach. MoŜna wyróŜnië nastýpujéce Śródĥa wartoļci (obok dochodów i oszczýdnoļci)4: x odróŜnianie siý od konkurencji; x kreowanie marki; x wzrost lojalnoļci klientów; x speĥnianie wymagaħ prawnych; x oryginalne badania; x informacje strategiczne. 4 Oparte czöĈciowo na [Danne i Cleland-Huang]. 2 2 R O Z D Z I A Ĥ 1 . D L A C Z E G O Z W I N N E P R O G R A M O W A N I E ? Wkraczanie w ļwiat zwinnego programowania Czy zwinne wytwarzanie oprogramowania pomoĔe zespoäowi w osiñganiu wiökszych sukcesów? MoĔliwe. Zwinne programowanie koncentruje siö osiñganiu celów osobistych, technicznych oraz organizacji. JeĈli zespóä ma problemy w którymĈ z tych obszarów, wdroĔenie zwinnego wytwarzania oprogramowania moĔe okazaè siö pomocne. Sukces na poziomie organizacji Zwinne metody pozwalajñ osiñgnñè sukces na poziomie organizacji poprzez koncentracjö na zapewnianiu wartoĈci i zmniejszaniu kosztów. BezpoĈrednio przekäada siö to na wyĔszy zwrot z inwestycji. Zwinne metody powodujñ takĔe wczesne ustalanie oczekiwaþ, dlatego jeĈli projekt nie prowadzi do sukcesu organizacji, wiadomo o tym na tyle wczeĈnie, Ĕe moĔna anulowaè go przed poniesieniem wysokich nakäadów. Zespoäy stosujñce zwinne programowanie zwiökszajñ wartoĈè dziöki wäñczeniu w pracö ekspertów biznesowych i skoncentrowaniu wysiäków na podstawowych wartoĈciach, które projekt ma zapewniaè organizacji. W projektach realizowanych zgodnie ze zwinnym podejĈciem jako pierwsze przygotowywane sñ najbardziej wartoĈciowe funkcje, a zespóä czösto udostöpnia nowe wersje, co znacznie zwiöksza wartoĈè. Kiedy zmieniñ siö potrzeby biznesowe lub zespóä zdobödzie nowe informacje, moĔna zmieniè kierunek prac, aby dostosowaè go do zaistniaäej sytuacji. DoĈwiadczone zespoäy stosujñce zwinne podejĈcie poszukujñ nieoczekiwanych moĔliwoĈci, które pozwolñ ulepszyè plan dziaäania. Takie zespoäy pozwalajñ zmniejszyè koszty. Po czöĈci wynika to z doskonaäoĈci technicznej. W najlepszych zwinnych projektach pojawia siö tylko kilka bäödów miesiöcznie. Mniejsze jest takĔe marnotrawstwo, co jest efektem wczesnego anulowania säabych projektów i zastöpowania kosztownych praktyk rozwoju prostszymi. Komunikacja w zwinnych zespoäach jest szybka i precyzyjna, a praca jest moĔliwa nawet w przypadku nieobecnoĈci kluczowych osób. Czäonkowie regularnie kontrolujñ proces i nieustannie usprawniajñ kod, dziöki czemu konserwacja oprogramowania i wprowadzanie w nim poprawek sñ äatwiejsze. Sukces techniczny Programowanie ekstremalne, czyli zwinna metoda, na której koncentrujö siö w tej ksiñĔce, szczególnie dobrze nadaje siö do zapewniania sukcesu technicznego. ProgramiĈci stosujñcy XP wspóäpracujñ ze sobñ, co pomaga im kontrolowaè drobne szczegóäy istotne w doskonaäych produktach, a jednoczeĈnie gwarantuje, Ĕe kaĔdy fragment kodu przejrzñ przynajmniej dwie osoby. ProgramiĈci nieustannie integrujñ kod, co umoĔliwia zespoäowi udostöpnienie oprogramowania w kaĔdym momencie, kiedy ma to sens biznesowy. Caäy zespóä koncentruje siö na caäkowitym ukoþczeniu jednej funkcji przed przystñpieniem do pracy nad nastöpnñ. Zapobiega to nieoczekiwanym opóĒnieniom w momencie udostöpniania produktu i umoĔliwia swobodne zmienianie kierunku. Programowanie ekstremalne obejmuje, obok struktury rozwoju, zaawansowane praktyki techniczne, które prowadzñ do osiñgniöcia doskonaäoĈci technicznej. Najbardziej znanñ technikñ jest wytwarzanie sterowane testami. Pomaga ono pisaè kod, który dziaäa dokäadnie tak, jak programiĈci tego oczekujñ. Zespoäy stosujñce XP tworzñ takĔe proste, nieustannie zmieniajñce siö projekty, które moĔna äatwo zmodyfikowaè przy zmianie planów. W K R A C Z A N I E W Ļ W I A T Z W I N N E G O P R O G R A M O W A N I A 2 3 Sukces osobisty Sukces osobisty jest, no cóĔ, osobisty. Zwinne programowanie moĔe nie speäniaè wszystkich wymagaþ w obszarze sukcesu osobistego. Jednak po przyzwyczajeniu siö do tej techniki uĔytkownik, niezaleĔnie od zajmowanego stanowiska, prawdopodobnie odkryje wiele jej zalet. Kierownictwo i wyĔsza kadra zarzñdzajñca Te osoby doceniñ däugowiecznoĈè oprogramowania i koncentracjö zespoäu na zapewnianiu wysokiego zwrotu z inwestycji. UĔytkownicy, udziaäowcy, eksperci z dziedziny i menedĔerowie produktu Te osoby doceniñ wpäyw, jaki majñ na kierunek rozwoju oprogramowania, a takĔe koncentracjö zespoäu na dostarczeniu uĔytecznych i wartoĈciowych programów oraz wysokñ czöstotliwoĈè udostöpniania wersji. MenedĔerowie produktu i projektu MenedĔerowie doceniñ moĔliwoĈè zmiany kierunku prac w obliczu nowych potrzeb biznesowych, zdolnoĈè zespoäu do podejmowania i speäniania zobowiñzaþ oraz wyĔsze zadowolenie udziaäowców. ProgramiĈci ProgramiĈci doceniñ wyĔszñ jakoĈè pracy wynikajñcñ z podniesienia jakoĈci technicznej, wiökszego wpäywu na szacunki i harmonogramy oraz niezaleĔnoĈci zespoäu. Testerzy Testerzy doceniñ traktowanie ich jak peänoprawnych czäonków zespoäu, moĔliwoĈè wpäywu na jakoĈè na wszystkich etapach projektu oraz bardziej wymagajñcñ i mniej schematycznñ pracö. Praca w zwinnych zespoäach to jeden z najprzyjemniejszych okresów w mojej karierze. Wystarczy, Ĕe wyobraĔö sobie przyjacielskñ atmosferö w zespole, który wspóäpracuje w celu zaprojektowania i udostöpnienia produktu o trwaäej wartoĈci, gdzie kaĔdy czäonek grupy z entuzjazmem przyczynia siö do skutecznego dziaäania caäoĈci. WyobraĔö sobie branie odpowiedzialnoĈci za dany obszar — techniczny, biznesowych lub zwiñzany z zarzñdzaniem — i zaufanie reszty zespoäu do moich zawodowych sñdów i umiejötnoĈci. JakĔe przyjemne jest rozwiñzywanie problemów projektowych i obserwowanie poprawy jakoĈci. Zwinne programowanie zmienia obraz branĔy. Rozwój i udostöpnianie oprogramowania w nowy sposób wymaga duĔo pracy i pomyĈlunku. Jednak jeĈli zespóä stosuje omawiane podejĈcie spójnie i przestrzegajñc wszelkich zasad, moĔe uzyskaè niezwykäe wyniki. Bödzie regularnie wytwarzaä naprawdö wartoĈciowe oprogramowanie i kaĔdego tygodnia demonstrowaä postöpy. Ponadto rozwój oprogramowania stanie siö przyjemniejszy niĔ kiedykolwiek wczeĈniej. Wszyscy gotowi? Zaczynamy. 2 4 R O Z D Z I A Ĥ 1 . D L A C Z E G O Z W I N N E P R O G R A M O W A N I E ?
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Agile Development. Filozofia programowania zwinnego
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: