1. Tajemna sztuka szacowania projektów wg Steve'a McConnella

2. Nauka a sztuka szacowania

3. Planowanie a szacowanie PLANOWANIE SZACOWANIE

5. Efekt finalny jest mniej więcej tym co założono i został wykonany w określonym limicie czasu/budżecie

6. Daje na tyle jasny pogląd na rzeczywistość projektu by umożliwiało kierownictwu prowadzenie go ku założonym celom

7. Jak dobrze potrafisz szacować? QUIZ

8. Wyniki 1 punkt za każdą odpowiedź, która będzie zawierała prawidłową wartość

9. Wielkosć Odpowiedź Temperatura na powierzchni Słońca 10 000 °F / 6 000 °C Szerokość geograficzna Szanghaju 31 ° na północ Powierzchnia Azji 17 139 000 mil 2 = 44 390 000 km 2 Rok urodzin Aleksandra Wielkiego 356 p.n.e. Całkowita wartość waluty USA w obiegu w 2004 roku 719,9 miliardów dolarów Łączna objętość Wielkich Jezior 5 500 mil 3 = 2,4 * 10 22 stóp 3 = 1,8 * 10 23 galonów 3 = 23 000 km 3 = 6,8 * 10 20 m 3 = 6,8 * 10 23 litrów Całkowita wartość biletów sprzedanych na film Titanic 1 835 miliardów dolarów Całkowita długość linii brzegowej Oceanu Spokojnego 84 300 mil = 135 663 km Liczba książek wydanych w USA od 1776 r. 22 million Masa najcięższego odnotowanego płetwala błękitnego 380 000 funtów = 190 ton angielskich = 170,000 kg = 170 t Materiał ten pochodzi z książki „Software Estimation” Steve'a McConnella (Microsoft Press, 2006), © Steve McConnell. Wszelkie prawa zastrzeżone.

10. Ludzie sądzący, że podają wyniki celne w 90% osiągają naprawdę 30% celność Zawężanie przedziałów narzucamy sobie sami – profesjonalna duma, wymagający klient Wąskie przedziały szacowania != dobre szacowanie

11. Wady przeszacowania

12. Prawo parkinsona - zadanie na 3h szacowane na 5h zajmie 5h Syndrom studenta Goldratta - najpierw zwłoka, potem pospiech (ale to niweluje kontrola projektu, tickety)

13. Wady niedoszacowania

14. Planowanie traci lub staje się bezużyteczne (np. stworzony zbyt mały team) Deweloperzy sami z siebie niedoszacowują o jakieś 30%, ich szacunków nie należy zmniejszać Mało czasu przeznaczone na definiowanie wymagań i architekturę mści się, bo generuje błędy Dynamika spóźnionego projektu opóźnia go bardziej: spotkania w celu poprawy sytuacji, reestymacja, przepraszanie, przygotowywanie okrojonych wersji, wybieranie najważniejszych elementów do zrealizowania, naprawianie błędów tworzonych pod napięciem

15. Materiał ten pochodzi z książki „Software Estimation” Steve'a McConnella (Microsoft Press, 2006), © Steve McConnell. Wszelkie prawa zastrzeżone.

17. Projekty średnio przekraczają czas o 120% i budżet o 100%. I to po okrojeniu wymagań.

18. Projekty nie są przeszacowywane, są jedynie niedoszacowywane

19. Korzyści z dobrego szacowania

21. Wyższa jakość

22. Lepsza koordynacja z innymi czynnościami

23. Lepsze budżetowanie

24. Większa wiarygodność deweloperów

25. Wczesna informacja o ryzyku

26. Źródła niedokładności szacowania

27. Materiał ten pochodzi z książki „Software Estimation” Steve'a McConnella (Microsoft Press, 2006), © Steve McConnell. Wszelkie prawa zastrzeżone.

28. Stożek sam się nie zwęzi – fiksowanie zmiennych Iteracyjnie – stożek wykorzystać do definicji UI zbijając niepewność do 25%, dalej 'podstożki'

29. Nie zakładaj, że cokolwiek dostajesz za darmo

30. Setup/installation program, Data conversion utility, Glue code needed to use third-party or open-source software, Help system, Deployment mode, Interfaces with external systems Accuracy, Interoperability, Modifiability, Performance, Portability, Reliability, Responsiveness, Reusability, Scalability, Security, Survivability, Usability Mentoring of new team members, Management coordination/manager meetings, Cutover/deployment, Data conversion, Installation, Customization Requirements clarifications, Maintaining the revision control system, Supporting the build, Maintaining the scripts required to run the daily build, Maintaining the automated smoke test used in conjunction with the daily build Installation of test builds at user location(s), Creation of test data, Management of beta test program, Participation in technical reviews, Integration work, Processing change requests, Attendance at change-control/triage meetings, Coordinating with subcontractors Technical support of existing systems during the project, Maintenance work on previous systems during the project, Defect-correction work, Performance tuning, Learning new development tools, Administrative work related to defect tracking, Coordination with test (for developers) Coordination with developers (for test), Answering questions from quality assurance, Input to user documentation and review of user documentation, Review of technical documentation, Demonstrating software to customers or users, Demonstrating software at trade shows, Demonstrating the software or prototypes of the software to upper management, clients, and end users Interacting with clients or end users; supporting beta installations at client locations, Reviewing plans, estimates, architecture, detailed designs, stage plans, code, test cases, and so on Vacations, Company meetings, Holidays, Department meetings, Sick days, Setting up new workstations, Training, Installing new versions of tools on workstations, Weekends, Troubleshooting hardware and software problems Materiał ten pochodzi z książki „Software Estimation” Steve'a McConnella (Microsoft Press, 2006), © Steve McConnell. Wszelkie prawa zastrzeżone.

31. A do tego Chaotyczność projektu Niestabilne wymagania Nieuzasadniony optymizm Subiektywności i stronniczość (pokrętła) Szacowanie na kolanie

32. Czynniki wpływające na szacowanie

33. Rozmiar (dysekonomia skali) Rodzaj tworzonego oprogramowania Czynniki personelowe Język oprogramowania Czynniki modelu Cocomo II (niektóre zależne od rozmiaru) Wpływ technologii nie jest pierwszorzędny

34. Błyskawiczny kurs technik szacowania

36. Obliczaj, jeśli nie masz czego zliczać

37. W ostateczności wykorzystaj własny osąd

39. Precyzyjnie zdefiniuj jednostki

40. Twórz proste modele z uwzględnieniem dysekonomii skali

41. Dane z bieżącego projektu cenniejsze

42. Dane typowe przemysłu najmniej dokładne

44. Wartości optymistyczna, pesymistyczna, najbardziej prawdopodobna -> spodziewana

45. Checklista poprawności pojedynczego szacunku

46. Obliczanie Marginesu Relatywnego Błędu -> sprzężenie zwrotne

48. Granularność zależy od etapu (stożek)

49. Dyskretne wartości przez ich optymizm psują szacowanie – używać przedziałów

51. Logika rozmyta – przejście z historycznego LOC/zadanie o danej wielkości do LOC zadania z ocenioną wielkością

52. Dopasowywanie koszulki

53. Pozostałe techniki Szacowanie przez analogię Ocena ekspercka w grupach Programy do szacowania Łączenie metod Proces ustandaryzowany

55. Nie manipuluj wynikiem szacowania, zmieniaj założenia

56. Nie szacuj bezpośrednio

57. Szacuj wieloma sposobami, szukaj korelacji

58. Reestymuj korzystając ze świeżych danych Materiał ten pochodzi z książki „Software Estimation” Steve'a McConnella (Microsoft Press, 2006), © Steve McConnell. Wszelkie prawa zastrzeżone.

60. Wynik szacowania to przedział

61. Nie zawężaj zakresów na siłę. Jeśli czujesz taki przymus upewnij się, że nie jesteś jego źródłem

63. Wynik szacowania to przedział

64. Nie zawężaj zakresów na siłę. Jeśli czujesz taki przymus upewnij się, że nie jesteś jego źródłem

65. DZIĘKI!