29 ÅÍÅÐÃÈß 5'2016 енергия Р Е К Л А М А Р Е К Л А М А лите, обикновено е компетентен само по част от целите на проекта. Освен това, той може и да не разбира технологиите и инструментите, използвани от екипа. Понякога в проекта се включват и други представители на клиента, които дават главно устни консултации. Консултациите са дадени набързо и само в устна форма или са лошо документирани и не са много полезни в дълговременен план. Тесните неформални и дори непрофесионални взаимоотношения между тестващи/валидиращи специалисти и разработчици или между управляващи проекта и клиента могат да доведат до значителни рискове, например пропускане на грешки, поемане на неизпълними ангажименти и т.н. Липсата на детайлни писмени процедури и процеси за тестване, валидиране и качествен контрол води до изпълнение на проекта с много скрити дефекти, което е неприемливо за критичните приложения. Най-важният критерий за ефективността на ГМ е доставката на работещ продукт, като критериите за това може и да не са съвсем ясни. Проблемът е там, че при липса на точни изисквания за продукта един работещ продуктможе да работи сам за себе си и през по-голямата част от времето, но да има множество грешки, който да го правят нестабилен или да не се покрива с крайните очаквания на клиента. Освен това, терминът „работещ продукт” може да има толкова дефиниции, колкото са и приемащите и използващите резултатите от проекта специалисти и е по принцип неясен и противоречив. Много по-добре е да се специфицира надеждността на продукта и да има пълни изисквания, срещу които да се тества и валидира резултатът от проекта. Простотата на изпълнението на проекта е съществена черта на ГМ. Но простотата е и понякога субективно свойство. Освен това, някои проекти имат толкова много изисквания, че няма начин да се намери просто и цялостно решение за проекта. Т.е. при ГМ често липсват обективни количествени измерителни параметри за простотата и достатъчността за завършване на проекта. Постоянната интеграция, т.е. прекалено честото създаване на версия на продукта, създава понякога огромно количеството версии на продукта, коитотрудно се контролирати сравняват, за да се определи полезността им. Тези постоянни дейности могат да се окажат излишно разпиляване на сили и средства в проекта и да не доведат до очаквания резултат. ГМ на теория отричат основните цикли на традиционните проекти, които обикновено се свеждат до няколко нива на изработка и детайлизиране на изискванията къмпроекта, разработка на общо решение, детайлизация на общото решение, намиране на решение за детайлите на проекта, тестване на детайлите от проекта и на сглобени (интегрирани) части от проекта, тестване, валидиране и приемане на целия проект, поддържане на проекта, повторно използване на части от проекта или тяхното рециклиране и напълно унищожаване и затваряне на проекта. Но всъщност ГМ повтарят голямата част от тези етапи многократно, върху малки порции от проекта, като не оставят много документация след себе си, твърдейки че това оскъпява и забавя проекта и че не е нужно. Оскъпяването на проекта заради разработката на документация може и да е вярно, но навременното и точното документиране е абсолютно задължително за по-дългосрочните и по-важните проекти.
RkJQdWJsaXNoZXIy MTEyMTYwMw==