Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00099 008441 10460629 na godz. na dobę w sumie
Szybkie projektowanie. Zapanuj nad chaosem zadań i presją czasu - ebook/pdf
Szybkie projektowanie. Zapanuj nad chaosem zadań i presją czasu - ebook/pdf
Autor: Liczba stron: 624
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-3271-3 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> grafika komputerowa >> inne
Porównaj ceny (książka, ebook (-20%), audiobook).

Zespoły projektowe borykają się z ciągłym niedostatkiem czasu. Napięte do granic możliwości terminy wymuszają na software developerach narzucenie morderczego tempa pracy. Takie podejście sprawia, że albo dostarczony produkt nie spełnia oczekiwań, albo nie udaje się dotrzymać terminu. Co gorsza, ciągła praca pod presją czasu powoduje chroniczne przemęczenie i problemy zdrowotne, nie wspominając już o braku sił i czasu na rozwój, który w branży IT ma kolosalne znaczenie.

Książka ta jest praktycznym, zdroworozsądkowym poradnikiem metod projektowania. Opisane w tej książce strategie pracy pozwolą na usprawnienie procesu projektowego i przyśpieszenie go. Przedstawiono tu również takie zagadnienia, jak zarządzanie ryzykiem, podstawy projektowania aplikacji oraz planowanie cyklu życia projektu. Mimo że nie są bezpośrednio związane z metodami szybkiego projektowania, to jednak mają kluczowe znaczenie dla produktywności zespołu. Naturalnie, nie istnieje jedna magiczna metoda przydatna w każdych warunkach — w tej książce opisano i krytycznie przeanalizowano najprzydatniejsze rozwiązania z różnych branż tworzenia oprogramowania.

Najważniejsze zagadnienia przedstawione w książce:

Odzyskaj kontrolę nad swoim projektem i zrealizuj go w terminie!


Steve McConnell jest głównym inżynierem oprogramowania i dyrektorem generalnym w spółce Construx Software Builders. Jest także członkiem organizacji IEEE Computer Society oraz ACM. McConnell jest aktywnym programistą, koncentruje się głównie na projektowaniu komercyjnego oprogramowania „celofanowego” (ang. shrink-wrap). Współpracuje z wieloma znanymi firmami, w tym z korporacją Microsoft. Wraz z żoną i z dziećmi mieszka w Bellevue, w stanie Waszyngton.

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

Darmowy fragment publikacji:

Tytuł oryginału: Rapid Development: Taming Wild Software Schedules Tłumaczenie: Krzysztof Sawka ISBN: 978-83-283-3270-6 Authorized translation from the English language edition: RAPID DEVELOPMENT: TAMING WILD SOFTWARE SCHEDULES; ISBN 1556159005; by Steve McConnell; published by Microsoft Press, a division of Microsoft Corporation, Inc. Copyright © 1996 by Steve McConnell All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc., representing Microsoft Press. Polish language edition published by HELION SA. Copyright © 2017. AT T is a registered trademark of American Telephone and Telegraph Company. Apple and Macintosh are registered trademarks of Apple Computer, Inc. Boeing is a registered trademark of The Boeing Company. Borland and Delphi are registered trademarks of Borland International, Inc. FileMaker is a registered trademark of Claris Corporation. Dupont is a registered trademark of E.I. Du Pont de Nemours and Company. Gupta is a registered trademark of Gupta Corporation (a California Corporation). Hewlett-Packard is a registered trademark of Hewlett-Packard Company. Intel is a registered trademark of Intel Corporation. IBM is a registered trademark of International Business Machines Corporation. ITT is a registered trademark of International Telephone and Telegraph Corporation. FoxPro, Microsoft, MS-DOS, PowerPoint, Visual Basic, Windows, and Windows NT are registered trademarks and Visual FoxPro is a trademark of Microsoft Corporation. Powersoft is a registered trademark and PowerBuilder is a trademark of PowerSoft Corporation. Raytheon is a registered trademark of Raytheon Company. Other product and company names mentioned herein may be the trademarks of their respective owners. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/szypro Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis treści Przedmowa do polskiego wydania ...........................................................15 Przedmowa .........................................................................................................17 Informacje o autorze .......................................................................................23 Część I Wydajne projektowanie ............................................................25 Rozdział 1. Witaj w świecie szybkiego projektowania .........................................27 1.1. Czym jest szybkie projektowanie? ........................................................................27 1.2. Skuteczne wdrożenie szybkiego projektowania .............................................28 Rozdział 2. Strategia szybkiego projektowania ......................................................31 2.1. Ogólna strategia szybkiego projektowania ......................................................34 2.2. Cztery wymiary szybkości projektowania ..........................................................36 2.3. Ogólne rodzaje szybkiego projektowania .........................................................44 2.4. Który wymiar ma największe znaczenie? ...........................................................46 2.5. Alternatywna strategia szybkiego projektowania ..........................................48 Literatura uzupełniająca ..................................................................................................53 Rozdział 3. Klasyczne błędy ...........................................................................................55 3.1. Przykład popełniania klasycznych błędów ........................................................55 3.2. Wpływ błędów na harmonogram projektowania ...........................................62 3.3. Lista klasycznych błędów ........................................................................................63 3.4. Ucieczka z „wyspy Gilligana” ..................................................................................73 Literatura uzupełniająca ..................................................................................................75 Rozdział 4. Podstawy projektowania .........................................................................77 4.1. Podstawy zarządzania ..............................................................................................80 4.2. Podstawy techniczne ................................................................................................85 4.3. Podstawy kontroli jakości ........................................................................................93 4.4. Postępowanie zgodne z instrukcjami .............................................................. 101 Literatura uzupełniająca ............................................................................................... 102 Rozdział 5. Zarządzanie ryzykiem ............................................................................. 103 5.1. Elementy zarządzania ryzykiem ......................................................................... 105 5.2. Identyfikacja ryzyka ................................................................................................ 107 5.3. Analiza ryzyka ........................................................................................................... 112 5.4. Priorytetyzacja ryzyka ............................................................................................ 115 Poleć książkęKup książkę 6 Spis treści 5.5. Kontrola ryzyka ........................................................................................................ 117 5.6. Ryzyko, wysokie ryzyko i „loteria” ...................................................................... 122 Literatura uzupełniająca ............................................................................................... 125 Część II Szybkie projektowanie ............................................................ 127 Rozdział 6. Główne problemy dotyczące szybkiego projektowania ...........129 6.1. Czy jeden rozmiar może być uniwersalny? .................................................... 129 6.2. Jaki rodzaj szybkiego projektowania jest Ci potrzebny? ........................... 131 6.3. Szanse na ukończenie projektu w terminie ................................................... 136 6.4. Postrzeganie a rzeczywistość ............................................................................. 138 6.5. Tam, dokąd płynie wolno czas ........................................................................... 140 6.6. Kompromisy w strategii szybkiego projektowania ..................................... 144 6.7. Typowy schemat usprawniania harmonogramu ......................................... 146 6.8. Droga ku szybkiemu projektowaniu ................................................................ 148 Literatura uzupełniająca ............................................................................................... 149 Rozdział 7. Planowanie cyklu życia ..........................................................................151 7.1. Klasyczny model kaskadowy ............................................................................... 153 7.2. Nieprzemyślane pisanie kodu ............................................................................ 157 7.3. Model spiralny ......................................................................................................... 158 7.4. Zmodyfikowane modele kaskadowe ............................................................... 160 7.5. Prototypowanie ewolucyjne ............................................................................... 163 7.6. Wieloetapowe dostarczanie produktu ............................................................ 164 7.7. Wytwarzanie dopasowane do harmonogramu ............................................ 165 7.8. Ewolucyjne dostarczanie produktu .................................................................. 167 7.9. Wytwarzanie dopasowane do narzędzi .......................................................... 168 7.10. Oprogramowanie komercyjne ......................................................................... 169 7.11. Wybór najszybszego cyklu życia dla Twojego projektu .......................... 170 Literatura uzupełniająca ............................................................................................... 177 Rozdział 8. Szacowanie .................................................................................................179 8.1. Opowieść o szacowaniu ....................................................................................... 181 8.2. Zarys procesu szacowania ................................................................................... 188 8.3. Szacowanie rozmiaru ............................................................................................ 189 8.4. Szacowanie wysiłku ............................................................................................... 196 8.5. Szacowanie harmonogramu ............................................................................... 197 8.6. Orientacyjne szacowanie harmonogramu ..................................................... 199 8.7. Zawężanie oszacowań .......................................................................................... 210 Literatura uzupełniająca ............................................................................................... 216 Poleć książkęKup książkę Spis treści 7 Rozdział 9. Sporządzanie harmonogramu ............................................................ 219 9.1. Tworzenie zbyt optymistycznych harmonogramów .................................. 220 9.2. Harmonogram pod presją .................................................................................... 233 Literatura uzupełniająca ............................................................................................... 243 Rozdział 10. Projektowanie zorientowane na klienta ......................................... 245 10.1. Wpływ klienta na strategię szybkiego projektowania ............................. 248 10.2. Rozwiązania zorientowane na klienta ........................................................... 250 10.3. Zarządzanie oczekiwaniami klienta ................................................................ 254 Literatura uzupełniająca ............................................................................................... 257 Rozdział 11. Motywacja .................................................................................................. 259 11.1. Typowe motywacje projektanta ...................................................................... 261 11.2. Stosowanie pięciu najważniejszych czynników motywujących ........... 264 11.3. Korzystanie z pozostałych czynników motywujących ............................. 270 11.4. Czynniki niszczące morale ................................................................................. 273 Literatura uzupełniająca ............................................................................................... 279 Rozdział 12. Praca zespołowa ...................................................................................... 281 12.1. Zastosowania pracy zespołowej w inżynierii oprogramowania ........... 283 12.2. Znaczenie pracy zespołowej w strategii szybkiego projektowania ..... 284 12.3. Utworzenie wydajnego zespołu ...................................................................... 286 12.4. Dlaczego zespoły zawodzą? .............................................................................. 295 12.5. Długoterminowe budowanie zespołu .......................................................... 298 12.6. Wskazówki dotyczące budowania zespołu ................................................. 300 Literatura uzupełniająca ............................................................................................... 301 Rozdział 13. Struktura zespołu .................................................................................... 303 13.1. Czynniki wpływające na strukturę zespołu .................................................. 305 13.2. Modele zespołów .................................................................................................. 308 13.3. Kierownicy a liderzy techniczni ........................................................................ 317 Literatura uzupełniająca ............................................................................................... 320 Rozdział 14. Regulowanie zestawu funkcji ............................................................. 323 14.1. Początek projektu: redukcja zestawu funkcji ................................................ 325 14.2. Środek projektu: kontrola przerostu funkcjonalności .............................. 334 14.3. Koniec projektu: usuwanie funkcji .................................................................. 343 Literatura uzupełniająca ............................................................................................... 345 Poleć książkęKup książkę 8 Spis treści Rozdział 15. Narzędzia zwiększające produktywność ........................................347 15.1. Rola narzędzi zwiększających produktywność w strategii szybkiego projektowania ............................................................ 349 15.2. Strategia wykorzystywania narzędzi zwiększających produktywność ....................................................................... 353 15.3. Nabywanie narzędzi zwiększających produktywność ............................. 355 15.4. Stosowanie narzędzi zwiększających produktywność ............................ 359 15.5. Syndrom „srebrnej kuli” ..................................................................................... 364 Literatura uzupełniająca ............................................................................................... 369 Rozdział 16. Ratowanie projektu .................................................................................371 16.1. Sposoby ratowania projektu ............................................................................ 373 16.2. Plan ratowania projektu ..................................................................................... 375 Literatura uzupełniająca ............................................................................................... 387 Część III Sprawdzone rozwiązania ........................................................ 389 Wprowadzenie do sprawdzonych rozwiązań ....................................................... 390 Układ rozdziałów opisujących sprawdzone rozwiązania .................................. 392 Podsumowanie metod branych pod uwagę jako sprawdzone rozwiązania .......................................................................... 395 Podsumowanie sprawdzonych rozwiązań ............................................................. 400 Rozdział 17. Komisja zatwierdzająca zmiany ..........................................................403 Rozdział 18. Codzienne kompilacje i testy dymowe ...........................................405 18.1. Stosowanie codziennych kompilacji i testów dymowych ...................... 407 18.2. Zarządzanie ryzykiem w procesie codziennych kompilacji i testów dymowych ............................................................................................. 412 18.3. Skutki uboczne korzystania z codziennych kompilacji i testów dymowych .............................................................................................................. 412 18.4. Oddziaływanie codziennych kompilacji i testów dymowych z innymi metodami ............................................................................................. 413 18.5. Konkluzje ................................................................................................................. 413 18.6. Czynniki decydujące o skutecznym stosowaniu codziennych kompilacji i testów dymowych ............................................. 414 Literatura uzupełniająca ............................................................................................... 414 Rozdział 19. Przygotowanie architektury nastawione na zmianę ..................415 19.1. Stosowanie opisywanej metody ..................................................................... 416 19.2. Zarządzanie ryzykiem podczas przygotowywania architektury nastawionego na zmianę .................................................................................. 421 19.3. Skutki uboczne przygotowania architektury nastawionego na zmianę ............................................................................................................... 422 Poleć książkęKup książkę Spis treści 9 19.4. Oddziaływanie przygotowania architektury nastawionego na zmianę z innymi metodami ........................................................................ 422 19.5. Konkluzje ................................................................................................................. 422 19.6. Czynniki decydujące o skutecznym stosowaniu przygotowania architektury nastawionego na zmianę ......................................................... 423 Literatura uzupełniająca ............................................................................................... 423 Rozdział 20. Ewolucyjne dostarczanie produktu .................................................. 425 20.1. Stosowanie ewolucyjnego dostarczania produktu ................................... 427 20.2. Zarządzanie ryzykiem w modelu ewolucyjnego dostarczania produktu ..................................... 429 20.3. Skutki uboczne ewolucyjnego dostarczania produktu ........................... 430 20.4. Oddziaływanie ewolucyjnego dostarczania produktu z innymi metodami .............................................................................................. 431 20.5. Konkluzje ................................................................................................................. 431 20.6. Czynniki decydujące o skutecznym stosowaniu ewolucyjnego dostarczania produktu ............................................................ 432 Literatura uzupełniająca ............................................................................................... 432 Rozdział 21. Prototypowanie ewolucyjne ............................................................... 433 21.1. Stosowanie prototypowania ewolucyjnego ............................................... 434 21.2. Zarządzanie ryzykiem w prototypowaniu ewolucyjnym ........................ 435 21.3. Skutki uboczne prototypowania ewolucyjnego ........................................ 440 21.4. Oddziaływanie prototypowania ewolucyjnego z innymi metodami . 440 21.5. Konkluzje ................................................................................................................. 441 21.6. Czynniki decydujące o skutecznym stosowaniu prototypowania ewolucyjnego ........................................................................................................ 441 Literatura uzupełniająca ............................................................................................... 442 Rozdział 22. Ustanawianie celu ................................................................................... 443 Rozdział 23. Inspekcje ..................................................................................................... 445 Rozdział 24. Sesje JAD ..................................................................................................... 447 24.1. Stosowanie metodologii JAD ........................................................................... 448 24.2. Zarządzanie ryzykiem w metodologii JAD ................................................... 456 24.3. Skutki uboczne stosowania sesji JAD ............................................................ 457 24.4. Oddziaływania metodologii JAD z innymi rozwiązaniami ..................... 458 24.5. Konkluzje ................................................................................................................. 458 25.6. Czynniki decydujące o skutecznym stosowaniu metodologii JAD ..... 459 Literatura uzupełniająca ............................................................................................... 459 Poleć książkęKup książkę 10 Spis treści Rozdział 25.Wybór modelu cyklu życia ....................................................................461 Rozdział 26.Pomiary .........................................................................................................463 26.1. Stosowanie pomiarów ........................................................................................ 464 26.2. Zarządzanie ryzykiem w pomiarach ............................................................... 472 26.3. Skutki uboczne stosowania pomiarów ......................................................... 473 26.4. Oddziaływanie pomiarów z innymi metodami .......................................... 473 26.5. Konkluzje ................................................................................................................. 473 26.6. Czynniki decydujące o skutecznym stosowaniu pomiarów .................. 474 Literatura uzupełniająca ............................................................................................... 474 Rozdział 27. Rozbijanie celów na podetapy ...........................................................477 27.1. Stosowanie metody rozbijania celów na podetapy ................................. 480 27.2. Zarządzanie ryzykiem podczas rozbijania celów na podetapy ............. 483 27.3. Skutki uboczne rozbijania celów na podetapy .......................................... 483 27.4. Oddziaływanie rozbijania celów na podetapy z innymi metodami .... 483 27.5. Konkluzje ................................................................................................................. 484 27.6. Czynniki decydujące o skutecznym rozbijaniu celów na podetapy ... 485 Literatura uzupełniająca ............................................................................................... 485 Rozdział 28. Zewnętrzni podwykonawcy ................................................................487 28.1. Wykorzystywanie zewnętrznych podwykonawców ................................ 489 28.2. Zarządzanie ryzykiem związanym z zewnętrznymi podwykonawcami . 495 28.3. Skutki uboczne zatrudniania zewnętrznych podwykonawców ........... 496 28.4. Zatrudnianie zewnętrznych podwykonawców a inne metody ............ 496 28.5. Konkluzje ................................................................................................................. 497 28.6. Czynniki decydujące o skuteczności omawianej metody ...................... 497 Literatura uzupełniająca ............................................................................................... 497 Rozdział 29. Negocjacje zgodne z zasadami ..........................................................499 Rozdział 30. Środowisko pracy ....................................................................................501 30.1. Zastosowania produktywnego środowiska pracy .................................... 503 30.2. Zarządzanie ryzykiem w produktywnym środowisku pracy .................. 505 30.3. Skutki uboczne wprowadzenia produktywnego środowiska pracy ... 506 30.4. Oddziaływania środowiska pracy z innymi metodami ............................ 507 30.5. Konkluzje ................................................................................................................. 507 30.6. Czynniki decydujące o skutecznym wdrożeniu produktywnego środowiska pracy ................................................................................................. 508 Literatura uzupełniająca ............................................................................................... 508 Poleć książkęKup książkę Spis treści 11 Rozdział 31. Języki szybkiego projektowania (RDL) ............................................ 509 31.1. Stosowanie języków RDL ................................................................................... 513 31.2. Zarządzanie ryzykiem podczas stosowania języków RDL ....................... 513 31.3. Skutki uboczne stosowania języków RDL ..................................................... 515 31.4. Oddziaływanie języków RDL z innymi rozwiązaniami ............................. 515 31.5. Konkluzje ................................................................................................................. 516 31.6. Czynniki decydujące o skutecznym stosowaniu języków RDL .............. 516 Literatura uzupełniająca ............................................................................................... 517 Rozdział 32. Przesiewanie wymagań ......................................................................... 519 Rozdział 33. Wielokrotne wykorzystywanie zasobów ........................................ 521 33.1. Stosowanie wielokrotnego wykorzystywania zasobów .......................... 522 33.2. Zarządzanie ryzykiem podczas wielokrotnego wykorzystywania zasobów ................................ 529 33.3. Skutki uboczne wielokrotnego wykorzystywania zasobów .................. 530 33.4. Oddziaływanie wielokrotnego wykorzystywania zasobów z innymi metodami .............................................................................................. 530 33.5. Konkluzje ................................................................................................................. 531 33.6. Czynniki decydujące o skutecznym, wielokrotnym wykorzystywaniu zasobów .................................................. 531 Literatura uzupełniająca ............................................................................................... 532 Rozdział 34. Wspólny cel ................................................................................................ 533 34.1. Stosowanie wspólnego celu ............................................................................. 534 34.2. Zarządzanie ryzykiem podczas ustanawiania wspólnego celu ............. 536 34.3. Skutki uboczne wspólnego celu ...................................................................... 538 34.4. Oddziaływanie wspólnego celu z innymi metodami ............................... 538 34.5. Konkluzje ................................................................................................................. 538 34.6. Czynniki decydujące o sukcesie wspólnego celu ...................................... 539 Literatura uzupełniająca ............................................................................................... 539 Rozdział 35. Spiralny model cyklu życia ................................................................... 541 Rozdział 36. Wieloetapowe dostarczanie produktu ............................................ 543 36.1. Stosowanie wieloetapowego dostarczania produktu ............................. 546 36.2. Zarządzanie ryzykiem w wieloetapowym dostarczaniu produktu ...... 549 36.3. Skutki uboczne wieloetapowego dostarczania produktu ...................... 550 36.4. Oddziaływanie wieloetapowego dostarczania produktu z innymi metodami .............................................................................................. 550 Poleć książkęKup książkę 12 Spis treści 36.5. Konkluzje ................................................................................................................. 551 36.6. Czynniki decydujące o skutecznym korzystaniu z wieloetapowego dostarczania produktu ................................................. 552 Literatura uzupełniająca ............................................................................................... 552 Rozdział 37. Zarządzanie zgodne z teorią W ..........................................................553 37.1. Stosowanie zarządzania zgodnego z teorią W ......................................... 555 37.2. Zarządzanie ryzykiem w teorii W .................................................................... 560 37.3. Skutki uboczne zarządzania zgodnego z teorią W .................................... 561 37.4. Oddziaływanie teorii W z innymi metodami ............................................... 561 37.5. Konkluzje ................................................................................................................. 561 37.6. Czynniki decydujące o właściwym zarządzaniu zgodnym z teorią W ... 562 Literatura uzupełniająca ............................................................................................... 562 Rozdział 38. Prototypowanie z odrzuceniem .........................................................563 38.1. Stosowanie prototypowania z odrzuceniem .............................................. 564 38.2. Zarządzanie ryzykiem w prototypowaniu z odrzuceniem ..................... 565 38.3. Skutki uboczne stosowania prototypowania z odrzuceniem ............... 566 38.4. Oddziaływanie prototypowania z odrzuceniem z innymi metodami .... 566 38.5. Konkluzje ................................................................................................................. 566 38.6. Czynniki decydujące o skutecznym stosowaniu prototypowania z odrzuceniem ...................................................................................................... 567 Literatura uzupełniająca ............................................................................................... 567 Rozdział 39. Projektowanie metodą okienek czasowych ..................................569 39.1. Stosowanie projektowania metodą okienek czasowych ........................ 571 39.2. Zarządzanie ryzykiem w projektowaniu metodą okienek czasowych . 574 39.3. Skutki uboczne stosowania metody okienek czasowych ....................... 575 39.4. Oddziaływanie projektowania metodą okienek czasowych z innymi rozwiązaniami ..................................................................................... 575 39.5. Konkluzje ................................................................................................................. 576 39.6. Czynniki decydujące o skutecznym projektowaniu metodą okienek czasowych ............................................................................. 576 Literatura uzupełniająca ............................................................................................... 577 Rozdział 40. Zespół narzędziowy ................................................................................579 Rozdział 41. Lista 10 największych zagrożeń .........................................................581 Poleć książkęKup książkę Rozdział 42. Prototypowanie interfejsu użytkownika ........................................ 583 Spis treści 13 42.1. Stosowanie prototypowania interfejsu użytkownika ............................... 585 42.2. Zarządzanie ryzykiem w prototypowaniu interfejsu użytkownika ...... 588 42.3. Skutki uboczne prototypowania interfejsu użytkownika ....................... 589 42.4. Oddziaływanie prototypowania interfejsu użytkownika z innymi rozwiązaniami ...................................................................................... 590 42.5. Konkluzje ................................................................................................................. 590 42.6. Czynniki decydujące o skutecznym prototypowaniu interfejsu użytkownika ........................................................................................................... 590 Literatura uzupełniająca ............................................................................................... 591 Rozdział 43. Dobrowolna praca w nadgodzinach ................................................ 593 43.1. Stosowanie pracy w dobrowolnych nadgodzinach ................................. 594 43.2. Zarządzanie ryzykiem przy dobrowolnej pracy w nadgodzinach ........ 599 43.3. Skutki uboczne dobrowolnej pracy w nadgodzinach .............................. 600 43.4. Oddziaływanie dobrowolnej pracy w nadgodzinach z innymi rozwiązaniami ...................................................................................... 600 43.5. Konkluzje ................................................................................................................. 600 43.6. Czynniki decydujące o skutecznym wdrożeniu dobrowolnej pracy w nadgodzinach ................................................................................................... 601 Literatura uzupełniająca ............................................................................................... 601 Bibliografia ....................................................................................................... 603 Skorowidz ......................................................................................................... 617 Poleć książkęKup książkę 14 Spis treści Poleć książkęKup książkę Rozdział 3. Klasyczne błędy Zawartość rozdziału  3.1. Przykład popełniania klasycznych błędów  3.2. Wpływ błędów na harmonogram projektowania  3.3. Lista klasycznych błędów  3.4. Ucieczka z „wyspy Gilligana” Tematy pokrewne  „Zarządzanie ryzykiem”: rozdział 5.  „Strategia szybkiego projektowania”: rozdział 2. PROJEKTOWANIE OPROGRAMOWANIA JEST SKOMPLIKOWANYM DZIAŁANIEM. Typowy projekt daje więcej okazji do wyciągania wniosków z błędów, niż zdarza się to niektó- rym ludziom przez całe życie. W tym rozdziale przyjrzymy się niektórym z klasycznych błędów, które przytrafiają się w trakcie szybkiego projektowania oprogramowania. 3.1. Przykład popełniania klasycznych błędów Poniższy przykład przypomina nieco dziecinną układankę, w której należy znaleźć wszystkie przedmioty o nazwach rozpoczynających się na literę „B”. Jak wiele klasycznych błędów jesteś w stanie wyłapać w opisie? Przykład 3.1. Klasyczne błędy W pewien kwietniowy, ciepły poranek Mike, lider techniczny w firmie Giga Safe, firmie zaj- mującej się ubezpieczeniami zdrowotnymi, jadł śniadanie w swoim biurze i spoglądał przez okno. „Mike, dostałeś dotację na aplikację Giga-Quote! Gratulacje! — zawołał Bill, szef Mike’a w Giga Safe. — Kierownictwu bardzo spodobał się pomysł zautomatyzowania kosztów ubezpieczenia. Popiera również ideę codziennego przesyłania kosztów ubezpieczenia do centrali, dzięki czemu będziemy od razu mieli potencjalnych klientów w bazie danych. Muszę pędzić na spotkanie, ale później omówimy szczegóły. Dobrze się spisałeś z tą propozycją!”. Mike rozpisał ofertę aplikacji Giga-Quote kilka miesięcy wcześniej, ale dotyczyła ona progra- mu pozbawionego funkcji łączenia się z centralą. No cóż… Teraz otrzymał szansę popro- wadzenia projektu aplikacji typu klient – serwer oprawionej w nowoczesny interfejs użytkow- nika — marzył o tym od zawsze. Otrzymał niemal rok na wykonanie projektu, a to mnóstwo czasu, żeby dodać nową funkcjonalność. Mike podniósł słuchawkę telefonu i zadzwonił do żony: „Kochanie, chodźmy gdzieś dzisiaj na kolację. Mamy powód do świętowania…”. Poleć książkęKup książkę 56 Rozdział 3. Klasyczne błędy Mike i Bill spotkali się następnego dnia rano w celu omówienia projektu. „No dobra, Bill, o co tu chodzi? To nie jest do końca ta oferta, nad którą pracowałem”. Bill poczuł ukłucie niepokoju. Mike nie brał udziału w poprawkach, ale nie było czasu, żeby go wtajemniczyć. Gdy tylko kierownictwo zapoznało się z koncepcją aplikacji Giga-Quote, przejęło inicjatywę. „Szefostwu bardzo spodobał się pomysł stworzenia oprogramowania automatyzującego proces zakupu ubezpieczenia zdrowotnego. Dyrektorzy wymagają jednak również automatycznego przesyłania zawartych transakcji do głównego serwera. Chcą też, aby system był gotowy przed wprowadzeniem nowych stawek w dniu 1 stycznia. Przesunęli proponowany przez ciebie termin ukończenia projektu z 1 marca na 1 listopada, co skraca harmonogram do sześciu miesięcy”. Mike przewidywał, że projekt zajmie mu 12 miesięcy. Nie wierzył w szansę powodzenia przy sześciomiesięcznym harmonogramie i powiedział to Billowi. „Czegoś tu nie rozumiem — stwierdził. —Kierownictwo zażądało dodania rozbudowanej funkcjonalności sieciowej i skró- ciło harmonogram z dwunastu do sześciu miesięcy?”. Bill wzruszył ramionami. „Mam świadomość, że to będzie duże wyzwanie, ale jesteś kre- atywny i wierzę, że sobie poradzisz. Szefowie zatwierdzili zaproponowany przez ciebie budżet, a dodanie łączy komunikacyjnych nie powinno być wcale takie trudne. Prosiłeś o trzydzie- stosześciokrotność wynagrodzenia zespołu i ją dostałeś. Możesz zatrudnić, kogo tylko zechcesz, by powiększyć zespół”. Następnie polecił Mike’owi, żeby się spotkał z innymi pro- gramistami i ustalił skuteczny sposób terminowego dostarczenia produktu. Mike spotkał się z Carlem, innym liderem technicznym, i razem zastanawiali się nad sposo- bami skrócenia czasu projektowania. „Skorzystaj może z języka C++ i programowania obiektowego — zaproponował Carl. — Dzięki temu będziesz wydajniejszy, co powinno po- zwolić na zredukowanie harmonogramu o miesiąc bądź dwa”. Nasz bohater uznał to za do- bry pomysł. Carl wspomniał również o istnieniu narzędzia raportującego, które powinno skrócić czas projektowania o połowę. Projekt zawierał mnóstwo raportów, dlatego obydwa rozwiązania pozwoliłyby ustanowić dziewięciomiesięczny harmonogram. Zakup nowego, szybkiego sprzętu pozwoliłby zyskać dodatkowe kilka tygodni. Gdyby Mike zatrudnił naj- lepszych programistów w branży, zjechałby z terminem ukończenia projektu do siedmiu miesięcy. To był już całkiem niezły plan. Mike podzielił się tymi koncepcjami z Billem. „Słuchaj — powiedział Bill — dobrze, że udało się wam skrócić termin do siedmiu miesięcy, ale to wciąż za długo. Zarząd dał jasno do zrozumienia, że zależy im na półrocznym harmonogra- mie. Nie dali mi wyboru. Mogę wam załatwić nowy sprzęt, ale musisz z zespołem w jakiś sposób zmieścić się z projektem w sześciu miesiącach lub pracować w nadgodzinach, jeśli to pomoże”. Mike uznał, że być może jego pierwotne oszacowanie harmonogramu było wyolbrzymione i że jednak uda mu się zakończyć projekt w pół roku. „W porządku, Bill, wynajmę dwóch podwykonawców do tego projektu. Może uda nam się znaleźć specjalistów w dziedzinie komunikacji, którzy pomogą nam w przesyłaniu danych z komputerów do serwera”. Do 1 maja Mike zebrał zespół. Jill, Sue i Thomas byli solidnymi programistami zatrudnio- nymi w tej samej firmie, a tak się składało, że nie przydzielono ich w tym czasie do żadnego projektu. Dodał do zespołu dwoje wolnych strzelców — Keiko i Chipa. Keiko miała doświad- czenie zarówno w komputerach stacjonarnych, jak i w typie serwera, na którym zespół opierał strukturę systemu. Jill z Thomasem przeprowadzili rozmowę kwalifikacyjną z Chipem i odra- dzali przyjęcie go do zespołu, ale Mike’owi zaimponowała jego wiedza. Znał się na komunikacji i był dostępny, więc pomimo sprzeciwów zatrudniono go. Poleć książkęKup książkę 3.1. Przykład popełniania klasycznych błędów 57 Na pierwszym wspólnym spotkaniu Bill powiedział zespołowi, że aplikacja Giga-Quote ma strategiczne znaczenie dla firmy. Pewni wysocy szczeblem pracownicy będą im się uważnie przyglądać. Jeżeli zespołowi się powiedzie, zarząd nie będzie skąpił nagród. Przyznał, że wie- rzy w możliwości poszczególnych członków. Po przemowie motywacyjnej Billa Mike zasiadł z zespołem i wprowadził wszystkich w szcze- góły harmonogramu. Zarząd dał im coś na kształt specyfikacji i mieli dwa tygodnie na wy- pełnienie wszelkich luk. Następne sześć tygodni mieli poświęcić na stworzenie schematu aplikacji, po czym zostałyby im cztery miesiące na jej stworzenie i testowanie. Intuicja pod- powiadała Mike’owi, że program w ostatecznej postaci zawierałby ok. 30 tys. wierszy kodu napisanego w języku C++. Pozostali członkowie zgodzili się z tym. Wyzwanie było ambitne, ale wszyscy od początku byli tego świadomi. W następnym tygodniu Mike spotkał się ze Stacy, główną testerką. Wyjaśniła, że powinni przysłać prototypy aplikacji do testowania nie później niż do 1 września, a gotową wersję przygotować do 1 października. Mike wyraził zgodę. Zespół szybko uwinął się ze specyfikacją wymagań i zabrał się za tworzenie schematu aplikacji. Przygotowali zarys programu, który mógł we właściwy sposób korzystać z możliwości języka C++. Do 15 czerwca mieli gotowy zarys aplikacji, co oznaczało, że skończyli ten etap przed cza- sem i jak szaleni zabrali się za programowanie, gdyż chcieli zdążyć z wypuszczeniem pierw- szej wersji testowej przed 1 września. Nie wszystko szło tak gładko, jak należy. Jill i Thomas nie przepadali za Chipem, Sue również narzekała, że chłopak nie dopuszcza nikogo do swojej partii kodu. Mike uważał, że programiści spędzali ze sobą zbyt wiele czasu w pracy, co stanowiło przyczynę konfliktu charakterów. Bez względu na animozje na początku lipca stwierdzili, że mają przygotowane już 85 – 90 aplikacji. W połowie sierpnia dział aktuarialny wydał stawki obowiązujące na przyszły rok i zespół stwier- dził, że musi dostosować system do zupełnie nowej struktury stawek. Nowa metoda oblicza- nia kosztów wprowadzała pytania o takie czynniki jak częstotliwość aktywności fizycznej, uzależnienie od tytoniu i alkoholu, zainteresowania oraz inne elementy, których nie było wcześniej we wzorach na stawkę ubezpieczeniową. Zespół Mike’a pomyślał, że struktura ję- zyka C++ powinna ich uchronić przed wpływem takich zmian. Zamierzali po prostu dodać nowe współczynniki do tabeli kosztów. Musieli jednak pozmieniać wygląd okien dialogowych, projekt bazy danych, dostęp do niej, a także obiekty komunikacyjne, żeby przystosować całość do nowej struktury. Zespół zabrał się za wprowadzanie poprawek, a Mike powiedział Stacy, że mogą zaliczyć kilka dni poślizgu, zanim przygotują wersję przeznaczoną do testowania. Wersja testowa nie była gotowa 1 września, a Mike zapewnił Stacy, że zostanie dostarczona w ciągu maksymalnie dwóch dni. Dni zmieniły się w tygodnie. Termin oddania gotowego projektu do testowania (1 październi- ka) nadszedł i przeminął. Programiści ciągle nie przygotowali pierwszej wersji testowej. Stacy umówiła się z Billem na przedyskutowanie harmonogramu. „Nie otrzymaliśmy jeszcze żadnej wersji do testowania — powiedziała. — Mieliśmy ją dostać do 1 września, ale nic takiego nie nastąpiło. Wygląda na to, że mają przynajmniej jeden miesiąc poślizgu. Obawiam się, że trapią ich jakieś kłopoty”. „Żebyś wiedziała, że mają kłopoty — odparł Bill. — Muszę porozmawiać z zespołem. Obieca- łem sześciuset agentom, że do pierwszego listopada otrzymają tę aplikację. Musimy ją wy- puścić przed zmianą stawek”. Poleć książkęKup książkę 58 Rozdział 3. Klasyczne błędy Bill zwołał spotkanie zespołu. „Jesteście świetną ekipą i powinniście wywiązywać się ze swo- ich zobowiązań — powiedział im. — Nie wiem, co poszło źle, ale oczekuję od was wszystkich ciężkiej pracy oraz że dostarczycie oprogramowanie na czas. Ciągle możecie otrzymać nagro- dy, ale musicie sobie na nie zapracować. Od teraz aż do zakończenia projektu każde z was jest zobowiązane do dziesięciogodzinnego dnia pracy przez sześć dni w tygodniu”. Po spo- tkaniu Jill i Thomas burknęli Mike’owi, że nie trzeba traktować ich jak dzieci, ale zgodzili się pracować w wyznaczony sposób. Zespół przesunął termin zakończenia projektu o dwa tygodnie, gwarantując, że przygotują gotowy produkt do 15 listopada. Testerzy mieliby sześć tygodni na jego sprawdzenie, zanim w styczniu zostałyby wprowadzone nowe stawki. Pierwsza wersja testowa aplikacji pojawiła się cztery tygodnie później — 1 listopada. Członko- wie zespołu zebrali się, aby omówić kilka istniejących problemów. Tomas pracował nad generowaniem raportów i natrafił na przeszkodę. „Strona z podsu- mowaniem zawiera prosty wykres kolumnowy. Korzystam z generatora raportów, który jest w stanie go wyświetlać, ale przekształca całą stronę w taki wykres. Jednym z wymogów jest umieszczenie wykresu oraz tekstu na tej samej stronie. Odkryłem, że mogę oszukać system, umieszczając tekst raportu jako legendę w obiekcie wykresu. Jest to oszustwo, ale po wyda- niu pierwszej wersji mogę spróbować wprowadzić jakieś bardziej formalne rozwiązanie”. Mike odparł: „Nie wiem, w czym widzisz problem. Mamy wydać produkt i nie mamy czasu, żeby doszlifowywać kod. Bill wyraził się wystarczająco jasno, że nie możemy sobie pozwolić na kolejne poślizgi. Oszukaj system”. Chip poinformował, że jego moduł komunikacyjny jest gotowy w 95 , ale jeszcze musi prze- prowadzić kilka testów. Mike zauważył, jak Jill i Tomas przewracają oczami, ale zignorował to. Zespół pracował ciężko do 15 listopada, w tym niemal przez całe dwie noce tuż przed koń- cem terminu, ciągle jednak nie był w stanie wydać ostatecznej wersji. Ludzie byli wycień- czeni, ale to Bill poczuł się bardzo źle rankiem 16 listopada. Stacy poinformowała go telefo- nicznie, że zespół programistów nie przesłał jej poprzedniego dnia aplikacji do przetestowania. Tydzień wcześniej Bill zapewnił kierownictwo, że wszystko idzie zgodnie z planem. Inna kierowniczka projektu, Claire, przyjrzała się postępom czynionym przez zespół i stwierdziła, że doszły ją słuchy o poślizgach w terminowym dostarczaniu aplikacji do testowania. Bill nie lubił Claire, ponieważ uważał, że jest zbyt nerwowa. Zapewnił ją, że jego zespół nie ma pro- blemu z harmonogramem. Bill kazał Mike’owi zebrać zespół, a gdy przyjrzał się ludziom, stwierdził, że wyglądają na pokonanych. Półtora miesiąca 60-godzinnych tygodni pracy zebrało swoje żniwo. Mike zapy- tał, o której godzinie tego dnia można się spodziewać gotowego produktu, ale odpowie- działa mu cisza. „Co chcecie mi przez to powiedzieć? — zapytał. — Skończymy dzisiaj tę ostateczną wersję, prawda?”. „Słuchaj, Mike — zaczął Tomas — mogę oddać dzisiaj swój moduł i powiedzieć, że jest »gotowy«, ale prawdopodobnie czekałyby mnie po tym trzy tygodnie jego poprawiania”. Mike zapytał, co Tomas ma na myśli, mówiąc „poprawianie”. „Nie wstawiłem logo firmy na każdej stronie, nie zdążyłem też wstawić danych kontaktowych agenta w stopce wydruku. To nic wielkiego. Wszystkie najważniejsze funkcje działają jak należy. Mój moduł jest gotowy w dziewięćdziesięciu dziewięciu procentach”. Poleć książkęKup książkę 3.1. Przykład popełniania klasycznych błędów 59 „Ja też jeszcze nie przygotowałam wszystkiego do końca — dodała Jill. — Moja poprzednia grupa wydzwaniała ostatnio często do mnie z prośbą o wsparcie techniczne i codziennie pomagałam im przez bite dwie godziny. Do tego Tomas właśnie mi przypomniał, że mieli- śmy udostępnić agentom możliwość dodawania swoich danych osobowych do raportów. Jeszcze nie zaimplementowałam okien dialogowych odpowiedzialnych za tę funkcję, a także kilku innych elementów interfejsu. Nie sądziłam, że będą one potrzebne w tym momencie”. Teraz z kolei Mike’owi zrobiło się słabo. „Jeżeli nic mi się nie stało z uszami i dobrze słyszę, to chcecie mi powiedzieć, że będziemy mieli gotowy, funkcjonalny produkt za trzy tygodnie. Zgadza się?”. „Najwcześniej za trzy tygodnie” — sprecyzowała Jill. Pozostali programiści przytaknęli. Mike obszedł stół i zapytał z osobna każdego członka zespołu, czy skończy swoje zadania w ciągu trzech tygodni. Wszyscy stwierdzili, że przy odpowiednio ciężkiej pracy jest to osiągalne. Tego samego dnia po długiej, nieprzyjemnej rozmowie Mike i Bill zgodzili się przedłużyć harmonogram o trzy tygodnie, do 5 grudnia, pod warunkiem że wszyscy członkowie zespołu będą pracować nie po 10, a po 12 godzin dziennie. Bill wyjaśnił, że szefostwo chce widzieć presję wywieraną na zespół. Zmodyfikowany harmonogram oznaczał, że firma musiała jed- nocześnie testować aplikację i szkolić agentów ubezpieczeniowych — był to jedyny spo- sób, aby 1 stycznia wypuścić aplikację na rynek. Stacy narzekała, że dział kontroli jakości nie zdąży w tym czasie przetestować produktu, ale została przegłosowana. Zgodnie z ustaleniami 5 grudnia twórcy aplikacji Giga-Quote oddali przed południem pro- dukt do testowania i wyszli z pracy wcześniej na zasłużony odpoczynek. Pracowali niemal bez przerwy od 1 września. Dwa dni później Stacy opublikowała pierwszą listę błędów i rozpętało się piekło. W ciągu tych dwóch dni zespół testerów wykrył ponad 200 usterek, w tym 23 błędy zaliczane do najwyższej kategorii — „konieczne do naprawienia”. „Nie wyobrażam sobie, żeby to opro- gramowanie było gotowe do przekazania agentom pierwszego stycznia — podsumowała. — Prawdopodobnie tyle czasu zajmie mojemu zespołowi napisanie testów regresyjnych dla już odkrytych usterek, a z każdą chwilą znajdujemy kolejne”. Mike zwołał zebranie zespołu na ósmą rano następnego dnia. Programiści byli rozdrażnieni. Twierdzili, że pomimo kilku poważnych problemów wiele zgłoszonych błędów wcale nie było błędami, a wynikiem niewłaściwego zrozumienia działania programu. Tomas jako przykład podał błąd nr 143: „W raporcie dotyczącym tego błędu stwierdzono, że na stronie podsumowania wykres słupkowy powinien się znajdować po prawej stronie, a nie po lewej. Tego nie można nazwać błędem najwyższej kategorii. To klasyczny przykład przewrażliwienia działu kontroli jakości”. Mike przekazał każdemu członkowi zespołu kopię raportu. Programiści mieli przeanalizo- wać zawarte tam problemy i oszacować czas potrzebny na ich wyeliminowanie. Na popołudniowym spotkaniu nie usłyszał dobrych wieści. „Jeżeli mam być realistką, to usunięcie zgłoszonych do tej pory błędów zajmie mi około dwóch tygodni — powiedziała Sue. — Do tego muszę dokończyć algorytmy sprawdzania poprawności bazy danych. Łącz- nie czekają mnie cztery tygodnie pracy”. Tomas przesłał błąd numer 143 do ponownej analizy, domagając się zmiany jego priorytetu z najwyższej kategorii na priorytet trzeciego poziomu — „zmiany kosmetyczne”. Dział kontroli jakości wyjaśnił, że raporty podsumowań w aplikacji Giga-Quote powinny wyglądać tak samo, jak raporty generowane przez aplikację odpowiedzialną za przedłużanie polis, które z kolei Poleć książkęKup książkę 60 Rozdział 3. Klasyczne błędy miały taki sam styl jak stosowane od lat materiały promocyjne. Agenci ubezpieczeniowi by- liprzyzwyczajeni do materiałów zawierających wykres słupkowy po prawej stronie, musiał więc on pozostać w tym miejscu. Utrzymano najwyższy priorytet błędu, co spowodowało dalsze problemy. „Pamiętasz to oszustwo z wyświetlaniem wykresu i raportu na tej samej stronie? — zapytał Tomas. — Żeby umieścić wykres po prawej stronie, muszę całkowicie przeredagować ten konkretny raport, co oznacza, że muszę stworzyć moduł odpowiedzialny za formatowanie tekstu i grafikę”. Mike się wzdrygnął i poprosił o przybliżony czas tworzenia modułu. Tomas odpowiedział, że zajmie mu to przynajmniej 10 dni, ale musi jeszcze dokładniej się zastano- wić nad problemem, żeby się upewnić. Przed pójściem do domu Mike oznajmił Stacy i Billowi, że zespół będzie pracował w trakcie przerwy świątecznej i usunie wszystkie zgłoszone błędy do 7 stycznia. Bill powiedział, że spodziewał się tego i zatwierdził czterotygodniowy poślizg przed wyruszeniem na trwającą miesiąc wycieczkę na Karaiby, którą planował już od poprzednich wakacji. Mike spędził cały miesiąc, trzymając swoich żołnierzy w ryzach. Przez cztery miesiące praco- wali tak ciężko, jak mogli, i sądził, że już się nie da mocniej ich przycisnąć. Przebywali w biurze po 12 godzin dziennie, ale dużo czasu spędzali na czytaniu gazet, opłacaniu rachunków i roz- mowach telefonicznych. Wydawało się, że do furii doprowadza ich każde pytanie dotyczące czasu potrzebnego do usunięcia kolejnych błędów. Na jeden wyeliminowany błąd przypadały dwa nowe. Usterki, których usunięcie powinno zająć kilka minut, miały wpływ na cały pro- jekt, przez co programiści głowili się nad nimi przez wiele dni. Po niedługim czasie zrozu- mieli, że wyeliminowanie wszystkich błędów do 7 stycznia jest nierealne. Tego dnia Bill wrócił z urlopu i Mike przekazał mu informację, że zespół będzie potrzebo- wał dodatkowe cztery tygodnie na usunięcie wszystkich usterek. „Chyba żartujesz — odparł Bill. — Mam na głowie sześciuset agentów, którzy mają dość wodzenia za nos przez bandę komputerowców. Zarząd rozważa możliwość anulowania projektu. Musisz w jakiś sposób dostarczyć ten produkt w ciągu dwóch tygodni, bez względu na koszty”. Mike zwołał zebranie zespołu, żeby rozważyć możliwości. Przekazał im ultimatum Billa, a na- stępnie poprosił, żeby oszacowali przybliżoną datę wydania produktu, najpierw w tygodniach, a później — miesiącach. Nikt się nie odezwał. Żaden członek zespołu nie chciał ryzykować podania terminu, którego prawdopodobnie i tak nie mogliby dotrzymać. Mike nie wiedział, co powiedzieć Billowi. Po spotkaniu Chip oznajmił Mike’owi, że podpisał kontrakt z inną firmą, który zacznie obowiązywać od 3 lutego. Mike po raz pierwszy poczuł, że może byłoby lepiej, gdyby pro- jekt rzeczywiście został anulowany. Mike zlecił Kipowi, programiście odpowiedzialnemu za architekturę serwera, pomoc w pozo- stałych modułach i przydzielił go do eliminacji błędów występujących po stronie komunika- cyjnej komputerów klienckich. Kip walczył przez tydzień z kodem napisanym przez Chipa i zrozumiał, że zawiera on pewne podstawowe wady koncepcyjne, przez które moduł nie ma prawa właściwie działać. Został zmuszony do ponownego zaprojektowania i zaimplemen- towania klienckiej części łącza komunikacyjnego. W połowie lutego odbyło się spotkanie zarządu, na którym Claire stwierdziła, że usłyszała już wystarczająco wiele i zaproponowała „zaprzestanie” projektu Giga-Quote. Spotkała się w piątek z Mike’em. „Ten projekt wymknął się spod kontroli — zaczęła. — Od miesięcy nie Poleć książkęKup książkę 3.1. Przykład popełniania klasycznych błędów 61 dostałam od Billa żadnych rzetelnych wytycznych do harmonogramu. Miał to być projekt trwający pół roku, a już zaliczyliście trzymiesięczny poślizg bez perspektywy ukończenia go w najbliższym czasie. Przyjrzałam się statystykom błędów i twój zespół nie radzi sobie z ich usuwaniem. Pracujecie już tak długo, że teraz nie czynicie żadnych postępów. Daję wam wszystkim wolny weekend; natomiast po powrocie masz sporządzić szczegółowy raport, który ma zawierać wszystkie, powtarzam: wszystkie, elementy pozostałe do ukończenia projektu. Nie chcę, abyś na siłę wymyślał jakiś sztuczny harmonogram. Jeżeli tworzenie aplikacji zajmie kolejne dziewięć miesięcy, muszę o tym wiedzieć. Przygotuj ten raport do środowego popołudnia. Nie musi być elegancki, ale ma być kompletny”. Zespół był bardzo zadowolony z wolnego weekendu i członkowie w ciągu następnego tygo- dnia przystąpili do sporządzania raportu ze zdwojoną mocą. W środę wylądował na biurku Claire. Dała go do przeanalizowania Charlesowi — konsultantowi do spraw inżynierii opro- gramowania, który również przejrzał raport błędów. Zalecił, aby zespół skupił się na kilku najwrażliwszych modułach, natychmiast przygotował analizę wszystkich błędów projekto- wych i programistycznych, a także żeby programiści przestali pracować w nadgodzinach, dzięki czemu mogliby dokładnie oszacować, ile wysiłku zostało włożonego w projekt oraz ile jeszcze zostało czasu do jego zakończenia. Trzy tygodnie później, w pierwszym tygodniu marca, lista błędów po raz pierwszy zaczęła się kurczyć. Morale zespołu nieco się podniosło, a konsultant na podstawie jednostajnych postępów oszacował termin dostarczenia gotowego i przetestowanego produktu do 15 maja. Kolejny wzrost stawek miał wejść w życie 1 lipca, dlatego Claire ustaliła 1 czerwca jako oficjal- ną datę wydania aplikacji. Epilog Program Giga-Quote dostarczono agentom zgodnie z planem, 1 czerwca. Został przyjęty ciepło, chociaż z pewną dozą sceptycyzmu. Korporacja Giga Safe doceniła ciężką pracę włożoną w projekt przez członków zespołu, dając każdemu z nich premię w wysokości 250 dolarów. Kilka tygodni później Tomas wziął długi urlop, a Jill przeniosła się do innej firmy. Stworzenie aplikacji Giga-Quote zajęło ostatecznie nie sześć, a 13 miesięcy — poślizg wy- niósł ponad 100 pierwotnego planu. Liczba osobomiesięcy (wliczając nadgodziny) wynio- sła 98 miesięcy, czyli została przekroczona o 170 w porównaniu do pierwotnie zakłada- nych 36 osobomiesięcy. Odnośniki: Więcej informacji na temat orientacyjnego szacowania terminu wykonania projektów o różnych rozmiarach znajdziesz w podrozdziale 8.6. „Orientacyjne szacowanie harmonogramu”. Wyliczono, że ostateczny produkt składał się z ok. 40 tys. niepustych, niebędących komenta- rzami wierszy kodu napisanego w języku C++, co stanowiło wartość o 33 większą od roz- miaru zakładanego przez Mike’a. Aplikacja stanowiła hybrydę produktu biznesowego i „celo- fanowego”, ponieważ została rozprowadzona do 600 punktów w kraju. Produkt tego typu i wielkości jest tworzony przeciętnie przez 11,5 miesiąca oraz wymaga włożenia wysiłku równego 71 miesięcy pracy zespołowej. Jak widać, zostały przekroczone obydwie wartości nominalne. Poleć książkęKup książkę 62 Rozdział 3. Klasyczne błędy 3.2. Wpływ błędów na harmonogram projektowania Michael Jackson (piosenkarz, nie informatyk) śpiewał, że „jedno zgniłe jabłko nie zepsuje pozo- stałych, maleńka”1. Być może jest to prawda w przypadku jabłek, ale nie dla oprogramowania. Jedno zgniłe jabłko może zepsuć cały projekt. Grupa naukowców z instytutu technicznego ITT przeanalizowała 44 projekty z dziewięciu krajów w celu ustalenia wpływu 13 czynników na produktywność (Vosburgh i in. 1984). Obser- wowano takie czynniki, jak wykorzystanie współczesnych rozwiązań programistycznych, poziom zaawansowania kodu, wymagania dotyczące wydajności, udział klienta w ustalaniu specyfikacji produktu, doświadczenie pracowników i kilka innych. Badacze podzielili czynniki na kategorie związane z małą, średnią i dużą wydajnością. Przykładowo: rozdzielili czynnik współczesne roz- wiązania programistyczne na niewielkie, średnie i częste zastosowanie. Na rysunku 3.1 widzimy wyniki badań przeprowadzonych na czynniku współczesne rozwiązania programistyczne. Im dłużej przyglądasz się wykresowi z rysunku 3.1, tym robi się on bardziej interesujący. Wi- doczny na nim wzór odpowiada zasadniczo wszystkim analizowanym czynnikom. Naukowcy odkryli, że projekty należące do kategorii składających się na niską produktywność rzeczywiście nie były zbyt wydajne — słupek ukazany w kategorii niska na rysunku 3.1. Jednakże produk- tywność projektów o wysokiej wydajności cechowała olbrzymia rozbieżność — słupek w kate- gorii wysoka. W tej kategorii wydajność projektów plasowała się pomiędzy niską a znakomitą. Odnośniki: Więcej informacji na temat omawianego wykresu znajdziesz w podrozdziale 4.2. „Podstawy techniczne”. Rysunek 3.1. Wnioski dotyczące czynnika „wykorzystanie współczesnych rozwiązań programistycznych” (Vosburgh i in. 1984). Właściwe wdrożenie kilku elementów wcale nie gwarantuje szybkiego projektowania. Trzeba również unikać popełniania błędów 1 W oryginale: „One bad apple don`t spoil the whole bunch, baby” z piosenki One Bad Apple — przyp. tłum. Poleć książkęKup książkę 3.3. Lista klasycznych błędów 63 Odnośniki: Więcej informacji dotyczących wpływu błędów na proces szybkiego projektowania znajdziesz w podrozdziale 2.1. „Ogólna strategia szybkiego projektowania”. Nie powinno dziwić, że projekty o niskiej produktywności osiągnęły takie a nie inne wyniki. Jednak zaskakujący jest fakt, że wiele projektów zorientowanych na wysoką produktywność w rzeczywistości kiepsko sobie radzi. Celem powyższego i innych wykresów umieszczonych w tej książce jest ukazanie, że skuteczne rozwiązania są warunkiem koniecznym, ale niewystarczającym do osiągnięcia maksymalnej szybkości projektowania. Nawet jeżeli stosujesz pewne elementy właściwie (np. wydajnie korzystasz z nowoczesnych rozwiązań programistycznych), wciąż mo- żesz popełnić błąd, który zniweluje korzystny wpływ danego czynnika. Przy zastosowaniu strategii szybkiego projektowania pojawia się kusząca myśl, że wystarczy zidentyfikować i wyeliminować przyczyny powolnego tworzenia, a produkt powstanie znacznie szybciej. Problem polega na tym, że istnieją również inne czynniki wpływające na szybkość projektowania i ostatecznie wyeliminowanie podstawowych przyczyn na wiele się nie zda. Przypomina to trochę pytanie: „Dlaczego nie jestem w stanie przebiec jednego kilometra w trzy minuty?”. Jestem za stary. Za dużo ważę. Nie mam dobrej kondycji. Nie chce mi się trenować. Nie mam światowej klasy trenera ani odpowiedniego obiektu treningowego. Nawet za młodu nie byłem wystarczająco szybki. Przyczyny można wymieniać w nieskończoność. Gdy mówimy o wyjątkowych osiągnięciach, pojawia się zbyt wiele przyczyn, dla których ludzie nie osiągają najwyższej formy. Omawiany w przykładzie 3.1 zespół twórców aplikacji Giga- Quote popełnił wiele błędów trapiących świat programistów od zarania dziejów informatyki. Ścieżka inżynierii oprogramowania jest bardzo wyboista, a od tych wybojów w dużej mierze zależy, jak szybko jesteś w stanie zaprojektować oprogramowanie. W przypadku oprogramowania jedno zgniłe jabłko może zepsuć pozostałe, maleńka. Wystar-
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Szybkie projektowanie. Zapanuj nad chaosem zadań i presją czasu
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ą: