„Здрасти, Амиго!“
„Здравей, Билаабо!“
„Днес ще ви разкажа How обикновено се разработват програмите.“
„През 20-ти век, когато модерните ИТ бяха в начален стадий, изглежда всички смятаха, че програмирането е като строителство or производство.“
„Нещата обикновено вървяха по следния начин:“
„ Клиентът би обяснил типа програма, от която се нуждае – Howво трябва да прави и How трябва да го прави.“
„ Бизнес анализаторите щяха да го изслушат и да направят пълен списък с програмни изисквания въз основа на казаното от него.“
„Тогава мениджърите на проекти биха разделor тези изисквания на задачи и също така биха определor кой програмист Howва задача ще изпълни и в Howъв ред.“
„Тогава програмистите се захващаха за работа. Понякога работеха няколко години(!).“
„Когато бяха готови, програмата беше дадена на тестери.“
„ Тестерите щяха да преминат през всяко от изискванията на програмата, за да проверят дали са изпълнени и че програмата работи Howто трябва.“
„Ако нещо се обърка, тестерите ще регистрират бъговете и ще ги изпратят на програмистите.“
„Тогава програмистите ще коригират грешките и ще изпратят коригираната програма обратно на тестерите. И цикълът ще се повтори.“
„Когато основните грешки бяха коригирани, програмата беше дадена на клиента.“
— Така ли се развиха нещата?
„Е, разбира се, опростих много, но това е доста близко до начина, по който се правеха нещата.“
„И завършването на един проект наистина може да отнеме година и половина до две години?“
„Понякога, ако разработката на даден проект беше наистина дълга, те го разделяха на отделни издания. На всеки 3-6 месеца разработчиците трябваше да създават специфична част от функционалността на програмата, да я тестват, да коригират всичките й грешки и да я показват на клиент."
"Първо, за да може да сподели впечатленията си. И второ, което е по-важно, за да продължи да плаща за развитието на програмата."
„Продължавам да плащам?“
„Тогава разработката често отнемаше 2-3 пъти повече от планираното. И тъй като на програмистите често се плащаше на час, програмата ставаше 2-3 пъти по-скъпа. Нещо повече, ползите също бяха намалени. В крайна сметка Howво иска клиентът днес за $100 000 може да не са необходими след 3 години - особено на три пъти по-висока цена."
„Клиентите често ли отказват да плащат?“
"Да. По-късно започнаха да добавят неустойки към договора, но това не подобри ситуацията. Разработката на софтуер се проточи и продължи. И никой не можеше да направи нищо по въпроса, дори и да искаше."
"Но защо?"
"Е, първо, твърде малко се знае по време на етапа на планиране. По-често, отколкото не, в началото никой не можеше да предвиди проблемите, пред които ще се изправят програмистите."
„Но опитните програмисти трябваше да могат да предвидят всичко, нали?“
„Виждате ли, че програмирането е уникална професия.“
"Обикновеният работник често върши една и съща работа отново и отново. Часовникарите правят часовници, готвачите готвят, учителите преподават, лекарите лекуват и т.н."
"Всеки от тези професионалисти прави основно едно и също нещо ден след ден. В резултат на това те започват да стават все по-добри и по-добри в работата си."
"В програмирането подходът е различен. Щом програмистът се сблъска с една и съща задача всеки ден, той пише функция, модул or програма, за да я изпълни, и никога повече не се връща към нея."
"Всеки програмист обикновено решава всяка задача веднъж в живота си."
„Нещо като учени or инженери-конструктори, които измислят неща.“
"А, добре, коя е най-важната роля в един проект?"
"Хм, How да отговоря на това. Лесно е да се каже кое е най-важното, но идентифицирането на най-малко важното е трудно."
" Основната работа на тестера ( Quality A assurance , QA ) е да наблюдава състоянието на програмата и да докладва за грешки своевременно. Колкото повече и по-рано тестерът открие грешки, толкова повече те могат да бъдат коригирани. Добрият тестер влияе повече върху качеството на продукта, отколкото добрият програмист го прави ."
"Защо програмистите не могат да тестват собствените си програми. В крайна сметка те не знаят ли по-добре от тестерите Howво работи и Howво не?"
„Добрият програмист просто не е в състояние да бъде добър тестер. Програмистът знае How работи програмата наистина добре, така че той or тя винаги я използва по определен начин. За разлика от обикновените потребители, които използват програмата, Howто искат. "
„Освен това тестерите не тестват това, което все още не работи. Тестерът тества функционалността or частите от програмата, за които програмистът казва, че вече работят почти перфектно.“
„И когато тестерът открие тонове грешки в тази функционалност и програмистът ги поправи, тогава продуктът всъщност се доближава до съвършенството.“
" Основната задача на програмиста ( S oftware D Developer E ngineer, D eveloper , SDE ) е да внедри нова функционалност. Или, казано по-просто, да изпълни възложените му or нея задачи. Когато на програмистите се възлагат задачи с нови функции , те ги изпълняват. Когато им се задават грешки, те коригират грешки."
„Но понякога има по-предизвикателни задачи, например да се измисли архитектура за програмата or части от нея. Колкото по-добра е предложената архитектура, толкова по-лесно ще бъде да се свършат нещата в бъдеще.“
„Проблемът е, че архитектурата трябва да бъде избрана в самото начало, но едва когато сте в средата на разработката, е ясно дали сте избрали правилната архитектура.“
„Освен това, ако архитектурата е успешна и програмата се окаже страхотна, тогава клиентът вероятно ще иска да я използва като основа за нови версии на програмата.“
— Ето Howво имам предвид.
„Каквато и архитектура да изберете, винаги ще има куп промени, допълнения и нови функции, които архитектурата не отчита.“
— Ето един добър пример.
„Клиент ви моли да построите 5-етажна сграда, така че вие проектирате архитектура и построявате къщата.“
„След това клиентът иска да добави още една история, след това друга и така нататък.“
„Но стените на първия етаж не са проектирани за толкова голяма тежест, Howто и основата. Така че всичко трябва да се преработи.“
„Но след като 5-етажната сграда е готова, Howво ще стане, ако клиентът веднага реши, че иска 50-етажна сграда?“
„Би било по-лесно да разрушим съществуващата структура и да възстановим всичко от нулата…“
„Но имам един съвет за вас по отношение на архитектурата.“
„Архитектурата на едно приложение трябва преди всичко да бъде гъвкава, което означава, че няма да се налага да започвате от нулата, ако решите да преработите половината от приложението. Този тип архитектура обикновено се нарича гъвкава и модулна . “
" Основната работа на ръководителя на проекта е да взема решения. Мениджърът на проекта е този, който вижда голямата картина и взема решения въз основа на тази перспектива."
„Да предположим, че по време на разработката стане ясно, че определена задача няма да бъде завършена по план. Тогава ръководителят на проекта може:“
" а) опитайте се да преговаряте с клиента за промяна на задачата"
„ б) отделете повече време за задачата“
" в) привличане на по-опитни програмисти от други проекти."
— И има много други възможности.
„Всяка опция изисква да пожертвате нещо и работата на мениджъра е да минимизира общите загуби от тези жертви. “
„Да предположим например, че конкурентите откраднат водещия програмист, като му предложат два пъти повече пари.“
„Ръководителят на проекта може:“
" а) не правете нищо. Програмистът ще напусне и проектът вероятно ще изостане и ще понесе санкции."
" б) удвои заплатата си. Тогава всички останали в екипа също ще искат повишения. Ако дадете на всички повече пари, тогава разходите на проекта ще се увеличат и той може да стане нерентабилен."
" в) няHowва друга опция, която измислите."
"Виждам."
„С лош мениджър на проекти добрият екип обикновено удължава проекта, но не винаги.“
„Добрият мениджър с екип от средностатистически програмисти почти винаги ще завърши проект по-бързо от лошия мениджър с екип от отлични програмисти.“
"Виждам."
— Добре, нека направим кратка почивка и след това ще продължим.
GO TO FULL VERSION