Как да изпратим софтуерен проект

Снимка на Али Яхя в Unsplash

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

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

1. Изберете дата на кораба, но не се привързвайте към нея

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

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

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

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

Илюстрация от Хенрик Крисп

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

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

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

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

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

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

4. Преценете колко време ще ви отнеме, за да задоволите зависимостите си - след това умножете

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

Това е животът в софтуерния бизнес.

Докато създавате опис на вашите зависимости и времето, което преценявате, че ще трябва да готвят, умножете по 2,5.

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

Или не Това е твоят кораб. Тук можете да използвате каквото и да е многократно. Дългогодишният опит ми подсказва, че за моите оценки все пак обикновено искам 2,5 пъти.

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

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

5. Добавете прогнозите си за времето и сравнете графиката с датата на вашия кораб

Ако имате голям късмет, прогнозите ви за времето и мрежата на вашия кораб перфектно.

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

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

В този процес са изброени всички неща, които разгледахме от най-реалните до най-малко реалните:

  1. Зависимостите за нашите желани характеристики
  2. Минимално жизнеспособен набор от функции
  3. Прогнозите за времето
  4. Датата на кораба

Датата на кораба е най-малкото истинско нещо, с което имаме работа! Не го оставяйте да кара.

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

6. Правете труден избор: отрежете обхвата или преместете датата на кораба

Знам. Искаш пони.

🗓

Но сега знаете какво струва понито.

Ще изпратите понито 18 месеца по-късно, отколкото бихте искали. Ще имате ли достатъчно пари, за да оцелеете за тези допълнителни 18 месеца? Ще се откажете от важно конкурентно предимство, като вземете тези допълнителни 18 месеца? Добре ли сте да чакате 18 допълнителни месеца, преди да получите отзиви от клиентите за това дали дори сте на правилния път?

Може би сте добре да преместите датата на кораба. Понякога това е правилното обаждане.

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

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

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

Но, Данило, това не е пъргавия / scrum / [методологията на култовия култ]!

Каквото и да е, човече. Сигурен съм, че не е така. Това е начинът, по който знам да изкарам проект на вратата на дата, договорена от всички страни, с обхват, документиран за всички страни, с компромиси, разбрани от всички страни.

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

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

Допълнителна информация:

1.0 от Rands: „Доставка на 1.0 продукт няма да ви убие, но ще се опита.“