Нов партньор?

partners[@]IT-PlayGround.net

Създадено за Вас

информирайте се, споделяйте

Пишете ни:

hello[@]IT-PlayGround.net

Защо да се присъедините?

1. чудесни членове в екипа - приятелски настроени, отворени за нови предизвикателства
2. споделяне на знание и опит от всички
3. организиране на социални събития със страхотните членове на екипа в Благоевград и/или София
4. промо кодове от партньорите ни
5. LinkedIn препоръки след известно време
6. още страхотни възможности. Останете в очакване ;)

свържете се с нас: hello[@]IT-PlayGround.Net

Основни концепции на ITIL & Agile

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

ИБИТ/ITIL (Инфраструктурна Библиотека на Информационните Технологии) и Agile (гъвкав, подвижен) са добили невероятна популярност, особено в усвояването им от производствените процеси на по-голяма част от IT гигантите. И да изброим няколко - IBM, HP, Lenovo и т.н. Изборът на това, кой метод да използвате като двигател на вашия бизнес зависи от целите, които сте си поставили. Тук, ще очертаем някои от основните разлики между двата метода. И въпреки, че това е правено хиляди пъти, ще опитаме да подчертаем практичността на всеки един от тях.

ИБИТ/ITIL или Инфраструктурна Библиотека на Информационните Технологии е по-старият от двата и се основава на голям брой "най-добри практики", разглеждайки продукта/услугата/програмата като единно образувание - едно цяло, което трябва да е напълно завършено в края на производствения цикъл. Клиента получава времева рамка, в която ще получи краен продукт с всички предварително избрани свойства, функции и варианти, върху които не може да се надгражда с нови такива, но могат единствено да бъдат подобрявани с нови версии. Структурата му е изградена от горе надолу - клиента и мениджърите решават какво е нужно и екипа от програмисти работи върху това. Методът разчита изключително на процеса на работа, и включва в себе си помощен модул, ИТ модул за услугата и т.н. - модули или отдели, които отговарят за различни функции на продукта или услугата. ФУНКЦИЯТА е фундаментално понятие в ИБИТ, тъй като целия цикъл на производство е посветен на нея и измерванията и статистиките са базирани на KPI/КПИ (ключови производствени индикатори). ИБИТ бива разделен на 5 основни етапа и обикновено времето, нужно за финалния продукт е по-дълго от това в Agile. Според виждането на мениджъра на проекта, един или няколко от тези етапи могат да бъдат пропуснати, но това е частен случай. Целият екип работи заедно по проекта и промените се изпълняват в една от фазите на процеса. Ето и 5-те етапа, и какво включват те в процеса на развитие и програмиране:

  1. Стратегия на услугата или продукта - включва визията и мисията на екипа
  2. Дизайн на услугата или продукта - включва планът, нужното време и средствата, необходими за завършване на проекта
  3. Преходен перид за услугата или продукта - включва програмиране и развитие до операционната фаза, управление на промените, управление на проекта, управление на производството на крайния продукт
  4. Оперативна фаза - включва управление на проблемите, управление на инциденти/грешки, управление на достъпа и поръчки по услугата
  5. Продължително подобряване на продукта/услугата - обърнете внимание, че това е функция за надграждане, а не за обновяване. Това включва въвеждането на нови технологии и нови функции. Основно води до напълно нов продукт в повечето случаи, поради значителни разлики във ФУНКЦИЯТА (не е задължително винаги да е така).


Това е най-лесното обяснение на ИБИТ, което мога да ви представя.

Agile от друга страна е по-малкият, но по-гъвкав брат на ИБИТ (или сестра, ако ви харесва повече). Концепцията тук е разделянето на екипа в малки групи - нещата се изпълняват в кратки отрязъци от време, екипа сам се управлява, има постоянна обратна връзка, целите се менят постоянно, и обикновено има седмични срещи в тази връзка. Мото на Agile би трябвало да е "Успей или се провали бързо", защото тук се изгражда основа, върху която се натрупват нови функции или качества на услугата/продукта. Тук няма дългосрочни цели, тъй като няма информация как ще изглежда крайния продукт, или можем да кажем, че тук няма понятие КРАЕН ПРОДУКТ. Всичко се изгражда на основата на нуждата от нови функции и постоянна промяна. Структурата тук е от долу нагоре, започвайки с програмистите и издигайки се по стълбицата, което дава невероятна гъвкавост. Присъстват информационните табла, списък със задачите и краткосрочни отметки - каквото е завършено, бива отбелязвано/отметнато на таблото. На седмичните срещи присъства постоянния контрол, който е по-сигурен и показва накъде се е насочило развитието на проекта.
Какво е сработило добре? Какво не е? какво искаме за бъдещето/за следващата седмица? - са само част от възможните въпроси на тези срещи.

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

Agile също така бива разделен на два възможни работни процеса. Имаме програмиране и развитие за определени времеви късове/рамки - SCRUM, при който получавате двуседмични периоди за вграждането на нови функции, и това което е останало встрани или е било незавършено, си остава незавършено и не се доразвива. И също така KANBAN, където няма времеви ограничения и рамки, но има определен комплект от свойства, който трябва да бъде имплементиран.

Ето и пример за двете практики:

Ако имаме една година време да вградим система за обратна връзка, система за резервни копия или бекъп, система за рейтинга и система за докладване на грешки в определен продукт/услуга, това е което ще получим:

SCRUM - ще имаме разделени малки отрязъци от време за отделните свойства/функции - в този случай 3-месечни периоди за всяко и програмирането/развитието ще е ограничено в неговата си област за този период от време. Не можете да развивате рейтинг системата във времевия период за бекъпа.

KANBAN
- получавате 1 година, за да имплементирате всички свойства. Това е. Няма определен ред, няма определени времеви срокове, за това кое ще е първо и кога ще има нужда от него (това в идеален свят, разбира се)

Това е, най-просто казано/написано, какво представляват ITIL/ИБИТ и Agile. Надявам се, сега вече ще е по-ясно кое какво е, когато срещнете термините и повече няма да се чудите каква е разликата.



Как да започнем от нулата с ITIL
Изчерпване на динамични портове (Ephemeral Port Ex...

Свързани публикации

By accepting you will be accessing a service provided by a third-party external to https://www.it-playground.net/bg/

Абонирайте се за новини свързани със сайта

Powered by:  www.sslavkov.eu