Изграждане на модел на веригата за доставки на софтуер

Стандартното изображение на поток от стойности на софтуерна разработка започва с кодиране и завършва с код в производство. Често виждате диаграми на devops, които започват с „бизнес“ и завършват с „клиент“. Това изображение обаче не отразява точно сложността на доставката на софтуер в корпоративен мащаб.

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

Моделът, използван в други продуктови индустрии, е моделът на веригата за доставки и чрез прилагането на този модел към доставката на софтуер можете да разширите разбирането си за „системата“ за доставка на софтуер отвъд devops, давайки ви нова представа за това как да го оптимизирате.

Каква е веригата на доставки?

Веригата на доставки започва с идеята, че можете да координирате всички производствени и непроизводствени дейности като единна система. Управлението на веригата на доставки често се разбира погрешно като просто „управление на доставчици“, когато всъщност това е само един аспект от управлението на веригата на доставки (макар и критичен).

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

Следните дейности са само някои от важните аспекти на всички вериги за доставки, но за софтуера те се изпълняват уникално:

Планиране

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

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

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

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

Източник

В традиционната верига на доставки компонентите за снабдяване включват управление на взаимоотношенията с доставчиците и разработване на стратегии за обществени поръчки за части и материали. Софтуерът също така разчита основно на компоненти с източник - според скорошно проучване на Sonatype, отвореният код сега формира по-голямата част от софтуерните продукти: до 80 до 90 процента от кода в съвременните приложения е от компоненти с отворен код. И тези компоненти създават уникални управленски предизвикателства.

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

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

Разпределение

Получаването на софтуер в ръцете на клиентите може да включва сложна мрежа от партньори от всякакъв вид: внедряване, разпространение, интеграция, дистрибутор; споразумения от всякакъв вид: OEM, лицензи, NDA, RFP; срещи от всякакъв вид: демонстрации, PoC, презентации; и много повече.

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

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

Газопроводът devops трябва да бъде тясно свързан с партньорствата, споразуменията и целите, за които се извършва работата. Кодът може да бъде проследим и свързан от историята с изискването до записа на клиента във вашия CRM, и всичко това чрез третиране на доставката на вашия софтуер като верига за доставки и следване със стратегия за интеграция.

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

Инструменти

Докато вашето класическо производствено оборудване може да се състои от машини за рязане и фурни за термообработка, веригата за доставки на софтуер включва клас инструменти (наречени по различен начин ALM инструменти, инструменти за жизнен цикъл или devops инструменти), които се използват за управление на различните етапи на доставка на софтуер .

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

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

Заключение

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

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

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