Арт estimatsii, по-интелигентни уеб

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

За да направите резервация - ситуацията е спешна, независимо от изповядван клиент или модел оценка на работата на изпълнителя, независимо дали е с фиксирана цена. фиксиран всички. timematerial или специален екип.

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

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

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

Какво е estimatsiya? От тогава, аз ще използвам този термин, заедно с "прогноза", а след това нека да го определи. Така че, в рамките на estimatsiey в областта на уеб програмиране обикновено се разбира математически изчислени оценката на приблизителна цена за проекта, в който входната информация за бъдещето на проекта може да бъде непълна или неточна.

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

Да започнем с това, че е необходимо напълно да забрави за съществуването на калкулатор. Рано estimatsiya не е нещо, където можете да намерите всичко. Но ако не можете да намерите, тогава какъв е смисълът, ще попитате вие? Чувството и за разлика от началото на estimatsii от финала (или проект, наречете го както искате), както следва:

• Даваш функционалност оценка (функции), вместо истории от потребителите (истории от потребителите);
• Вашата цел - да се помогне на клиента да идентифицира проблемите си, а не да планират своите финансови разходи;
• оценка Точност - средно и ниско, но не е много висок;
• Рано estimatsiya трябва да се направи от един експерт, а не развитие на екипа.

Освен това, да направят правилния първоначална estimatsiyu, получавате почти завършен проектът окончателна оценка, с която можете спокойно да отидете на клиента.

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

И сега към веселбата.

Какво е необходимо за ранно estimatsii

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

На второ място. имате нужда от маса. Да започнем с това, той може да бъде много прост.

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

Какво да се прави

Изчислете момента, в който вие ще похарчите за оценката. В действителност, тя estimatsiya estimatsii. От това ще зависи от детайлите на получените документи.

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

За да се даде първо приближение на час груби функционален. Това означава, че ако е писано "прави директория връзки" и вътре усещате, че същото си направил преди шест месеца и отне 50 часа, пиша този номер. Отново - тези цифри са само за вътрешно ползване, като основа за по-нататъшни изчисления, и да се съхраняват в съзнанието или записани "в областта". На този етап е по-добре да се направи оценка на функционалността на концепциите за "лесно", "трудно", "горе-долу" и така нататък. Г.

Функциите се извличат от който и да е достъпна за нас информация, получена от клиента.

Така че, това, което сме направили? Ние добавяме колона с уникалния номер на проблема, на която тя е винаги на разположение в нашите вътрешни комуникации (или да работят на изоставането в Scrum), плюс имаме колона с броя на часовете, за да изпълни задачата, и нивото на колона ekspiriensa (опит) за разработчици върху задачата в ръка.

Това трябва да присъстват във вашата estimeytah? Време пряко за развитието, миграция на данни, писане автоматизирани тестове (ако има такива), функционалната конфигуриране, тестване функционалност, поправки, и разбира се - пускане в действие на проекта върху активен сървър - deploymenta.

Как да се направи оценка на часовника

Най-добрите и най-доказан начин да се оцени часовника на развитие е използването на скалата. Scale - определен набор от номера, от които можете да изберете часовника. Най-популярната Скалата е 1, 2, 4, 8, 16. Това означава, че в определена задача, можем да пишем на броя на часовете, съответстващи на един от номерата. Можете също да комбинирате часовника и да използва част от време, като например развитие модул може да отнеме 16 + 16 часа и включването на някоя вградена - 0,2 часа. Най-важното нещо, което мисля, че в рамките на определен фиксиран набор от числа, тя позволява на мозъка да не се опитват да вземат случайно число от тавана и някак храносмилане задача, преди да го оцени. Когато това разделяне не е подходящ за мащабни фигури в отсъствието на адекватен опит.

Но това не означава, че не можете да използвате 1, 2, 5, или всеки друг мащаб, който ви подхожда лично. Изберете една, в която се чувствате най-комфортно.

Ако задачата отнема повече от 50 часа - Почивка в по-малките.

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

Ние управляваме риска и несигурността

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

Много много нивото на несигурност в ранните етапи на оценката може да намали vayrfreymy (Wireframes) - информация за тяхното използване и създаване на по-добро себе си изглежда.

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

Основните фактори, които влияят на риска са:

• Ниско ниво на екипа
• Неразбрани изискванията на проекта или недостатъчно внимание към него
• Пълното отсъствие или дефект на стандартите и практиките за съвместното развитие
• Грешки при планирането
• Липса VCS (Git, SVN, Mercurial, базар и т. Г.)

Необходимо е да се вземе предвид така наречените "управлението на очакванията" - също е важна част от проекта, който обикновено е забравено в стъпка estimatsii и планиране. Така например, в никакъв случай не може да забрави за:

• Изпълнение (сайт трябва да работи бързо)
• Стабилност (тя не трябва да е)
• Безопасност (тя трябва да бъде трудно да се справи)
• Подходяща за използване (тя трябва да бъде лесен за използване за всички потребителски групи)

Комуникация с клиенти

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

Клиентът ще ви благодаря.

Избягвайте решения, които не вярват,

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

Ние оценяваме рисковете правилно

Най-простият и най-лесният начин да се направи оценка на рисковете в estimeytah, така че - настроите часовника правилно, е да попълните в колона "Experience" на етикета. Ако вече сте взели решение и да знаете точно колко време ще отида, сложи пет. Ако prinitsipe знам как да го направя, но те никога не са опитвали, а след това тройката е подходящ. Ако не знаете как да се направи едно цяло. Колкото по-ниска е числото, толкова по-висок е рискът, и колкото повече време е необходимо да се положи върху тях, защото ще се прекарва време в Google, Wikipedia, специализирани сайтове и форуми, общуването на IRC.

И тук е мястото, където започва магията!

Ние се въведе понятието "рисков фактор". В действителност, това е просто един множител, който се прилага към estimirovannym часа по-рано. Обикновено, този коефициент се изчислява по следния начин. Броят преди дебелото черво (от 1 до 5) е нивото на ekspiriensa проблем. След дебелото черво - минималната и максималната стойност множител за дадено ниво ekspiriensa.

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

Минималният брой на часовник часа предварително = * минимален риск.

Макс = часа преди часа * съотношение максимален риск.

Например, ние първоначално помислих, че се направи форума ще отнеме 10 часа, а на нивото на нашите ekspiriensa е пет. Следователно минималното оценка за дадена задача (10 * 0.8) = 8 часа и максималната оценка (10 * 1,25) = 12.5 часа. Каквато и да е стойност на (8 + 12,5) / 2 = 10,2. Като правило, идеала или на средната стойност трябва да съответства на предварителната оценка.

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

Окончателната версия на маса оценка. Всички числа са "научно", изчислени.

Плюс това, не забравяйте да сложите в estimeyty такива неща като:

• Разходи за управление на проекта (дори и ако имате на заинтересованите страни, за да сме в крак с): x 1,25
• Тестване: 1.15x

И аз имам един въпрос!

И след това, което най-очевидните въпроси.

Какво трябва да знаете, за да правилно estimirovat гледате?

Всичко, което трябва да направите е да се съберат колкото се може повече задачи трупи, които вече са направени. Съберете ги сами със себе си, с колегите си, приятелите си - навсякъде, стига името на видовете проблеми, които имате предвид, няма да скочи на броя на часовете. И разбира се - трябва да сте запознати със системата, с която работите, за предпочитане колкото е възможно повече от неговите аспекти. Използване на системата за управление на времето, в полза на техните резултати. Аз използвам Toggl. например.

Може рисков фактор да доведе до намаляване estimeyta?

Може би сте забелязали, че рисковият фактор може да бъде по-малко от една, което означава, че ако предварително zaestimirovali 5:00 на дадена задача, получили най-малко 2,5 часа след прилагане на коефициента, и 10:00 часа, като максимум. По този начин, на риска от въздействие върху намаляването на броя на час. Все още няма грешки - всъщност говори за "риск", имаме предвид, че има някои неочаквани фактори, които могат да повлияят на брутните фигури, и те могат да работят не само в посока на увеличаване. Най-простият пример - след началото на проекта беше установено, че един от разработчиците, участващи проект Potikha "дом", в който той се прилага решение, което ние първоначално счита за много рисковано. Ние говорихме за това и не би могъл да знае на етапа на estimatsii и следователно изразходва за решаването на минималното време.

След това всичко зависи от вашите нужди. Умножете часовника на залог, например $ 2 на час, и да получите стойност на проекта. Премахване на допълнителни колони, които не показват на клиента по-добре и да се натисне своя подробен документ. Ако времето позволява, да се обсъждат документа с отбора. Ако работиш в момента модерни технологии - имаме готов изоставането!

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

За тези, които искат да се бръкнат по-дълбоко, отколкото просто етикети с формулите, обърнете се към:

• Голямата книга Agile оценка и проектиране от Майк Cohn
• Всичко е възможно представяне на drupalkonah на събитието и технически по този въпрос, като един подход не съществува тук, и не може, по принцип,

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

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

Най-тежката критика е добре дошъл.