Спрытны менталітэт супраць спрытных механізмаў

https://flic.kr/p/bkcj5q

Я неаднаразова выяўляю, што каманды праграмнага забеспячэння занадта засяроджаныя на механізмах і губляюць з выгляду асноўны прынцып. Асабліва гэта тычыцца методык Agile. Такіх метадаў, як Scrum, ёсць так шмат механізмаў, што новыя, спрытныя, цалкам губляюцца. Першапачаткова я напісаў гэта ў электроннай пошце сваёй камандзе, каб патлумачыць, які мой погляд на Agile, але я адправіў яго столькім людзям, што, прымаючы парады Скота Хензельмана, я ператвараю яго ў запіс у блогу.

Я лічу сябе некалькі кваліфікаваным, каб даць гэта разуменне. Я спрытны практык з тых часоў, калі распрацоўка Agile ўдзельнічала з дапамогай адвёрткі - для дэмантажу ўласных кабін і стварэння адкрытага плана для сядзення!

У пачатку сваёй кар'еры я працаваў у кампаніі па медыцынскім праграмным забеспячэнні. Мы стварылі праграмнае забеспячэнне для прагляду настольных ПК для агляду выяваў, якое было ўстаноўлена на працоўным стале ўрача ў бальніцах. Працэс разгортвання прадугледжваў падарожжа з кампакт-дыскамі ў іншы горад і ўстаноўку працоўнага стала і сервераў малюнкаў. Мы падлягалі ўзгадненню FDA, таму нам давялося ствараць спецыфікацыі, якія праходзілі праз зацвярджэнне FDA. Гэта стварыла ідэальную сераду для метадалогіі вадаспаду зверху ўніз. Усе тэхнічныя характарыстыкі былі запісаны, зацверджаны, падпісаны, і мы пабудавалі толькі гэтыя параметры і тыя параметры. Калі каманда распрацоўшчыкаў пачала падарожнічаць з інсталяцыйнай групай і, назіраючы за тым, як лекары выкарыстоўваюць наша праграмнае забеспячэнне, мы зразумелі, што зрабіць гэта нашмат лепш, толькі калі зможам пагаварыць з кліентам раней у гэтым цыкле. Мы закадзіравалі дакладныя характарыстыкі і ўсё ж даставілі тое, што было не так карысна, як магло б быць. Гэты графік паказвае частку майго досведу.

Як распрацоўка праграмнага забеспячэння можа схавацца з https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

Прыблізна ў гэты час мая каманда чула пра тое, што называецца Agile Manifesto, і практыку пад назвай Extreme Programming. Улічваючы, што яго падпісалі ветэраны галіны, чые кнігі мы актыўна чыталі, такія людзі, як Марцін Фаўлер і Кент Бек, надалі практыцы шмат легітымнасці. Мая каманда з пяці разабрала кабіны, уцягнула ў сябе прэм'ер-міністра (проксі для нашага кліента), каб прысесці побач з намі, устанавіла дошку з індэксамі і пайшла на працу, складаючы XP, калі мы ішлі разам. У нас быў штотыднёвы цыкл планавання і дэманстрацый, шмат спарвання і абмеркавання. Я працаваў у розных ітэрацыях і варыяцыях гэтага ў розных кампаніях каля 15 гадоў. Здавалася, адна каманда не прытрымлівалася ніякай методыкі, але гэта адбылося таму, што ўсе члены каманды былі з глыбокага спрытнага фону, ітэрацыя і супрацоўніцтва - гэта стан іх працы па змаўчанні, і ім не спатрэбіўся навязаны працэс.

Так Agile пра планы адкрытых паверхаў ці шмат размаўляе? Калі ў вас ёсць рэцэпты і рэтрас, ці можаце вы прэтэндаваць на спрытнасць? Дзе Scrum ці TDD ўпісваюцца? Часта людзі занадта захапляюцца спецыфікай працэсу - Scrum ці Kanban? Два тыдні ці адзін тыдзень спрынту? Калі вы не маеце адставання ў сыходзе, вы сапраўды Agile? Пасталеўшы займацца актыўным развіццём метадаў Agile, іншыя распрацоўшчыкі аднолькава займаюцца, развіваюць і прыстасоўваюць практыку, і я даў мне магчымасць зразумець асноўныя прынцыпы.

Быць Agile дазваляе хутка задаволіць патрэбы кліентаў. Ці значыць гэта, што мы пішам код хутчэй? Не. Мы не можам перамагчы законы фізікі, і для стварэння трывалага шматфункцыянальнага прыкладання патрабуецца час.

Што нам трэба зрабіць, гэта

  1. Вызначце асноўныя праблемы бізнесу, якія мы хочам вырашыць з дапамогай кода
  2. Дайце тэарэтычнае рашэнне хутка, каб праверыць гіпотэзу
  3. Пераносяць і адаптавацца па меры змен патрэбаў ці мы даведаемся больш
  4. Рабіце гэта ў супрацоўніцтве, з заказчыкам займаецца частка каманды

Усё астатняе, што мы робім, складаем 2 і 3 вышэй менш балюча - ведаць, калі мы задавальняем патрэбу як мага хутчэй, а калі не зможам хутка змяніцца. Калі вы вырашылі пабудаваць (супраць пакупкі), вы пішаце спецыяльнае праграмнае забеспячэнне. Гэта азначае, што ён мае спецыялізаваныя патрабаванні і ўмовы.

Атрыманне чаго-небудзь бачнага, нават калі гэта невялікі падмноства функцыянальнасці, перад кліентам як мага хутчэй дазваляе атрымаць зваротную сувязь хутчэй. Вось чаму я заўсёды выступаю за тое, каб засяродзіць увагу на тым, каб стварыць невялікі фрагмент гэтай функцыі, каб скончыцца, і атрымаць усё гэта да вытворчасці. Скажыце, вы ствараеце старонку для сваіх агентаў падтрымкі, каб убачыць усе дадзеныя пра кліента. Замест таго, каб марнаваць шмат часу на даследаванне крыніц дадзеных для ўсёй старонкі і напісанне ўсіх API-першых, паспрабуйце атрымаць падмногу дадзеных на старонцы, аж да вытворчасці. Вы зможаце скарыстацца механізмамі інтэграцыі і разгортвання, вы зможаце пачаць атрымліваць зваротную сувязь пра рамкі карыстацкага інтэрфейсу, як гэтая старонка адпавядае астатняй частцы вашага прыкладання і г.д. калі вы стварылі цэлыя рамкі API.

Вось некаторыя іншыя механізмы, важныя для спрыту

Спрынты: развіваючыся ў скрынаванымі па часе цыклах, дазваляе нам правесці праверку і адаптацыю і ўсталёўваць новыя дадзеныя праз рэгулярныя прамежкі часу, каб пераканацца, што мы ўсё яшчэ працуем над адпаведнымі функцыямі. Праграмнае забеспячэнне - гэта адказнасць. Мы павінны будаваць толькі тое, што нам трэба, і мець магчымасць дадаваць тое, што трэба, калі гэта неабходна. Таму важна рэгулярна глядзець на тое, што мы пабудавалі дагэтуль і куды ідзем далей. Гэта прыводзіць да другога пункта.

Улічваючы, што мы плануем пастаянна ацэньваць і мяняць, наша праграмнае забеспячэнне павінна быць лёгка змяніць. Што рабіць, калі пасля таго, як кліент пачаў карыстацца дадаткам, яны хацелі, каб некаторыя дадзеныя паказваліся інакш, чым першапачаткова распрацавана? Ці маглі б мы зрабіць гэта, не закрануўшы ўсё астатняе на старонцы? Ці нам трэба патэлефанаваць у іншы API, каб атрымаць дадзеныя - ці маглі б мы зрабіць гэта змяненне бяспечна? Менавіта тут увайшлі добрыя практыкі і механізмы развіцця

Тэставанне блока: у нас ёсць аўтаматызаванае тэставанне на розных узроўнях, таму ёсць бяспека для змен. Таксама важна памятаць пра тое, што на самой справе правяраюць адзінкавыя тэсты. Блок тэстаў павінен праверыць логіку. Калі вы бярэце прыклад вышэй, выкарыстоўваючы іншы API для атрымання дадзеных, у ідэале, не патрабуецца ніякіх зменаў у тэстах адзінак для нашага API, які служыць дадзенымі ў інтэрфейсе. Іспыты адзінак існуюць, каб даць вам упэўненасць у тым, каб рэфактаваць код, які, у сваю чаргу, дае вам магчымасць пісаць толькі тое, што вам трэба зараз, і адпачыць пазней, каб не стварыць метрыку 100% пакрыцця ў любым выпадку.

CI / CD: Гэта дазваляе нам скараціць адлегласць паміж паслугамі і дастаўкай. Гэта неабходна для спрыту. Калі бар'еры для ўкаранення здымаюцца, і мы можам падштурхнуць невялікія змены ў вытворчасці, рызыка змяненняў значна зніжаецца. Калі разгортванне стомнае, яны сустракаюцца радзей. Радзей разгортванне выцясняе тону змен, дакранаючыся да вялікай плошчы паверхні, а значыць, і рызыкуе. Калі вы даведаецеся больш пра тое, чаму важная прадукцыйнасць дастаўкі праграмнага забеспячэння і якія метрыкі трэба выкарыстоўваць для яе аптымізацыі, настойліва рэкамендую гэтую кнігу Ніколь Форсгрэн.

Падзел праблем: Слаба звязаная архітэктура мае важнае значэнне для праграмнага забеспячэння, якое лёгка змяніць. Гэта памяншае плошчу паверхні змены. Мікрасэрвісы і кантэйнеры - некаторыя з механізмаў, якія выкарыстоўваюцца для развязання праблем. Важна памятаць пра гэта і абавязкова мець на ўвазе падзелу праблем пры стварэнні API, кампанентаў і прыкладанняў.

Памятайце
Добры код можна лёгка змяніць

Лепшы код можна лёгка выдаліць

Лепшы код - гэта той, які не пісаўся ўвогуле

Важна, каб біты, якія вы ствараеце, як мага хутчэй сустракаліся з рэальным светам, каб вы ведалі, як павінны выглядаць вашы новыя біты, і вы не марнуеце час на непатрэбныя біты.