Софтуерни технологии
Изтегляне 2.27 Mb.
|
Свързани:
empty doc
| Анализът се състои точно в този подбор на поредните средства за реализи-
ране. Съществено е, че всяко нещо, което този анализ определи като такова сред- ство, трябва да бъде ясно ориентирано към нуждите на потребителя, да подлежи на тестване и усилията за реализацията му да могат да бъдат отделени и оценени. Проектирането и програмирането се движат практически едновремен- но. В момента на определянето на средствата от поредната итерация се извърш- ва декомпозиция и планиране. Това означава, че точно определен брой програ- мисти получават точно определени задачи със също така точно определени сро- кове. Тъй като става въпрос за малки и ясни задачи, определянето на тези сро- кове не би следвало да е трудно, особено след първите итерации. Докато прог- рамистите работят — всеки по своята задача, потребителят, който продължава да е активен участник, създава функционални тестове. Тук има още една ха- рактерна и малко странна особеност — програмистите работят по двойки вър- ху дадена задача на един компютър. Това се свързва с необходимостта да се осигури валидност на създадения програмен модул при липсата на стандартни- те процедури. Последната е породена от съкратеното време и намалените дру- ги ресурси. Предвидена е възможността за контакт на двойката с потребителя по въпроси на функционалността или пък с най-опитните програмисти по тех- нологични въпроси, но винаги в рамките на не повече от 15 минути. В този процес на реализация почти веднага навлиза и тестването. При това има още една особеност: по логически причини тестването следва програ- мирането, но самите тестови примери се пишат предварително. Както е обичайно, при почти всеки тест се изявяват различни грешки, които следва да бъдат отстранени. При това винаги приоритет се дава на конструктивността, по-точно: ако двойката програмисти вижда „чист" начин за отстраняване на греш- ката, тя гo прилага незабавно; ако вижда "гpy6" начин и заедно с това се досеща и за ново проектант- ско решение, което би довело до „чисто" решение, то се прилага „чистото" ре- шение с препроектирането; ако вижда само "груб" начин без друга алтернатива — прилага се този „груб" начин. На всеки програмист е ясно какво се разбира тук под „чисто" решение — то е съобразено със запазване на всички добри качества на програмата — прег- ледност, ясна структура, способност за лесно модифициране, запазена просто- та и т. н. При втората алтернатива се предпочита все пак „чистото" решение, въпреки че то изисква повече време и усилия. С това се осигурява обаче по- лесното съпровождане на продукта в бъдеще. 191 Следва да се отбележи изрично — макар потребителят да задава свои фун- кционални тестови примери, тестването се извършва от самите програмисти. Смята се, че макар това да елиминира независимото тестване, при възприетия модел и при относително малкия обем на решаваните задачи това не води до отрицателни последствия по отношение на валидността на разработвания соф- туер. 15.2.4. Съвсем практически аспекти Дори при най-добре планираните разработки и добре комплектовани ко- лективи могат понякога да възникнат проблеми. Един не толкова рядко срещан случай е надценяването на собствените (на колектива) възможности. Идва момент, в който става ясно, че сроковете няма да бъдат спазени. Ако този момент е все още достатъчно отдалечен от крайния срок, възможна е оценка на прилаганите процедури и евентуални про- мени в тях. Може обаче да се окаже, че е късно за дадения проект да се правят резул- татни промени. Няма друга възможност, освен изпълнителят да се обърне към възложителя и да поиска някаква форма на облекчение — удължаване на срока, временен отказ от определени планирани за реализация функции, отлагане на дадено средство за следващата итерация. Във всички случаи отрицателните стра- ни на такъв подход са по-добро решение, отколкото сляпата надежда за благоп- риятен изход в последния момент. Друг доста често срещан случай са клиентите (възложители), които не са склонни твърде да общуват с разработчика. Те не искат да определят средствата за реализация в поредната итерация, нито пък да създават тестови примери. На пръв поглед това не е никак лошо, но опитният софтуерист знае много добре, че в един момент спестеното време и неприятни моменти от липсата на комуни- кация с възложителя ще му се стоварят в двоен и троен размер, когато клиен- тът започне да експлоатира продукта и реши, че не е получил това, което си е представял. Ясно е, че всякакви промени на този стадий са много по-трудни (понякога невъзможни) и по-скъпи. Обикновено опитният изпълнител се е пог- рижил чрез подписания договор да няма никакви задължения за промени в та- къв късен момент. Но дори само усилията да убеди клиента в правотата си са достатъчно неприятни и отнемат време. Да не говорим, че ефектът от един неу- довлетворен потребител (макар и изключително по негова собствена вина) е във всяко отношение отрицателен за разработчика. Следователно разработчикът просто е длъжен във възможно най-ранен мо- мент да убеди възложителя да му сътрудничи. Във всички случаи, но особено при ХР е абсолютно недопустимо по време на разработката програмистът да се уповава на собствените си догадки вместо на ясно изразените изисквания на възложителя. Вероятно най-доброто решение е да се обяснят максимално наг- ледно на възложителя тежките последици от нежеланието му да участва в кръга на своята компетентност в разработката. Ако дори тогава няма резултат, изво- дът е, че сигурно тази разработка не си струва усилията. Друг важен практически проблем е текучеството. За България този проб- лем съдържа и известен момент на безвъзвратност, доколкото движението на 192 програмистите към чужбина е особено интензивно и не толкова често веднъж заминалите се връщат. А ако се върнат, това е знак, че може би програмистът не е чак толкова добър специалист. Впрочем известен „оборот" на членовете на колектива действа освежаващо. Ръководителят на екипа обаче винаги следва да се интересува от мотивите на напускащия. Ако те са свързани с по-добри мате- риални условия, каквито една малка софтуерна фирма по-трудно може да оси- гури, това не е толкова тревожно, най-малкото едва ли може да му се противос- тои. Ако обаче мотивите на отиващия си се дължат на нисък професионализъм във фирмата, на недобра атмосфера, на лоша организация, на неудовлетворе- ност от равнището на разработваните проекти, това би следвало да бъде сигнал за сериозния ръководител. Естествено, тук стои въпросът и доколко един на- пускащ програмист може да навреди на фирмата, отнасяйки със себе си опре- делена информация, натрупана по време на работата му там. От една страна това, че се работи в двойка, запазва почти напълно възможностите на колектива безболезнено да продължи работата си. От друга страна, са общите проблеми от опасностите от изнасянето на информация навън от фирмата, но това е тол- кова общ проблем, че разискването му тук не е смислено. Изтегляне 2.27 Mb. Сподели с приятели:
|