PM Stories » Гъвкави методологии

Spooning – една пародия на Pair Programming

Майк Рам — Wed, 04 Apr 2012 16:48:39 +0000

Тези от вас, които се интересуват от Agile методи за разработка на софтуер и управление на проекти, сигурно са чували за Pair Programming или работа по двойки – една от най-спорните практики на Extreme Programming. В това видео, на което попаднах от сайта Obama Pacman, си правят голям майтап с нея, но шегата е добродушна.

Ако искате да научите повече за Agile методологиите и за това доколко са успешни различните техники в практиката на софтуерното производство, заповядайте на семинара “Методологии за управление на проекти“, в който разглеждаме различните подходи и правим анализ на това кой е най-подходящия в различните проекти, с които се ангажираме.

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

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

Среща на Agile и Lean общостта – 18.04.2011

Майк Рам — Mon, 11 Apr 2011 11:43:52 +0000

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

Здравейте, приятели!

Наскоро да имаше семинар на тема “Методологии за управление на проекти”, където стана дума за Lean & Agile. Затова няма да изпадам в подробности – ще отбележа само, че Lean & Agile са философии/принципи/методи/практики, които през последните години набират широка популярност по света (до някаква степен и в България) и които имат сериозно отражение върху начина на управление на проекти (софтуерни и не само).

Конкретният повод да пиша тук е една инициатива, подета от Jurgen Appelo, целяща подобряване на комуникацията и сътрудничеството между хората в Европа, интересуващи се от Agile и Lean. Подробности за инициативата има тук: http://www.noop.nl/2011/02/agile-lean-europe-energize-the-network.html

На конференцията XP 2011 в Мадрид през месец май 2011 ще се дискутират идеи и планове за Agile Lean Europe (ALE) общността (http://www.noop.nl/2011/03/ale-gathering-at-xp2011.html). Идеята е всяка страна да представи своите идеи пред останалите.

Във връзка с това Scrum Bulgaria групата организира среща на 18 Април 2011, понеделник от 19:00 часа. Сборен пункт – фоайето на Факултета по Математика и Информатика (ул. Джеймс Баучър 5; град София). Основна тема за обсъждане: визия и идеи за Agile Lean Europe (ALE) общността:

Какво е важно за нас от България по отношение на цялата ALE общност (Европа). В частност отговор на тези въпроси.
Как ще представим нашите идеи пред останалите? (В най-добрия случай се търси някой да се появи на XP2011 в Мадрид през май 2011).

Междувременно темата се дискутира тук: http://bit.ly/ale-xp2011-bulgaria-sb
Подробности за събитието – на сайта на scrumbulgaria групата.

Срещата е отворена за всички желаещи! Заповядайте!

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

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

10 проблема при преговорите с клиенти. Част 1 – избор на методология и избор на клиент

Майк Рам — Thu, 26 Aug 2010 05:43:33 +0000

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

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

Как договаряте условията – гъвкави (agile) методологии или дълги спецификации?
Колко време отнема контактът с клиента: срещи, телефонни разговори, мейли?
По какъв начин договаряте дизайна, за да избегнете постоянните промени в процеса на работа?
Как разпределяте минорните (незначителни и кратки) корекции от съществените (тези, които отнемат време и водят до закъснения и загуби)?
По какъв начин договаряте плащанията (авансови, на фази, на срокове)?
Работите ли извън стандартното време (вечер, уикендите)?
Как реагирате при закъснения на клиент (забавяне на материали, закъснение при отговор и на плащане)?
Кои са задължителните въпроси и уточнения, които задавате и разяснявате на клиента в началото?
Колко от проектите ви са на загуба или със закъснение?
Кои са признаците на потенциалния проблемен клиент?

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

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

Първата работа е да си изясним проблемите.

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

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

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

Разбира се, не винаги е лесно да убедиш един клиент в правилността на избора си и в ефективността на управленския подход, който си избрал. Точно тук – при първоначалните разговори – си проличава и отговорът на въпрос номер 10 – дали клиентът няма да ни създава проблеми и струва ли си въобще да се захващаме с него. Ето няколко примера, които могат да ми подскажат, че клиентът ще ни създаде проблеми:

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

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

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

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

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

The Agile Manifesto – превод на български

Майк Рам — Thu, 06 May 2010 06:21:43 +0000

Когато още през 2001 г. беше публикуван Agile Manifesto, бях привлечен от принципите и ценностите, които неговите автори издигнаха като основополагащи в едни нови отношения между софтуерните разработчици и потребителите. Признавам, че някои от практиките все още са трудно приложими в днешния меркантилен свят, но ето че близо 10 години тези принципи и ценности доказаха своята стойност и все повече хора в софтуерния бизнес се обръщат към тях.

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

На български език има относително малко информация за Agile програмирането въобще и за Манифеста. Ето няколко линка за тези, които искат да научат нещо повече:

Единственият опит за превод, който открих, дело на Георги Стойчев. Доста свободна и на моменти неточна интерпретация, но заслужава адмирации за това, че е първи.
Майсторството да правиш софтуер – една добра презентация, вдъхновена от принципите и ценностите на Agile програмирането.
И, разбира се, на курсовете по управление на проекти, които водя, се говори доста по темата за Agile методологиите и техните основни практики.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Гледайте я!

Гласувайте за тази статия в 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:

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

Open Agile Румъния

Майк Рам — Tue, 19 May 2009 07:58:46 +0000

Open Agile е първото голямо събитие в Румъния, посветено на управлението на софтуерното производство с гъвкави (Agile) методи. То ще се проведе на 22 и 23 май 2009 г. в University Politehnica в Букурещ.

Конференцията обещава да бъде интересна, като се има предвид, че сред лекторите са Ken Schwaber (на снимката) – един от създателите на най-успешния и най-популярен Agile метод – Scrum и Jurgen Appelo – един от най-популярните блогъри в света в областта на управлението на софтуерни проекти.

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

У нас активността е насочена предимно в технически конференции, фокусирани върху новости в програмирането. Събития като Microsoft Days и DevReach вече са се превърнали в успешна традиция. Но разработването на софтуерни продукти отдавна не е само програмиране, а една цяла индустрия, която има всички характеристики на всеки друг бизнес. За съжаление, у нас все още мисленето на хората, работещи в тази индустрия, е насочено предимно в производството, т. е. в програмирането, а области като управлението и маркетинга на софтуерни продукти все още остават на заден план.

Конференцията Open Agile Romania обещава да бъде интересна и полезна. Не е много далеч, а и участието не е много скъпо. За съжаление, аз няма да мога да присъствам, но ще се радвам онези, които успеят да отидат, да споделят своите впечатления на страниците на PM Stories.

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

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

The Zen Of Scrum

Майк Рам — Mon, 23 Feb 2009 08:40:17 +0000

Scrum е най-бързо развиващата се “гъвкава” методология за разработка на софтуер. Не толкова сурова и крайна в изискванията си както Extreme programming (XP) и в същото време разбираема и лесно приложима в редица проекти.

Въпреки, че идеята на гъвкавите методологии е да се прилагат в малки екипи, те намират все по-широка употреба и в големи корпорации, както и в държавни организации на запад. Аз самият я намирам за доста прагматична и успешно приложима в множество проекти, въпреки че има особености, които, ако бъдат пренебрегнати, могат да доведат до неуспех. В курса “Основи на управлението на софтуерни проекти“, който водя във фирма RammSoft, има една голяма лекция, посветена на гъвкавите методологии и по-специално на Scrum.

Наскоро попаднах на една чудесна презентация, изготвена от Jurgen Appelo, озаглавена The Zen of Scrum. В нея Юрген представя най-важните аспекти на Scrum по един елегантен и разбираем начин. Самата презентация е изработена в стила на гуруто на съвременното разбиране за презентиране – Garr Reynolds, автор на блога Presentation Zen – и в негова чест е избрано и това заглавие.

В желанието си да популяризира разбирането и практикуването на Scrum, Юрген е публикувал своята презентация напълно свободно и всеки може да я копира, препубликува или дори да я обяснява и преподава на други. Разгледайте я – тя е стойностна не само заради това, че обяснява методологията на Scrum ясно и в детайли, но и заради това, че не изпада в религиозен фанатизъм, както често се случва с проповедниците на гъвкавите подходи, а съвсем честно и открито показва недостатъците на системата и подводните камъни, на които можете да се натъкнете при нейното внедряване.

Едно наистина полезно четиво.

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

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

Управление на сложни изисквания в един “agile” проект

Майк Рам — Wed, 10 Dec 2008 05:10:29 +0000

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

Това казва Scott W. Ambler в статия, публикувана в Dr. Dobb’s Portal. И още:

“Гъвкавите” методологии като Scrum и Extreme Programming (XP) ни показаха как можем значително да подобрим работата си, но много хора изпаднаха в другата крайност и изхвърлиха бебето на управлението на изискванията заедно с мръсната вода на бюрокрацията, вярвайки, че всичко може да се реши с прости методи. За щастие, има решение, което се справя с проблемите на сложните системи и то може да бъде реализирано напълно в стила на “Agile” методологиите, без да се налага връщане към традиционните тежки практики на писане на тонове (ненужна) документация.

Методът Scrum популяризира идеята да се управляват изискванията като списък от малки функционални единици, описани в приоритизиран стек, наречен “product backlog”. Идеята е, че в началото на всяка итерация (спринт) се изваждат онези изисквания, които трябва и могат да се имплементират в рамките на тази итерация. И всичко щеше да е прекрасно, ако в действителност беше толкова лесно.

Софтуерните екипи, включително и гъвкавите, имплементират не само нови функционални изисквания по време на една итерация, но също така поправят дефекти или изпълняват други, нефункционални задачи. Затова се налага едно допълнение към стратегията на Scrum за “product backlog”. Той се превръща в стек от работни задачи, които могат да бъдат: функционално изискване, бъг или друга работа, като ревю на работата на колега, обучение или инсталация на оборудване.

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

Прочетете я!

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