За пореден път се поставя въпросът за точността на прогнозите за времето, необходими за развитието. За пореден път се опитах да формулира отговор за себе си.
На първо място, "точен" оценка не съществува по принцип. Разходите за труд - това винаги е случайна променлива подлежи на определено разпределение на вероятностите. Външно, тя изглежда така.
В този пример, вероятността за завършване задача за 4 дни е 0.5, шест дни - 0.75, 8 дни - 0.9.
Аз, като истински зъл и глупав строг клиент тук обърква труд и време за изпълнение на задачата, но тя е в този случай не е от значение. За простота, ние ще приемем, че задача се изпълнява от един човек, и той я дава през цялото време, докато задачата е завършена. (Знаеш ли, че тези оценки "за простота" в никакъв случай не могат да се споразумеят с действителния планирането на проекти, нали?)
Когато се изисква да се изчисли разходите за труд, ние обикновено си поставили някаква приблизителна праг на вероятност. Например, ако ние се определя праг от 0,9, нашата оценка ще се извършва със средно девет от десет пъти.
Това е само приблизителна форма на кривата. Малко вероятно е, че някой ще бъде в състояние да формулира точно разпределението на параметрите за оценка на следващата задача. Можете, разбира се, се опитват да го изгради въз основа на събраните статистически данни за вече завършени задачи. Но статистиката е вероятно да са лъжа, защото всичко е постоянно променящите се условия, които влияят върху параметрите на дистрибуция.
И тук ние бавно се приближава към първото издание на точността на прогнозите. Една от любимите въпроси на клиенти (и действа в ролята им началници): "Защо е вашата оценка винаги погрешно, ако решите да имате толкова много години същия проблем?"
И, характерно, често сме съгласни с него, и да напускат офиса след порицание, измъчван себе си ", и истината, и когато спре засилване на една и съща рейк?" Това се потвърждава и от големия брой на "научни", псевдо-научни и ненаучни начини за оценка, че Той изобретил индустрия разработка на софтуер през годините на неговото съществуване. Ние се опитваме да се оцени размера на код, броят на yuzkeysov, функционални единици или папагали. Умножаваме оценките за броя на "пи" или «д». Но това не поставя под съмнение важното: точната прогноза може да се "изчислява", ако установим магическата формула.
Но нека да мисля: дали наистина реши същия проблем?
Само си представете. Нашата задача програмист - например, да се напише функция за изчисляване на корен квадратен. Програмист прекарано на нея, например, три дни, друг ден е отишло за тестване и коригиране на грешки.
Следващият понеделник, ние поставяме на програмиста на нова задача: да се напише функция за изчисляване на корен квадратен. И му даде четири дни. Въз основа на опита, придобит. Gain опит програмист завършва работата за два дни, без никакви грешки.
Ние го хвалят и му даде една трета задача: напишете функция на извличането на корен квадратен.
След няколко месеца на производителност програмист се стабилизира, и той ще бъде в състояние да дават три функции изчисли квадратен корен на ден. Въз основа на това изпълнение, ние ще бъдем в състояние да даде много точна оценка усилие ... оценка да напише функция за изчисляване на корен квадратен.
Абсурдът е очевиден пример, но той илюстрира основния проблем, присъща на повечето оценка начини усилия. Програмистите никога не решават същия проблем. Всички задачи са уникални.
Разбира се, много често в програмирането общ подход за решаване на конкретни проблеми - всички видове модели и рамки. В различни райони на планиране може да включва повече или по-малко рутинни задачи. Но истината е, че рутината обикновено автоматизирано (или даден неопитен млади животни, което допринася своя дял на непредсказуемост), докато по-голямата част на несигурност се крие именно в тази част на проблема, което го прави уникален.
Изкривяването на клиента в цялата искреност: от негова гледна точка, ние наистина се реши един и същи бизнес проблеми. Работил съм в много тясна област в продължение на почти десет години - разработването на приложения за терминалите, които приемат банкови карти. И от гледна точка на бизнес клиентите на. всички тези десет години съм решен безброй пъти абсолютно същата задача: да се "научи" на терминала за извършване на продажбата на картата на клиента. От техническа гледна точка, нито един от тези проблеми не е като другата. Броят на параметрите, на които те се различават е огромен: различен хардуер, различни езици, различни компилатори, различни протоколи, различни потребителски интерфейси за бизнес ... Но всичко това е без значение - терминал или изпълнява сделката или не.
Възможно ли е с това нещо да се направи? Как да се вземат предвид несигурността в планирането на проекта?
Най-често срещаният метод: да лежи в планирането, колкото е възможно и да се даде оценка на рисковете, които могат да се срещнат възможно най-високата вероятност. Тази "максимална възможност" се определя, на първо място. степен на арогантност мениджър и желанието му да се пазарят с клиента, и второ - степента на пренебрегване на своята параноя, която се проявява, като се вземат предвид рисковете.
Но дори и ако можем да направим сделка за оценка с вероятност от 0,9, то няма да се намали напрежението в проекта. На първо място. всеки десети мандат ще продължи да бъде осуетено (и това със сигурност ще бъде най-важната и трудна задача). На второ място. В четири от случаите от десет бихте оценили надценени поне два пъти (веднъж погледнете графиката: оценка с вероятност от 0.9 е два пъти оценката на вероятността 0.5). И тогава вие ще падне в презастрахователни такси и вашия екип - в преди уволнението от работа.
Много по-добър начин да се справят с несигурността на собственото си оръжие - теорията на вероятностите. Има много методи за оценка вероятностни, от които най-добре познат (броят на препратки в учебниците) е метод PERT. и най-надеждни (в моя личен опит) - Практика планиране Poker. Въпреки, че Agile последователи, най-вероятно, не мисля за вероятностни механизми, присъщи на този метод, а просто да и правя.
Планиране Poker дава точни прогнози за изненада. В действителност, с негова помощ, ние считаме, в следващата оценка на колективен опит за решаване на всички предишни проблеми и големи рискове. Но това може да се използва успешно само добре организиран екип от опитни програмисти (да се чете: Agile-екип).
А радикален начин за решаване на проблема предлага теория на ограничения. метод критична верига включва пълно отхвърляне на оценките с висока степен на вероятност. Вместо това се предлага да се направи оценка на индивидуални задачи с вероятност от около 0.5, поставяйки общо поплавък за целия проект.
Но този начин на наистина радикално. За да го заредите, който искате да промените цялостната култура на дизайна на организация.
Пауза. Прочетете отново, бавно, размишлявайки смисъла: той е необходим за промяна на цялостната култура на дизайна на организация.
Опитайте се да се прецени колко много хора в компанията изгради своята работа около "оценки" на модела. QA тества планове, въз основа на очаквания срок за приключване на повторения за развитие. отдел продажби включва тези оценки със съгласието на клиента, но договорът вече не се нарича "оценки" и "срок на доставка". Маркетингов отдел обявява дата на излизане за следващата версия на "убийци на конкуренцията" в своето съобщение за пресата. И под него всичко е подписано от шефа си.
Сега си представете, че вие разговаряте с всички тези хора, "От утре, ние ще се даде на всички прогнози с вероятност от 0,5."
Не, защото те не разбират. Ти казваш това: "От утре, ние ще изпълнява само половината от обещанията си по отношение на времето."
Какво ще чуете в отговор, и е квинтесенцията на дизайн културата на вашата организация.