Препоръчано четиво: Agile Software Development
Гъвкавите (agile) методологии са постоянно обект на спорове и дискусии - дали са методологии, дали са форма на мениджмънт или стил на програмиране, дали въобще са полезни и какъв е техния смисъл.
Това донякъде е оправдано, като се има предвид, че повечето методи възникват като алтернатива на класическите (или тежки) методологии, които и до ден днешен се използват в големи и скъпи проекти и за съжаление не винаги успяват да доведат проекта до успешен край.
Честно да си призная, не съм голям почитател на гъвкавите методи, може би защото са прекалено радикални и екстремни. И аз, както и Steve McConnell, смятам, че много от идеите, които те проповядват, са полезни и биха могли да се използват при традиционното управление на проекти, но не всичко от agile development е приложимо за всички проекти. Както казват американците, “one size doesn’t fit all“.
Категории: Връзки, Препоръчано четиво, Разработка на софтуер | 2 коментара
Двата типа програмисти
Jeff Atwood от Coding Horror публикува наскоро една статия, озаглавена Двата типа програмисти, която разпали страстите и събра огромно количество противоречиви и емоционални коментари. По-късно, усетил, че нещата залитнаха в неправилната посока, той написа още един пост, опитвайки се да потуши страстите и да донесе мир, но войната вече се беше разгоряла. Аз ги прочетох и двата, при това няколко пъти. Прочетох и всички коментари и все още не съм много сигурен какво точно искаше да каже Джеф и защо го каза по този начин. Тук ще се опитам да представя моето виждане за нещата..
Той казва, че съществуват два вида програмисти - тип 0 (20%) са хората, които програмират за удоволствие. Тези хора живеят и дишат програмиране. Те използват Linux и участват в Open Source проекти. Иначе казано, (макар и той да не го казва в прав текст), това са готините пичове, истинските програмисти, умните програмисти. Другата група са тип 1 (80%) - хората, които програмират, за да си вадят хляба. Такива хора бихме могли да наречем “професионалисти”, но той ги нарича по-скоро “чиновници”. Те работят от 9 до 5, използват само Microsoft технологии и не четат технически статии и новини по интернет. “Те не са глупави”, казва той, но аз мисля, че точно това иска да каже, защото финалният призив е към умните момчета да преглътнат гордостта си и да помогнат на глупавите си другарчета да поумнеят и те.
Целта е всъщност благородна. Ако пък случайно вие почувствате, че сте от онези 80% - глупавите програмисти - не се притеснявайте - една от най-важните характеристики на групата на 20-те процента е, че те четат блогове, особено неговия. Така че, вие просто трябва да прочетете поне една статия от неговия блог и автоматично ще се прехвърлите в елитната група.
Съжалявам, Джеф, но не мога да приема това!
Категории: Разработка на софтуер | 3 коментара
Банка ДСК - софтуерно решение за управление на опашка от клиенти
Днес в блога си The Man on the Silver Mountain публикувах една статия, озаглавена Банка ДСК - реален социализъм в действие. В тази история разказвам за два феномена, с които се сблъсках там. От една страна е нежеланието или неспособността на банката да се справи с огромните опашки от клиенти и превръщането им в нормално ежедневие, и от друга е софтуерното решение, с което банката иска да вкара опашката в някакъв ред, и което се оказва поредната софтуерна недомислица.
Трудно някой, който се е занимавал с разработка на софтуер, може да се сети за по-проста задача от това да раздаваш последователни номера, но явно екипът, разработил системата на Банка ДСК, е успял дори от тази проста задача да сътвори нещо, което не само не помага, но и още повече обърква и без това ошашавения клиент.
Тази история е поредния пример за софтуерно изпълнение, което напълно е игнорирало крайния потребител - нито е съобразено с неговите изисквания, нито пък с възможностите му и спецификата на неговото поведение. (Не бива да забравяме, че 90% от клиентите на банката са пенсионери, които не само нямат компютърна грамотност, но имат затруднения с четенето и придвижването.)
Прочетете статията. Сигурен съм, че ще ви накара да се замислите.
Категории: Класически грешки, Разработка на софтуер | Няма коментари
Класически грешки - 2008
Онзи ден получих писмо от Steve McConnell с линк към резултатите от изследването, което той проведе миналото лято върху Новите класически грешки на софтуерното производство. Аз участвах в това проучване и писах за него в Класическите грешки. Стив публикува своя списък от класически грешки в книгата си Rapid Development от 1996, но поради много динамичното развитие на софтуерния бизнес, той реши, че списъкът се нуждае от актуализация. В него бяха предложени няколко нови грешки, а всички останали бяха подложени на верификация.
Сега той е публикувал резултатите от това проучване в брошура от 39 страници заедно с презентация на PowerPoint. Проучването включваше много въпроси, целящи да се направи един по-задълбочен анализ на същността и причините за възникването на най-големите грешки, които правим в областта на софтуерното производство. Списъкът от 2008 година ги подрежда според честотата на тяхното срещане и според пораженията, които могат да нанесат на един проект. Събрани заедно, тези критерии ни дават списъка на най-разрушителните класически грешки в нашия бизнес. Няма да ви издам коя е най-фаталната грешка, която правим, за да не ви разваля удоволствието да си го прочетете сами - просто кликнете на този линк (може да ви поиска регистрация, която е безплатна) и ще го узнаете.
Моят професионален опит ми показва, че повечето софтуерни компании все още са много далече от стандартите, които Steve McConnell поставя за Rapid Development и първата и най-важна стъпка, която трябва да се направи, е да се научим да избягваме тези “класически грешки”. Допускането на подобни грешки е гаранция, че няма да можете да завършите своя проект навреме. Според мене, всеки добър проджект мениджър трябва да има този списък пред себе си, за да го следи периодично и да си задава въпросите: Продължаваме ли да допускаме класически грешки? и Как можем да ги избегнем?
Това, разбира се, никак не е лесно. Понякога се налага да правиш неща, които биха били класифицирани като класически грешки, принуден от обстоятелствата или от по-висшия мениджмънт. Но знаейки, че това, което правиш, може да ти донесе големи неприятности, ще те накара да внимаваш повече и да следиш по-внимателно за рисковете, които заплашват да провалят твоя проект.
Документът с новите класически грешки е безценен източник на информация. Прочетете го и се замислете дали не допускате класически грешки във вашите проекти.
Гласувайте за тази статия в Svejo.net:
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл
Категории: Класически грешки | 2 коментара
Новият дом на блога за управление на софтуерни проекти
Добре дошли на страниците на PM Stories - блогът за разработка на софтуер и управление на проекти!
Започнах да пиша по тази тема преди няколко месеца в моя първи блог Спри и помисли!, но реших, че темата за software engineering и project management си заслужава свое собствено място, където да се концентрира интереса на програмисткото братство, и където (надявам се) да се включат повече хора в дискусиите, а защо не и като автори?
Този блог има и версия на английски език, но не всички постове са еднакви. Постовете на английски език третират теми, които засягат професията на софтуерния разработчик и на проджект мениджъра в по-общ смисъл и биха били интересни за читатели от целия свят. Постовете на български език са свързани с теми от нашата действителност, които са по-важни за нас, отколкото за чужденците. Надявам се, че тези от вас, които могат да четат на английски, ще намерят интересни неща и в английската версия на блога.
Ще се радвам, ако сред вас има желаещи да станат автори в този блог. Вярвам, че по този начин ще успеем да направим този блог истински полезен източник на информация в областта на софтуерното производство и управлението на проекти.
Добре дошли в PM Stories!
Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин чрез RSS feed или по имейл
Категории: Лични, Разработка на софтуер, Управление на проекти | Няма коментари
Ролята на проджект мениджъра - притиснат като сандвич
Проджект мениджърът е връзката между две групи от хора: тези, които вършат работата (програмисткия екип) и тези, които искат работата да бъде свършена (спонсорите). Ролята на мениджъра е да осъществи връзката и взаимното разбиране между тези две страни.
Така започва Кришна Кумар своята статия The Sandwich Situation, в която разсъждава над ролята на проджект мениджъра, сравнявайки я със сандвич, в който плънката е притисната от двете страни. Понякога натискът е доста силен и сравненията, които идват наум са по-скоро с чук и наковалня, отколкото със сандвич.
Дали, обаче, концепцията за “междинното звено” е достатъчно ефективна? Това е въпросът, който Кришна задава и се опитва да му намери отговор. Няма ли да е по-просто и по-евтино, ако спонсорите сами си управляват работните екипи?
Продължи към пълния текст »
Категории: Професията на проджект мениджъра | Няма коментари
Как оценяте бюджета на един проект? Резултати от анкетата
Анкетата беше поставена преди доста време и я позадържах с надеждата, че повече хора ще се включат и ще получим малко по-представителна извадка, но забелязах, че напоследък няма нови гласуващи и затова реших да я прекратя и да разгледаме резултатите.
Въпросът беше: Как оценяте бюджета на един проект?
В анкетата гласуваха общо 65 човека. Ето и разпределението на гласовете:
Категории: Анкети, Курсове и семинари, Управление на проекти | 1 коментар
Project Scope vs. Product Scope
Това са често срещани в учебниците по project management термини, които доста хора все още не разбират добре и често бъркат. Gina Lijoi дава едно кратко, но пък достатъчно ясно обяснение на тези термини в нейния блог Interactive Project Management. Термините нарочно не ги превеждам, защото вече са придобили достатъчна популярност в нашата практика (както и много други), а на български така и няма достатъчно добри аналози.
Правилата на Неизвестния ПиЕм - Част 3
Списъкът с изстраданите мъдрости и шеги от света на project management-а продължава. Макар и малко цинични на моменти, те са истинско отражение на реалностите в една професия, която обичаме и мразим едновременно.
- Проектът е една малка крачка за проектния спонсор и голям скок за шефа на проекта.
- Добрият проджект мениджмънт не е толкова в това да знаеш какво да правиш и кога, колкото в това, да знаеш какви оправдания да дадеш и кога.
- Ако всичко върви точно по план, значи някъде нещо тотално се скапва.
- Всички търсят силни проджект мениджъри, а когато ги намерят - не ги искат.
- Overtime-а е плод на наивното мениджърско въображение.
- Количественият проджект мениджмънт е способността да предвидиш с колко ще надхвърлиш първоначално планираните срок и бюджет.
- Колкото по-рано започнеш писането на код, толкова по-късно ще свършиш.
- За проджект мениджъра, надхвърлянето на срока и бюджета са толкова сигурни, както смъртта и данъците.
- Някои проекти завършват навреме въпреки най-добрите практики на управлението на проекти.
Вижте също част 1 и част 2 на Правилата.
Задължителни въпроси при формулиране на изискванията към един софтуерен продукт
Един от ключовите проблеми при разработването на един софтуерен продукт са непълните или неясни изисквания, зададени от клиента. Софтуерните разработчици са хора с много силно развито аналитично и детайлно мислене и имат нужда от точно и ясно обяснение какво трябва да се направи при всяка една възможна ситуация. Или, казано на програмистки език - какво трябва да се случи при всяко едно разклонение на if оператора.
Клиентите пък, са хора, които в общия случай не притежават това мислене и често пропускат да опишат ситуации и варианти, които за разработчиците са важни, а за тях са нещо тривиално и подразбиращо се. Добро решение в този случай е намесата на бизнес анализатора, който умее да говори и двата езика и знае как да зададе на клиента онези въпроси, които вълнуват програмистите, но на неговия език.
Така във функционалната спецификация влизат не само нещата, които клиентът изрично е поискал и обяснил, но и нещата, които са важни за разработчиците от техническа гледна точка, и без които продуктът не може да работи нормално.
-
RSS абонамент
Препоръчвам ви
Връзки
Авторски права
-
Admin
