SlideShare a Scribd company logo
Здравейте, аз съм
Стоян Христов Дипчиков.
В следващия час ще ви
запозная с проблемите на
проджект мениджмънта и
планирането.
Успеваемост на проекти
      65% провалени (19% провалени + 46% извън бюджет и срокове)
       1.	 65% от софтуерните проекти са неуспешни или проблемни (Standish
           Group)
       2.	25-40% от работа по софтуерни проекти се изхвърля и прави наново
           (Carnegie Mellon)
       3.	50% от проектите биват изваждани от експлоатация веднага след
           инсталацията си (Gartner)




35% succeded
Бизнес анализ и успеваемост

      65% провалени (19% провалени + 46% извън бюджет и срокове)
       1.	 40% от проблемите се откриват от крайните потребители (Garner)
       2.	Неправилно дефиниране на изискванията води до 66% от провалите
           (Forrester Research)
       3.	60-80% от провалите на проекти са резултат от неправилно събиране и
           управление на изискванията (Meta Group)




35% успешни
Развитие на проекта и дефекти

Release                               Заключения
Откриваеми на бъгове 40-50%
Цена на промените Много Висока
                                      1.	 Web сайтовете се
                                          разработват, за да
                                          изпълнят набор от
Тест                                      изисквания
Откриваеми на бъгове 15-50%
Цена на промените Висока
                                      2.	По-голямата част
                                         от бъговете се
                                         откриват след
Реализация                               реализацията на
Откриваеми на бъгове 10-15%              проекта
Цена на промените Средна
                                      3.	Изискванията са
                                         главния източник
Дизайн                                   на дефекти в
Откриваеми на бъгове 5-10%               проекта
Цена на промените Ниска


Изисквания
Откриваеми на бъгове < 5%
Цена на промените Ниска
Защо се провалят проектите?




                                             Не се предвиждат
                                             бъдещите дефекти




                                              Някои от лошите навици
Прибързване с започването                     на програмистите ;)
на кодирането и дизайна


                                     Омагьосания кръг, в който
          Грешна оценка на проекта   поставяме софтуерните тестери
Как да осигурим успеха на проекта си?




                                      Поддържайте
                                      прозрачността в проекта




                                      Не пренебрегвайте
Всички в екипа са равни               бумащината




             Имайте доверие   Проверявайте често проекта,
             на екипа си!     пишете отчети често
SDL (Software Development Lifecycle)

Waterfall                   Agile
                                             Проект
 Изисквания
                                            Итерация
      Дизайн
                                         Удобрени промени
       Реализация
                                         Дневни промени
               Тест

                                             Начало
                Поддръжка


                            Rup

                             Начална
                            подготовка    Уточнения   Изграждане   Миграция
Планирането на проект?!?



        Планирането на проект?!?
        Какво представлява планирането на проект?


        Начална фаза на планирането
        1.	 Обхват на проекта (Scope) - Засегнатите лица по
            проекта / Stakeholders (Лице за контакт) и Ресурси
            (Вашите колеги + технически и други нужди за
            проекта)
        2.	Проблеми за решаване и анализ на рисковете
        3.	Интервюта с клиента и събиране на изискванията
Техническо задание и wireframes
                  Няма общо приета структура за технически
                  задания. Моят пример:
            mes   1.	 Кратко описание на проекта и неговите цели
     wirefra
                  2.	Използвани технологии
                  3.	Засегнати лица
                  4.	Речник
                  5.	Описание на основните модули
                  6.	Приложения (Flow charts, диаграми и описание на
                     алгоритмите и т.н.)


                  Wireframes (скици на проекта)
                  1.	 Защо са ни скици?
                  2.	 Начини за създаване на Wireframes: На ръка или чрез
                      специализиран софтуер (Axure, Adobe Fireworks)
                  3.	 Не се увличайте в дизайн на wireframe-ите
Оценка на проекта



    1.	 Защо ни е нужна оценка?
    2.	 Как процедираме в Despark?
    3.	 Документирайте сроковете, който сте решили
        както и причината за определянето им, за да може
        после да ги съпоставите с реалните резултати и да
        ги анализирате
График на проекта
     1.	 Разбиване на проекта на малки под задачи, като за
         основа ползваме разписаните задачи от предната
         фаза на оценката
     2.	 Труд за разработка на задача с/у Време (Effort vs.
         Duration)
     3.	 Максималното време което може да се просрочи
         един таск без да се отрази на проекта.
     4.	 Разпределяне на ресурсите по задачите
     5.	 Буферни таскове (Buffer tasks)
     6.	 Milestones и предварително насрочени срещи с
         клиентите
     7.	 Разработка на зависимостите м/у тасковете
     8.	 Проверка на графика
     9.	 Софтуери за Project Management (MS Project, Merlin)
     10.	 Примери – DoBand (Agile), MerchantGuard (малко
        milestones), the360 (много milestones и предварително
        насрочени срещи)
Срещи и комуникация с клиентите
                             1.	 Не забравяйте, че те са един от ключовете към
                                 успешен проект
                             2.	 Максимален брой Face-to-Face срещи
                             3.	 Подготвяйте си въпроси преди всяка среща и
                                 помислете какво биха Ви питали
                             4.	 Не ограничавайте комуникацията си с клиента само в
                                 срещите
                             5.	 Софтуери и online продукти помагащи за
                                 комуникацията по време на проекта:
                             6.	 Basecamp, Wrike, Lighthouse
                             7.	 Чести и ревюта и отчети са добра практика



Няколко съвета
Прозрачност   Гледайте да сте          Не прекалявайте           Бъдете активната
              максимално отзивчиви     с компютърните            страна в дебатите
              и ги накарайте да        термини, говорете на
              почувстват, че са        разбираем за тях език
              приоритет номер 1
Промени. Анализ и оценка на промените
              Промени. Анализ и оценка на промените
              Това е неизбежен момент, бъдете готови за него

              Анализ и оценка
              1.	 Колко време би отнела
              2.	 Как това ще се отрази на графика
              3.	 Колко би струвала на клиента
              4.	 Дали всъщност тази промяна въобще е нужна и можем ли
                  да минем без нея
              5.	 Обсъдете промяната с колегите си, работещи по проекта,
                  за се види и тяхното мнение по въпроса.

              Имайте предвид
              1.	 Програмистите не обичат промените!
              2.	Програмисткия неписан закон „Ако нещо работи, не го
                 пипай!” ;)

              Заплащането на промените
              1.	 Не издребнявайте в изискванията си за заплащане на
                  всичко
              2.	Но следвайте стриктно политиката си относно заплащането
                  на промени
Дизайн и програмиране



      1.	 Pair programming
      2.	 Програмистите не могат да тестват качествено
          собствения си код, вложете малко допълнителен
          ресурс в тази насока
      3.	 Задължително е и клиента да се намеси в тестовете
      4.	 Bug tracking системи – Lighthouse, Mantis
      5.	 Използвайте SVN
Благодаря за
вниманието!

More Related Content

Similar to CG&Web Seminar Lecture '10

Bl Consulting Ltd I Scala Pm Overview
Bl Consulting Ltd I Scala Pm OverviewBl Consulting Ltd I Scala Pm Overview
Bl Consulting Ltd I Scala Pm Overview
guest408cb05
 
Continuous integration (d.atanasov)
Continuous integration (d.atanasov)Continuous integration (d.atanasov)
Continuous integration (d.atanasov)Deyan Atanasov
 
"Особености на комуникациите в проектите според най - разпространените междун...
"Особености на комуникациите в проектите според най - разпространените междун..."Особености на комуникациите в проектите според най - разпространените междун...
"Особености на комуникациите в проектите според най - разпространените междун...
dessylicious
 
DrupalCamp Sofia 2015
DrupalCamp Sofia 2015DrupalCamp Sofia 2015
DrupalCamp Sofia 2015
Bozhidar Boshnakov
 
Rabota po proekti_new
Rabota po proekti_newRabota po proekti_new
Rabota po proekti_newLilyBankova
 
Rabota po proekti_new
Rabota po proekti_newRabota po proekti_new
Rabota po proekti_newLilyBankova
 
Професия IT специалист
Професия IT специалистПрофесия IT специалист
Професия IT специалист
rsabev
 
Стартиране на софтуерен бизнес - пътят от програмата до продукта
Стартиране на софтуерен бизнес - пътят от програмата до продуктаСтартиране на софтуерен бизнес - пътят от програмата до продукта
Стартиране на софтуерен бизнес - пътят от програмата до продукта
Neven Boyanov
 
Как да направим живота си по - лесен с добър QA подход
Как да направим живота си по - лесен с добър QA подходКак да направим живота си по - лесен с добър QA подход
Как да направим живота си по - лесен с добър QA подход
Bozhidar Boshnakov
 
Style and Standards in Technical Communications
Style and Standards in Technical CommunicationsStyle and Standards in Technical Communications
Style and Standards in Technical Communications
Mariana Vacca
 
Ролята на проектантите в контекста на предходните и бъдещите периоди на ОПОС ...
Ролята на проектантите в контекста на предходните и бъдещите периоди на ОПОС ...Ролята на проектантите в контекста на предходните и бъдещите периоди на ОПОС ...
Ролята на проектантите в контекста на предходните и бъдещите периоди на ОПОС ...
Emil Hristov
 
Курс - Качество на софтуера - част 1
Курс - Качество на софтуера - част 1Курс - Качество на софтуера - част 1
Курс - Качество на софтуера - част 1
Kalin Vasilev
 
Курс качество на софтуера - част 1
Курс качество на софтуера - част 1Курс качество на софтуера - част 1
Курс качество на софтуера - част 1
Kalin Vasilev
 
Стартиране на софтуерен бизнес - пътят от програмата до продукта
Стартиране на софтуерен бизнес - пътят от програмата до продуктаСтартиране на софтуерен бизнес - пътят от програмата до продукта
Стартиране на софтуерен бизнес - пътят от програмата до продукта
Neven Boyanov
 
Как се става програмист?
Как се става програмист?Как се става програмист?
Как се става програмист?
Svetlin Nakov
 
Nakov High Quality Code
Nakov High Quality CodeNakov High Quality Code
Nakov High Quality CodeSvetlin Nakov
 
Studio projects
Studio projectsStudio projects
Studio projects
iTransformers
 

Similar to CG&Web Seminar Lecture '10 (20)

Bl Consulting Ltd I Scala Pm Overview
Bl Consulting Ltd I Scala Pm OverviewBl Consulting Ltd I Scala Pm Overview
Bl Consulting Ltd I Scala Pm Overview
 
Continuous integration (d.atanasov)
Continuous integration (d.atanasov)Continuous integration (d.atanasov)
Continuous integration (d.atanasov)
 
"Особености на комуникациите в проектите според най - разпространените междун...
"Особености на комуникациите в проектите според най - разпространените междун..."Особености на комуникациите в проектите според най - разпространените междун...
"Особености на комуникациите в проектите според най - разпространените междун...
 
DrupalCamp Sofia 2015
DrupalCamp Sofia 2015DrupalCamp Sofia 2015
DrupalCamp Sofia 2015
 
Rabota po proekti_new
Rabota po proekti_newRabota po proekti_new
Rabota po proekti_new
 
Rabota po proekti_new
Rabota po proekti_newRabota po proekti_new
Rabota po proekti_new
 
Професия IT специалист
Професия IT специалистПрофесия IT специалист
Професия IT специалист
 
Стартиране на софтуерен бизнес - пътят от програмата до продукта
Стартиране на софтуерен бизнес - пътят от програмата до продуктаСтартиране на софтуерен бизнес - пътят от програмата до продукта
Стартиране на софтуерен бизнес - пътят от програмата до продукта
 
Project management
Project managementProject management
Project management
 
Как да направим живота си по - лесен с добър QA подход
Как да направим живота си по - лесен с добър QA подходКак да направим живота си по - лесен с добър QA подход
Как да направим живота си по - лесен с добър QA подход
 
Style and Standards in Technical Communications
Style and Standards in Technical CommunicationsStyle and Standards in Technical Communications
Style and Standards in Technical Communications
 
Ролята на проектантите в контекста на предходните и бъдещите периоди на ОПОС ...
Ролята на проектантите в контекста на предходните и бъдещите периоди на ОПОС ...Ролята на проектантите в контекста на предходните и бъдещите периоди на ОПОС ...
Ролята на проектантите в контекста на предходните и бъдещите периоди на ОПОС ...
 
Курс - Качество на софтуера - част 1
Курс - Качество на софтуера - част 1Курс - Качество на софтуера - част 1
Курс - Качество на софтуера - част 1
 
Курс качество на софтуера - част 1
Курс качество на софтуера - част 1Курс качество на софтуера - част 1
Курс качество на софтуера - част 1
 
Стартиране на софтуерен бизнес - пътят от програмата до продукта
Стартиране на софтуерен бизнес - пътят от програмата до продуктаСтартиране на софтуерен бизнес - пътят от програмата до продукта
Стартиране на софтуерен бизнес - пътят от програмата до продукта
 
Как се става програмист?
Как се става програмист?Как се става програмист?
Как се става програмист?
 
Nakov High Quality Code
Nakov High Quality CodeNakov High Quality Code
Nakov High Quality Code
 
Ogra s3-2010 success
Ogra s3-2010 successOgra s3-2010 success
Ogra s3-2010 success
 
Studio projects
Studio projectsStudio projects
Studio projects
 
Programirane i organizaciq
Programirane i organizaciqProgramirane i organizaciq
Programirane i organizaciq
 

CG&Web Seminar Lecture '10

  • 1. Здравейте, аз съм Стоян Христов Дипчиков. В следващия час ще ви запозная с проблемите на проджект мениджмънта и планирането.
  • 2.
  • 3.
  • 4.
  • 5.
  • 6.
  • 7.
  • 8. Успеваемост на проекти 65% провалени (19% провалени + 46% извън бюджет и срокове) 1. 65% от софтуерните проекти са неуспешни или проблемни (Standish Group) 2. 25-40% от работа по софтуерни проекти се изхвърля и прави наново (Carnegie Mellon) 3. 50% от проектите биват изваждани от експлоатация веднага след инсталацията си (Gartner) 35% succeded
  • 9. Бизнес анализ и успеваемост 65% провалени (19% провалени + 46% извън бюджет и срокове) 1. 40% от проблемите се откриват от крайните потребители (Garner) 2. Неправилно дефиниране на изискванията води до 66% от провалите (Forrester Research) 3. 60-80% от провалите на проекти са резултат от неправилно събиране и управление на изискванията (Meta Group) 35% успешни
  • 10. Развитие на проекта и дефекти Release Заключения Откриваеми на бъгове 40-50% Цена на промените Много Висока 1. Web сайтовете се разработват, за да изпълнят набор от Тест изисквания Откриваеми на бъгове 15-50% Цена на промените Висока 2. По-голямата част от бъговете се откриват след Реализация реализацията на Откриваеми на бъгове 10-15% проекта Цена на промените Средна 3. Изискванията са главния източник Дизайн на дефекти в Откриваеми на бъгове 5-10% проекта Цена на промените Ниска Изисквания Откриваеми на бъгове < 5% Цена на промените Ниска
  • 11. Защо се провалят проектите? Не се предвиждат бъдещите дефекти Някои от лошите навици Прибързване с започването на програмистите ;) на кодирането и дизайна Омагьосания кръг, в който Грешна оценка на проекта поставяме софтуерните тестери
  • 12. Как да осигурим успеха на проекта си? Поддържайте прозрачността в проекта Не пренебрегвайте Всички в екипа са равни бумащината Имайте доверие Проверявайте често проекта, на екипа си! пишете отчети често
  • 13. SDL (Software Development Lifecycle) Waterfall Agile Проект Изисквания Итерация Дизайн Удобрени промени Реализация Дневни промени Тест Начало Поддръжка Rup Начална подготовка Уточнения Изграждане Миграция
  • 14. Планирането на проект?!? Планирането на проект?!? Какво представлява планирането на проект? Начална фаза на планирането 1. Обхват на проекта (Scope) - Засегнатите лица по проекта / Stakeholders (Лице за контакт) и Ресурси (Вашите колеги + технически и други нужди за проекта) 2. Проблеми за решаване и анализ на рисковете 3. Интервюта с клиента и събиране на изискванията
  • 15. Техническо задание и wireframes Няма общо приета структура за технически задания. Моят пример: mes 1. Кратко описание на проекта и неговите цели wirefra 2. Използвани технологии 3. Засегнати лица 4. Речник 5. Описание на основните модули 6. Приложения (Flow charts, диаграми и описание на алгоритмите и т.н.) Wireframes (скици на проекта) 1. Защо са ни скици? 2. Начини за създаване на Wireframes: На ръка или чрез специализиран софтуер (Axure, Adobe Fireworks) 3. Не се увличайте в дизайн на wireframe-ите
  • 16. Оценка на проекта 1. Защо ни е нужна оценка? 2. Как процедираме в Despark? 3. Документирайте сроковете, който сте решили както и причината за определянето им, за да може после да ги съпоставите с реалните резултати и да ги анализирате
  • 17. График на проекта 1. Разбиване на проекта на малки под задачи, като за основа ползваме разписаните задачи от предната фаза на оценката 2. Труд за разработка на задача с/у Време (Effort vs. Duration) 3. Максималното време което може да се просрочи един таск без да се отрази на проекта. 4. Разпределяне на ресурсите по задачите 5. Буферни таскове (Buffer tasks) 6. Milestones и предварително насрочени срещи с клиентите 7. Разработка на зависимостите м/у тасковете 8. Проверка на графика 9. Софтуери за Project Management (MS Project, Merlin) 10. Примери – DoBand (Agile), MerchantGuard (малко milestones), the360 (много milestones и предварително насрочени срещи)
  • 18. Срещи и комуникация с клиентите 1. Не забравяйте, че те са един от ключовете към успешен проект 2. Максимален брой Face-to-Face срещи 3. Подготвяйте си въпроси преди всяка среща и помислете какво биха Ви питали 4. Не ограничавайте комуникацията си с клиента само в срещите 5. Софтуери и online продукти помагащи за комуникацията по време на проекта: 6. Basecamp, Wrike, Lighthouse 7. Чести и ревюта и отчети са добра практика Няколко съвета Прозрачност Гледайте да сте Не прекалявайте Бъдете активната максимално отзивчиви с компютърните страна в дебатите и ги накарайте да термини, говорете на почувстват, че са разбираем за тях език приоритет номер 1
  • 19. Промени. Анализ и оценка на промените Промени. Анализ и оценка на промените Това е неизбежен момент, бъдете готови за него Анализ и оценка 1. Колко време би отнела 2. Как това ще се отрази на графика 3. Колко би струвала на клиента 4. Дали всъщност тази промяна въобще е нужна и можем ли да минем без нея 5. Обсъдете промяната с колегите си, работещи по проекта, за се види и тяхното мнение по въпроса. Имайте предвид 1. Програмистите не обичат промените! 2. Програмисткия неписан закон „Ако нещо работи, не го пипай!” ;) Заплащането на промените 1. Не издребнявайте в изискванията си за заплащане на всичко 2. Но следвайте стриктно политиката си относно заплащането на промени
  • 20. Дизайн и програмиране 1. Pair programming 2. Програмистите не могат да тестват качествено собствения си код, вложете малко допълнителен ресурс в тази насока 3. Задължително е и клиента да се намеси в тестовете 4. Bug tracking системи – Lighthouse, Mantis 5. Използвайте SVN