Културата често се игнорира и не разбира погрешно, но въпреки това тя е ключов фактор, отговорен за представянето на компанията. Ако не се справим с нашата култура, в крайна сметка ще правим грешни практики, които в крайна сметка ще повлияят на нашите бизнес цели.
Разбиране на настоящата култура на организацията
Културата ни разказва за ценностите и нормите в рамките на група или компания. Той идентифицира какво е важно, както и как хората подхождат и работят помежду си.
КУЛТУРА = „Как нещата могат да бъдат направени умно за успех“
Да вземем примера на екип за поддръжка на клиенти. Културата на този екип трябва да бъде такава, че в крайна сметка да постигне 97-98% от удовлетвореността на клиентите.
Като се има предвид удоволствието на клиентите, на първо място те трябва да бъдат учтиви, дори в трудни ситуации трябва да бъдат добри слушатели, за да избегнат объркване, което им е необходимо, за да приоритизират работата според изискванията.
Нека спрем за малко и си зададем няколко въпроса:
- Каква е културата на моята компания сега?
- Доколко тази култура е съобразена с моите бизнес цели или KRA?
- Какви проблеми мога да очаквам поради несъответствие?
За всяка организация 4Cs играе жизненоважна роля
Сега нека да разгледаме културата на организация, разработваща софтуер. Има много екипи, участващи в изграждането и поддръжката на един софтуерен блок. Всички тези отбори имат отделни цели и отделна култура.
Този процес започва след потвърждаване на изискванията от клиента.
Разработчиците следват указанията за кодиране, дефинирани от тяхната организация, а инструменти за програмиране като компилатори, интерпретатори, дебъгъри и т.н. се използват за генериране на кода. За кодиране се използват различни езици за програмиране на високо ниво като C, C ++, Pascal, Java и PHP.
Те разделят пълния пакет на малки папки и след това разработват съответно малки кодове.
Етап 1 : Тези малки единици кодове след това се обединяват, за да образуват голяма единица. Докато се интегрират по-малките чипове, трябва да се извърши тестване на ниво проект, известно като интеграционно тестване.
Етап 2 : След успешната интеграция тя се разполага в фиктивна система. Тази фиктивна система има подобна конфигурация като тази на клиентската машина или машината, където този проект трябва да бъде разгърнат най-накрая.
Етап 3 : И накрая, след тестване на всички функции в фиктивна система, проектът се разполага в производствения сървър или клиентската машина.
Въпреки че този процес изглежда много гладък и лесен на думи, в технически план е много трудно да се постигне.
Нека да видим с какви проблеми можем да се сблъскаме:
обръщане на номер в java
Етап 1 :
Клиентът винаги е в търсене на промени за подобряване на качеството на продукта. По-голямата част от времето, когато беше направена първата итерация, клиентът ще предложи няколко промени. Когато разработчиците получат промените, те започват да ги включват, което влияе върху интеграцията, водеща до счупени компилации.
Етап 2:
През повечето време тестерите или други оператори няма да са наясно с новите промени, които трябва да бъдат направени. Веднага след като получат кода от разработчиците, те започват да ги тестват. Докато на заден план разработчиците все още правят промените.
Тъй като не получават достатъчно време за внедряване на нови промени, те в крайна сметка разработват неефективни кодове, с които се сблъскват с други проблеми с мрежата и базата данни, което отново забавя времето им за доставка.
Когато накрая доставят кодовете на оперативния екип, им остава много минимално време за създаване и внедряване на нови тестови случаи. Така те пропускат много от тестовите случаи, които по-късно осъзнават, че те са от висок приоритет.
Етап 3:
Макар че на практика компилацията изглежда е готова за производство, но резултатите са напълно неочаквани. Компилацията е неуспешна и възникват редица грешки.
Тогава за всяка възникнала грешка те трябва да проследяват защо това се е случило, къде се е случило, какви промени трябва да се направят, за да се преодолее, ще има ли промени в кодовете на други, за да стане съвместимо с предишните. И накрая, за всички тези грешки трябва да се генерира отчет за грешка.
Неуспехът се дължи на системни грешки поради незнанието на разработчика на база данни в ефективността на кода, невежеството на тестера в броя на тестовите случаи и т.н.
Тъй като клиентът винаги държи строги срокове, служителите, участващи в постигането им, се концентрират само във финалната версия, дори ако трябва да компрометират цялостното качество.
c ++ как да използвам пространства от имена
Въпреки че това изглежда е проблем при координацията на работата, това всъщност е провалът на възприетата култура.
Това се случва поради голямата зависимост от ръчните процеси. Бягането насам-натам в един и същ екип поради липса на познания за различните области, липсата на достъп или липсата на интерес увеличава собствената ни тежест и болка.
Крайно време е да бъдем гъвкави. Може да е трудно да бъдеш господар на всички процеси, участващи в дадена система, но ние можем да бъдем крикът на всички, овладявайки един от тях. Тогава само ние можем да автоматизираме нашата система или да я направим достатъчно интелигентна, за да се възстанови, вместо да се върнем назад.
Сега може би си мислите защо?
Това е така, защото този, който владеете, е силно зависим от другите. За да знаем за точката на зависимост, трябва да разберем цялата система.
Така че нека помислим за процес за промяна на културата. Преди това имате ли отговор на въпросите по-долу?
- Къде се проваля сегашната ви култура?
- Защо искате да промените процеса?
- Идентифицирахте ли ясно всички необходими промени?
- Получихте ли обратна връзка и бай-ин от всички засегнати заинтересовани страни?
- Презаверихте ли дисциплината на процеса, данните и измервателната система за промяната?
И така, сега, когато имаме отговор на всички, мислим за революция в нашата система. Как ще се случи тази революция? Това може да бъде постигнато само когато убием това, което сме сега. Много време се губи в миграцията на кода между екипите. Трябва да внесем процеса, където можем да правим непрекъсната интеграция и непрекъснато внедряване.
Този процес на непрекъсната интеграция и внедряване го прави по-гъвкав. Привеждането на тази ловкост се счита за DevOps култура.
DevOps е практиката на инженерите по операции и разработки, които участват заедно в целия жизнен цикъл на услугата, от проектирането през процеса на разработка до производствената подкрепа.
Не е лесно да се промени работната система с течение на времето. Извършването на успешен преход е по-скоро обновяване на системата, отколкото възстановяване.
Сега нека видим как можем да постигнем това. Може да има два начина за подход.
1) От горе надолу
разлика между приспособленията и разширенията
2) Отдолу нагоре
Потопейки се по-дълбоко в тези техники, ще разберем кое е най-подходящо за нашата организация.
При подхода отгоре надолу можем да отидем при висшето ръководство и да поискаме от тях да направят промени във всички отбори. Ако тогава ръководството е убедено, можем да започнем да работим по него.
Но вероятността да получите отговор като „НЕ“ е доста голяма. Това е така, защото промяната на системата може да доведе организацията до нестабилност.
Те трябва да проучат структурата на организацията, приходите, нивото на интерес на клиента и т.н. Но най-важният фактор, който ги дърпа назад от излизането от старата система, е, че те не могат да видят голяма картина на това какво може да се постигне и колко гладко може да се постигне с по-новата.
В този случай можем да търсим втория подход, за да получим тази голяма картина.
Подходът отдолу нагоре изисква доброволец. Тук трябва да вземем малък екип и малка задача и да я изпълним в DevOps Model.
Разглеждайки техническата страна на този модел, ние имаме различни набори от сложни инструменти, които правят работата по-ефективна и бърза. Но само инструментите не са достатъчно способни да създадат среда за сътрудничество, наричана DevOps.
Създаването на такава среда изисква да мислите нестандартно, напр. оценка и преструктуриране на начина, по който хората мислят за своите екипи, бизнеса и клиентите.
Съставянето на нов набор от инструменти е по-просто от промяната на организационната култура. Чрез насърчаване на разработчиците на антисоциални програми, позволяване на интегриране на неефективен код, внедряване на кодове, които не са били правилно тествани, поставяне на обвинения върху главите на другия, считайки, че оперативният екип е глупав, не са най-добрите практики, които следваме, за да дадем възможност на бизнеса и създаваме стойност за нашите клиенти.
Не инструментите, а хората, които ги използват, правят процеса сложен. Да кажем на абстрактно ниво, а не да събираме идеи и поведения, да бъдем отворени за тях, ни води към светъл път.
Нека започнем с екип от 6 членове и история от 3 точки. Първо, трябва да разбием екипа, който наричаме като разработчици, оператори, тестери и т.н. Ние ги разглеждаме като едно цяло, кажете „DevOps“. Когато получим изискванията, трябва да анализираме рисковите зони. Имайки предвид по-дълбоките участъци от морето & hellip .. Започваме да плаваме.
Сега трябва да се замислите „какъв е х-факторът на тази непрекъсната интеграция и непрекъснато внедряване, което намалява вероятността за отказ“.
С подобрената визия и процес можем да се обърнем към ръководството, като представим ясната картина на резултатите като колко гладък е бил процесът, как е намален рискът от неуспех, как задачата е изпълнена преди времевата линия и т.н.
Сега можем ясно да визуализираме как целият процес е оптимизиран на техническа и културна основа, като имаме ретроспекция след всяка итерация.
Edureka е специално подготвен което ви помага да овладеете концепции около Puppet, Jenkins, Ansible, SaltStack, Chef и др.
Имате въпрос към нас? Споменете ги в раздела за коментари и ние ще се свържем с вас.
Подобни публикации: