PM Stories

Пътят на Agile през 21-ви век

Майк Рам — Thu, 17 Sep 2009 07:52:36 +0000

Гъвкавият (Agile) подход при разработване на софтуерни проекти винаги е предизвиквал противоречиви чувства в мен. Може би защото повечето хора, които го проповядват, всъщност не го разбират, и така той остава неразбираем и за другите.

Alistair Cockburn е един от хората, които са измислили идеологията и принципите на Agile, един от хората, подписали The Agile Manifesto – основополагащия документ на гъвкавото движение, а както се оказа – един изключително интелигентен и отворено-мислещ човек.

Предлагам ви един видео запис от негова презентация на конференцията Agile 2009, където той споделя виждането си за пътя на Agile – откъде е тръгнал подхода, какви са новите предизвикателства пред него и какви са посоките, в които трябва да се развива, за да бъде успешен.

Презентацията е много земна, разказана на разбираем език, с много примери от живота и други производства и с много свеж хумор, така че със сигурност ще ви провокира да помислите над това как работите в момента и как бихте могли да подобрите своите производствени процеси.

Онова, което аз започвам да проумявам като голяма заблуда, е опитите да се противопоставят т. нар. “класически методологии” и “водопадния подход” на “гъвкавите методологии” точно като практики и методологии на организацията. Истината за мен е, че разликата е в мисленето, в отношението между хората и в много по-активната комуникация.

Някои хора твърдят, че наличието на проектен мениджър убива проекта, защото той пречи на креативността на екипа. Това са пълни глупости! Креативността на екипа не може да бъде спряна, ако съществува въобще. И един добър проектен мениджър може да помогне много за нейното развитие и резултатност.

Истината е, че успехът на един екип и на проектите, с които той се занимава, зависят от самите хора и от тяхната нагласа. Организационната структура не е толкова важна. Тя зависи от множество характеристики на самия проект. По-важно е какви са хората в екипа и каква е тяхната мотивация.

Ако екипът е мотивиран да произведе супер продукт и търси начини да подобри начина си на работа, той ще го постигне независимо от конкретната организационна структура. Ако екипът не е мотивиран, той ще намери оправдание не само в “тъпия ПМ”, но и в “скапаната ни държава”, във фазата на луната, в земното притегляне и в какво ли още не.

Проектният мениджър, пък, ако е точният човек, може да запали мотивацията на екипа и да създаде по-добри условия, в които тяхната креативност да се развива. Ако ли не – ще отнесе всички обвинения.

Agile е начин на мислене и на общуване, а не толкова нова организационна структура. Това разбирам аз от презентацията на Cockburn и мисля, че това разбиране би помогнало на много екипи и мениджъри да бъдат по-ефективни, особено в днешните кризисни времена.

Презентацията трае близо един час, след което са записани и въпроси от публиката, но определено си струва гледането. Този час няма да бъде загубен за вас – сигурен съм, че ще ви даде полезни идеи как да подобрите своя начин на работа.

Гледайте я!

Гласувайте за тази статия в Svejo.net:

Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се за съдържанието му чрез RSS feed или по имейл.

Вижте и тези публикации:

Краят на софтуерното инженерство?

Майк Рам — Thu, 30 Jul 2009 05:10:19 +0000

Tom DeMarco, един от големите световни специалисти по управление на софтуерни проекти, автор на една от най-важните книги за управлението на хора – Peopleware – разбуни духовете наскоро с публикуването на една своя статия, в която се отрича от предишните си вярвания за смисъла и важността на софтуерното инженерство, обявявайки го за ненужно.

Какво, всъщност, представлява софтуерното инженерство?

Терминът на английски е software engineering и в компютърните среди все още няма консенсус относно неговото точно значение. Някога, в зората на компютърната индустрия, са смятали, че софтуерното производство трябва да се постави на научна основа и да се разглежда като инженерно-техническа дейност, която може лесно да се планира и контролира. Тази идея бързо се възприема от бизнеса, който все повече иска да измъкне програмирането от научните лаборатории и да го вкара в производствените цикли на печеленето на пари.

На тази идея се противопоставят привържениците на “софтуерното занаятчийство”, които твърдят, че програмирането си е майсторлък и не може да го вкараш в калъп или да му поставяш ограничения. Това е творчески процес, който изисква вдъхновение, вглъбяване и талант.

Факт е, че днес софтуерното производство вече е бизнес като всеки друг, но пък OpenSource движението показа, че може да бъде и некомерсиална дейност, бореща се за качествени продукти без значение от цената. Остава въпросът

дали програмирането наистина е инженерна дейност?

Том ДеМарко смята, че инженерната страна на софтуерното производство се състои във възможността да го измерваш и контролираш. Той е авторът на популярната сентенция “Не можеш да контролираш онова, което не измерваш“. Днес, обаче, той се отрича от възгледите си, че контролът е най-важното нещо в един проект.

За да разберете истинската роля на контрола, представете си два напълно различни проекта:

Проект А, който евентуално ще струва 1 милион долара и ще донесе печалба около 1.1 милиона долара и

Проект Б, който евентуално също ще струва към 1 милион долара, но ще донесе приходи от над 50 милиона долара

Очевидно е, че контролът е от голямо значение за Проект А, но почти не играе роля за Проект Б. Това веднага води до странното заключение, че стриктния контрол има голямо значение за относително безполезни проекти и много по-малко за истински полезните проекти. Излиза, че колкото повече се фокусирате върху контрола, толкова по-вероятно е да работите върху нещо, което носи минимална полза.

За мен, по-важният въпрос не е как да контролираме софтуерните проекти, а защо, по дяволите, се занимаваме с толкова много проекти, от които ползата е почти нищожна?

И още:

За последните 40 години се тормозехме от неспособността си да завършим своите проекти навреме и в рамките на бюджета. Но това въобще не е трябвало да бъде нашата главна цел. Много по-важна цел е трансформацията, да създадеш софтуер, който да промени света или дори да промени само една фирма и начина, по който тя прави своя бизнес.

С тези си думи, Том ДеМарко направо разбива концепциите за управление на проекти, които битуват сред големите организации, но, честно да си кажа, сякаш има право. Не случайно дори и сред популярните блогъри по темата за управление на проекти и производство на софтуер се появиха разногласия и много емоционални коментари. Предлагам ви да прочетете мненията на Jeff Atwood, който подкрепя идеята на DeMarco, и на Glen Alleman, който я отрича.

Разбира се, задължително прочетете статията на Tom DeMarco (в PDF формат).

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Международният институт по бизнес анализ обновява сертификационният си изпит

Майк Рам — Wed, 29 Jul 2009 11:55:10 +0000

Това е прес-съобщение от Българската секция на Международния институт по бизнес анализ.

Международният институт по бизнес анализ (International Institute of Business Analysis – IIBA) обновява сертификационен изпит Certified Business Analyst Professional (CBAP). Считано от 1 август 2009 г. новата версия на изпита ще включва ново съдържание, съответстващо на обновените и подобрени стандарти на института.

Промяната е в съответствие с публикуваната през март 2009 г. версия 2.0 на Business Analysis Body of Knowledge Guide (BABOK). След нейното публикуване бе даден период от четири месеца на започналите своята сертификация по версия 1.6 да завършат процеса, преди изпита да бъде обновен в съответствие с новия стандарт.

Новата версия на стандарта бе представена от Петър Лефтеров, вицепрезидент по образованието към българската секция на Международният институт по бизнес анализ, на среща-семинар, организирана съвместно с Технологика ЕООД.

Събитието се проведе на 23 юли 2009 г. в сградата на Факултета по Математика и Информатика към СУ „Св. Климент Охридски” и събра повече от сто експерти в областта на бизнес анализа. На срещата бе разгледана темата за използване на методологията АРИС за моделиране на бизнес процеси, изнесена от Борис Борчев, мениджър „Управление на бизнес процеси и проекти” в Технологика. Софтуерният специалист Георги Георгиев представи и опита на фирмата в управлението на софтуерни изисквания в рамките на целия жизнен цикъл на софтуерен проект.

Костадин Купенов, президент на българската секция на IIBA, съобщи че българската секция ще продължи практиката за редовни срещи-семинари в сферата на бизнес анализа и ще партнира с български организации и ИТ компании по инициативи, свързани с развитието на професията.

За повече информация посетете сайта на Българската секция на IIBA.

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Софтуер за Code Reviews само за $5! 5-дневна оферта

Майк Рам — Tue, 14 Jul 2009 09:28:43 +0000

Компанията SmartBear чества излизането на версия 5.0 на техния основен продукт CodeCollaborator и предлага невероятна оферта продавайки пакет от 5 лиценза за техния олекотен продукт CodeReviewer само за $5!

Офертата е валидна само за 5 дни: от 13 до 17 юли 2009 г.

Аз бях много заинтригуван от това предложение и си направих труда да прочета малко повече за продукта. Изглежда много полезен, ако практикувате редовни ревюта на кода във вашата фирма. Ако пък не го правите – вероятно вашият кода крие потенциални проблеми.

За $5 вие не получавате основния продукт CodeCollaborator, който е изключително богат на възможности, а неговия “по-малък братовчед” CodeReviewer, който е с малко по-ограничени възможности. Можете да видите разликите между двата продукта тук , но веднага става ясно, че възможностите на CodeReviewer са задоволителни за всеки екип, койтоиска да подобри практиките си на писане на програмен код, а цената е повече от атрактивна.

Не пропускайте тази възможност – струва си!

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Петък – ден на майстора. Забавни компютърни цитати

Майк Рам — Fri, 10 Jul 2009 05:10:33 +0000

В края на работната седмица ви предлагам една развеселяваща доза цитати и оригинални мисли за компютри, програмиране и програмисти. Насладете им се!

- Колко хардуерни инженери са необходими, за да се смени една крушка?
- Николко. Ще го оправим в софтуера.

- Колко програмиста са необходими, за да се смени една крушка?
- Николко. Ще го документираме в ръководството.

- Колко инженери от Microsoft са необходими, за да се смени една крушка?
- Николко. Ще дефинираме тъмнината като индустриален стандарт.

- Колко документатори са необходими, за да се смени една крушка?
- Николко. Потребителят ще се оправи и сам.

Анонимен

—

Непрекъснатата принтерна хартия е най-здрава в перфорациите.

Закон на Мърфи за принтерната хартия

—

Целта на компютърната наука е да създаде нещо, което ще просъществува поне докато го създаваме.

Анонимен

—

Всяка програма е част от друга програма, но рядко си пасват.

Пълно издание на вътрешните майтапи в Microsoft, том III

—

Когато една програма отказва да работи според спецификацията, сменете спецификацията. По-лесно е, отколкото обратното.

Брифинг пред новопостъпилите програмисти в Microsoft, 1995

—

Информационен център: Зала, пълна с компютърни специалисти, чиято работа е да ти обяснят защо не можеш да получиш информацията, която ти трябва.

Дяволския речник на компютърните науки

—

Ако кодът и коментарите се разминават, значи и двете вероятно са грешни.

Норм Шрайър

—

Всяка програма има поне един бъг и може да бъде съкратена поне с една инструкция, откъдето по индукция следва, че всяка програма може да бъде докарана до една единствена инструкция, която няма да работи.

Анонимен

—

Бог създаде машинния език. Всичко останало е дело на човека.

Анонимен

—

Истинските програмисти на пишат на PL/I. PL/I е за онези програмисти, които не могат да решат дали да пишат на COBOL или на FORTRAN.

Programmers’ World

—

Език за програмиране C: Един нов език, който комбинира гъвкавостта на Асемблер с мощта на Асемблер.

Въведение в С на Мърфи

—

Език, който на променя начина ти на мислене в програмирането, не си струва да го знаеш.

Алекс Лу за програмирането на Java

—

В основата на всяка грешка, за която обвиняваме компютъра, стоят поне две човешки грешки, включително и грешката да обвиняваме компютъра.

Анонимен

—

Очаквам всеки момент някой да изобрети едно кръгло нещо, което да се търкаля по земята и да намали триенето, но за това ще му трябва поне 233-мегахерцов Pentium процесор.

Гари Харант, Австралия

—

Краят на света дойде. Моля излезте от системата.

Съобщение при изход от системата Posix 2.1.1

Цитатите в оригинал можете да видите в английската версия на блога, а тук и тук можете да намерите още. Приятно прекарване!

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Добрите практики на софтуерното производство – анкета

Майк Рам — Thu, 09 Jul 2009 05:10:59 +0000

Компанията Construx, собственост на един големите гурута на софтуерния бизнес – Steve McConnell – е разработила доста обемиста анкета за проучване на добрите и полезни практики в разработването на софтуер – като се тръгне от събирането и анализа на изискванията, мине се през писането на код и тестването и се стигне до управлението на проекти. Авторът призовава всички, които се занимават в тази област да отделят малко време и да се включат в изследването, за да може по-късно събраните данни от всички участници да ни покажат кое е наистина полезно като практика и върши работа, и кое – не.

Аз се включих в анкетата и наистина времето за попълването е между 30 и 60 минути, но вие не сте длъжни да попълвате всички категории, особено пък ако не се занимавате с всички описани дейности. Можете да дадете мнение само за онези дейности, с които активно се занимавате и с които имате най-много опит. Тогава би трябвало да се справите за 20-ина минути.

Под всяка таблица с полезни практики има обяснение кое какво означава, защото термините са взети от различни теории и методологии и е възможно с голям част от тях да не сте запознати. Преди да отговорите е добре да прочетете добре обясненията и ако не познавате някоя практика или не я употребявате – просто не пишете нищо за нея.

Призовавам ви и аз да се включите в тази анкета. Steve McConnell е човек с голяма ерудиция и идеята да се оценят по-известните теоретични подходи според практическото им използване и ефективност, е много добра. Така ще можем да получим една по-реална представа кои техники носят реална полза в практиката.

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Почти перфектно

Майк Рам — Mon, 29 Jun 2009 05:10:45 +0000

“Almost Perfect” или “Почти перфектно” се казва книгата на W. E. Pete Peterson, бивш изпълнителен директор на WordPerfect Corporation, в която той разказва историята на създаването на един от най-успешните софтуерни продукти в света, на възхода и падението на фирмата, на ентусиазма и главозамайването на нейните създатели, както и собствената си личностна драма.

Книгата е много интересна, поне за онези, които се интересуват от софтуерния бизнес. Издадена е още в 1993 г. за първи път и е продала само 10 000 копия, след което е спряна от печат. За наше щастие, авторът я е публикувал онлайн и можете да я прочетете от тук. Освен това, се предлага и в PDF вариант, за онези, които предпочитат да я четат офлайн. (Специални благодарности на Jeff Atwood за линковете.)

Честно казано, не знам защо издаделите са свалили книгата от печат. Тя е невероятен учебник по мениджмънт и маркетинг, по креативност и по история на информационните технологии. Еволюцията, която една група младежи изживяват от голия ентусиазъм да изпрограмират нещо готино, до статута на мултимилионери и до тъжния фалит на края е изключително интересна и поучителна.

WordPerfect е първата истинска текстообработваща програма в света. По-младите читатели сигурно не биха могли и да си представят първите текстови редактори, които обработваха текста ред по ред, а не параграф по параграф, както е днес. А когато Microsoft решават да навлязат и да завладеят пазара на текстови редактори, той вече е доминиран от WordPerfect и борбата става особено жестока.

Книгата представя и доста откровено личната трансформация, която Pete Peterson изживява. От човек, който просто си търси по-интересна работа, до изпълнителен директор, който поема целия бизнес на фирмата срещу (забележете!) само 1% дялово участие в акциите, до закостенелия диктатор, от когото всички искат да се отърват.

Ето няколко цитата, които ще ви заинтригуват:

Откакто продажбите на версия 3.0 стартираха, фирмата започна да изглежда като бърз влак, движещ се напълно неконтролируемо. Ние не можехме да го спрем, не знаехме как да го управляваме и не бяхме сигурни къде искаме да стигнем. Единственото, което можехме да направим, е да устискаме и да се надяваме, че всичко ще свърши добре.

***

Ние бяхме една група от приятели, роднини и съседи, всички работещи здраво и даващи най-доброто от себе си, но нямахме каквато и да е формална структура в нашата организация. Срещите се провеждаха по коридорите, където двама или повече човека се срещаха случайно. Нямахме никакви официални методи за обсъждане на идеи или вземане на решения. Ако някой дойдеше с идея, ние обикновено я изпробвахме. Единственото ограничение за нашите експерименти беше наличната сума в банката. Ако можехме да си го позволим, го правехме.

***

Огромното нарастване на продажбите означаваше, че имаме нужда от от още хора, повече офисно пространство, повече компютри и телефони. Вероятно имахме и повече структурираност в организацията, но по онова време не знаехме как да го постигнем. Нашата семейна компания от вида “един за всички, всички за един” работеше добре с 25 служители, но започна да се пропуква, когато станахме повече от 50. Много неща се случваха по онова време и изглежда, че никой не разбираше защо. Беше проблем да държим всички хора информирани и да работят заедно. Трябваше да продължим да назначаване нови хора в разработката, в маркетинга, в клиентската поддръжка, в производството и отдела за поръчки, но за съжаление, им давахме почти никакво обучение и твърде слаб контрол. Всеки отдел беше самостоятелна малка империя със свои собствени правила и процедури.

***

Не беше обичайно една софтуерна компания да остави програмистите да определят бъдещето на нейните продукти. Ние, обаче, бяхме компания, създадена и притежавана от програмисти, в която програмистите бяха на изключителна почит. Маркетинг отделът основно се занимаваше да продава продуктите, след като вече бяха разработени и много рядко беше включван в ранните етапи да изпълнява традиционната си маркетингова роля да идентифицира пазарна нужда и да определи продукт, който да я задоволи. Понякога това ни поставяше в ситуация да разработваме решения преди да сме идентифицирали проблема, но не можехме да бъдем много критични към своите програмисти, при положение, че фирмата беше толкова успешна. Често те просто манипулираха данните, които получаваха, за да постигнат това, което си бяха наумили.

***

WordPerfect Corporation не беше платформа за лични постижения, кариерна стълба към други възможности или предизвикателство за личностно развитие. Фирмата не поставяше нуждите на личността пред своите собствени. Компанията не се интересуваше от личните чувства на служителите си, освен ако не бяха свързани с нейното собствено съществуване.

През май 1990 Microsoft пуснаха Windows 3.0 и нашите най-големи страхове се превърнаха в реалност. Точно, когато убедително печелехме пазара на текстови редактори за DOS, светът на персоналните компютри искаше Windows, бъгове и всичко останало. За да бъдат нещата още по-зле, Microsoft Word for Windows вече беше на рафтовете на дилърите и получаваше много добри отзиви. Този малък облак на хоризонта, който изглеждаше съвсем безобидно през 1986, беше вече навсякъде около нас, изглеждащ зловещо и заплашително. Силата и големината на IBM вече не можеха да ни предпазят. Дори и слон не можеше да игнорира приближаващата буря.

***

Следващите няколко месеца бяха много трудни. Аз преживях всички емоции, типични за хората, загубили работа. Преминах през периоди на отричане, тъга, депресия, яд и примирение. Беше ми много трудно да загубя своята WordPerfect идентичност с нейния статус на полу-звезда. Липсваха ми обедите и тенис мачовете в късния следобед, когато работехме върху всички важни проблеми. Липсваха ми битките с Microsoft. Открих, че да се пенсионираш на 43 години не е чак толкова привлекателно, както повечето хора си представят.

***

WordPerfect Corporation вече не съществува. Когато опитите да я направят публична се провалиха, Alan и Bruce продадоха своите дялове на на Novell. Когато продажбите на WordPerfect спаднаха, Novell продаде повечето от продуктите на WordPerfect на Corel на много ниска цена. Въпреки, че WordPerfect все още се ползва от милиони потребители по света, Corel има големи проблеми да изкарва пари от този продукт. Microsoft е много як конкурент.

***

WPCorp се похарчи до смърт. Последната пълна година, когато аз бях там (1991), продажбите бяха приблизително $600 милиона, а счетоводната печалба беше $200 милиона. През 1992, продажбите паднаха до близо $570 милиона, но разходите нараснаха толкова, че достигнаха приходите. През 1993 продажбите бяха около $700 милиона (ако може да се вярва на това число), но разходите нараснаха над $700 милиона. Броят на служителите от началото на 1992 до края на 1993 нарасна от 3300 на 5500 човека и фирмата кървеше пари.

***

Novell пострада най-много. Вместо златна крава, обещаваща продажби от $880 милиона и печалба от $100 милиона, WordPerfect беше дупка, в която парите потъваха, с много по-малко реални продажби и загуби от $100 милиона. Novell купиха потъващ кораб и никога не са имали реален шанс да оправят нещата. Самите Novell бяха здраво загазили (и все още са) и не можеха да оправят собствения си кораб, камо ли нечий друг.

Историята прилича на сапунен сериал, но е много ценна като урок по бизнес. Освен това, книгата е написана много увлекателно и се чете много бързо. А като добавим, че в ролята на Големия Лош Вълк играят Microsoft, предполагам, че всички ще се заинтересуват от нея

Струва си! Препоръчвам ви я горещо!

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Петък – ден на майстора. Най-добрият начин да мотивираш един програмист

Майк Рам — Fri, 05 Jun 2009 05:10:17 +0000

Всички знаем колко е трудно да накараш един програмист да свърши нещо, особено ако не му е приятно. Широко е разпространено вярването, че работата на програмиста е чисто изкуство, също като да пишеш поезия, а тази работа се върши само когато има вдъхновение.

Има, обаче, един начин да запалиш един програмист да работи, даже и когато е легнал тежко болен, даже и когато е изпаднал в кома! Стига да има една искрица живот в него, тя ще го събуди и ще го изстреля в офиса. Вижте как става това:

Запомнете тези магически думи и ги използвайте, когато видите някой програмист от вашия екип да се скатава. Те наистина вършат работа:

Един колега каза, че може да напише твоя код по-добре и той да заработи два пъти по-бързо!

Вижте тук цялата история. Благодарности на Jeff Atwood за линка.

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

Що за програмист сте?

Майк Рам — Wed, 03 Jun 2009 05:10:02 +0000

Някога, в зората на компютърната индустрия, се разпространяваха легенди за Истинския програмист, който пише само на FORTRAN, пие много бира и кафе и НИКОГА, ама НИКОГА не пише коментари. Днес нещата вече са влезли в някакви релси и програмирането отдавна не е онази тайнствена магия, пред която всички шефове благоговееха. Днес децата още преди да се научат да четат и пишат на родния си език, знаят поне един език за програмиране и умеят да тракат по клавишите на компютър още преди да са се научили да пишат ченгелчета в тетрадките си.

По същата логика и оценката на качествата на Истинския програмист днес вече е поставена на научна основа. Разработен е психологически тест, който определя какъв тип програмист сте. Авторите твърдят, че тестът е базиран на популярната психологическа класификация на Myers-Briggs и че е напълно сериозен, въпреки че някои от въпросите са много забавни.

Ето какво излезе за мен:

Your programmer personality type is: PHTB

You’re a Planner.
You may be slow, but you’ll usually find the best solution. If something’s worth doing, it’s worth doing right.

You like coding at a High level.
The world is made up of objects and components, you should create your programs in the same way.

You work best in a Team.
A good group is better than the sum of it’s parts. The only thing better than a genius programmer is a cohesive group of genius programmers.

You are a liBeral programmer.
Programming is a complex task and you should use white space and comments as freely as possible to help simplify the task. We’re not writing on paper anymore so we can take up as much room as we need.

Искате ли и вие да разберете дали сте Истински програмист или екипен играч като мен – тествайте се! Минава бързо и не боли.

Благодарности на Дончо за чудесния линк!

Гласувайте за тази статия в Svejo.net:

Вижте и тези публикации:

В търсене на теория за софтуерното производство

Майк Рам — Mon, 01 Jun 2009 05:10:12 +0000

Ivar Jacobson е забележителна личност в областта на софтуерното производство. Един от създателите на езика за моделиране на процеси и изисквания UML, на Rational Unified Process – една от класическите методологии за управление на софтуерни проекти, Ivar Jacobson не спира да търси най-добрия начин за правене на ефективен и полезен за потребителя софтуер. Той има и собствен блог (който аз наскоро открих благодарение на моя приятел Дани), в който споделя своите търсения и открития в областта на разработката на софтуерни продукти.

В една от последните си статии, г-н Jacobson се възмущава от твърде честото възникване на нови “революционни” подходи в разработката на софтуер и лекотата, с която някои мениджъри се хвърлят в тяхното внедряване като методология за управление на проекти, изхвърляйки и зарязвайки всичко, постигнато до момента в техните компании.

Ние в инженерната индустрия ли работим или в модната?

- възкликва той. И продължава:

Не ви ли се струва, че следването на последната мода в софтуерната индустрия е станало по-важно от производството на качествен софтуер?

В стремежа си да бъдат модерни, казва той, хората унищожават доброто заедно с лошото. Вместо да се поучат от собствения си опит и да градят на базата на своите успехи, те съвсем безотговорно зарязват всичко постигнато до момента и започват с нещо, което вярват, че е фундаментално ново. Сякаш нямат никакви солидни знания, върху които да се опрат. Затова и толкова лесно се люшкат към всяка нова тенденция без да могат да запазят онова, което са научили от опита си.

Подобно нещо се получава и с така наречените гъвкави (agile) методологии. Докато Agile manifesto представи набор от ценности, които бяха нещо здраво и устойчиво, способно да издържи на натиска на промените, то нароилите се в последствие “методологии” представят съществуващи и преди практики, които само са преименувани и са представени като нещо съвсем ново. Това, в крайна сметка само отвлича вниманието на програмистите и техните мениджъри от основната им задача – правенето на качествен софтуер.

Какво трябва да се направи?

Имаме нужда от теория на софтуерното производство. Но тя не трябва да е нещо сложно и неразбираемо, а нещо просто и конкретно, за да има практическа полза от нея.

Първо, теорията трябва да стъпи на някаква основа. Трябва да се изгради едно ядро, което е общо и разбираемо за всички. В крайна сметка, всички сегашни методологии признават, че има дейности, които винаги извършваме, когато разработваме софтуерни продукти. Например, винаги пишем код, винаги го тестваме (по един или друг начин), винаги мислим за изискванията (документирани или не), винаги имаме списък със задачи (backlog) – експлицитен или имплицитен – и винаги имаме план – независимо дали е записан на хартия или е само в главите ни.

След това трябва да разберем смисъла на методите и процесите и да ги обясним в термините на ядрото. Можем да съберем всички съществуващи практики, да ги изчистим от козметичните разлики и да получим един набор от основни и важни дейности, които да бъдат от реална полза за екипите, разработващи софтуер. Те трябва да залегнат и в учебните планове на университетите, така че от там да излизат хора, разбиращи процеса на софтуерното производство в неговата същност и да могат да фокусират своите усилия в производството на полезни и удобни за потребителя продукти.

По-нататък авторът описва в детайли ползата за бизнеса, за софтуерната индустрия като цяло, за програмистките екипи и са академичната общност от една такава теория, изцяло ориентирана към практиката. Съветвам ви да прочетете цялата статия, за да придобиете по-добри впечатления за идеята.

За да бъде цялото усилие от реална полза, е много важно участието на хората, занимаващи се със създаването на софтуерни продукти. Затова и авторът приканва всеки, който има идеи или желание да сподели опит, да му пише на оставения имейл, за да може онова, което се получи като краен продукт, да произлиза от действителността и да носи реална полза за всички. Всеки, който иска, би могъл да даде своите идеи и предложения на Ivar Jacobson и неговия екип, а аз ще очаквам да споделите вашите мисли и коментари тук.

Гласувайте за тази статия в Svejo.net: