Трудно е да се намери човек, който не би искал да бъде третиран с уважение. Но за това състояние на нещата трябва да има причина. Например, когато човек е първокласен признат професионалист в областта на разработката на софтуер. И за това е необходимо да се учи. И в тази статия ще бъде разгледано какво е Agile, каква е ползата от нея и как да се разбере тази технология.
Обща информация
Първо, нека разгледаме техническите въпроси. Какво е Agile? Преводът (словесното) на думата от английския език - "жив, мобилен", е малко по-рядко наричан "гъвкав". И между другото, това е намаление. Пълното име на този подход е Agile software development. Но тъй като беше прекалено дълго, беше решено да се намали. И сега казват само Agile. Преводът като „гъвкав“ се използва, защото е най-подходящ за реалната ситуация.
Какво е включено тук?
Ние продължаваме да разглеждаме какво е Agile. Тук би било желателно да се концентрираме върху факта, че това е гъвкав подход, основан на много различни методологии (Scrum, XR, Kanban, Lean). За да разберем по-добре темата, нека направим паралели. Да приемем, че Agile-технологията е процес на произход на Вселената. Крайният продукт е самото съществуване на самия свят. Големият взрив е най-болезненият проблем, с който човек трябва да отговори - промяната в списъка с изисквания за продукта. Обикновено процесът на създаване включва използването на каскаден модел. В товаслучай всичко върви последователно и на етапи. Този подход може да се изрази накратко: виждам целта - отивам при нея. И ако изискванията за крайния резултат се променят, понякога е необходимо да се повторят отново или не всички. Това, което допълнително усложнява тази ситуация, е да се опитате да се преструвате, че всичко е наред и трябва да продължите напред.
И тук Agile, методологията на управление, е призвана да се бори с всичко това поради своята гъвкавост. Този състав "Сол" минимизира различните рискове, като използва принципите. Всички те са отразени в манифеста Agile, публикуван през 2001 г. Накратко, звучат така:
Най-важното е хората, а не нещата.
Да си сътрудничат и да не четат договора.
Документацията не трябва да пречи на работата.
Промяна възможно най-бързо.
Може да изглежда прекалено неясно и не е точно, но нека да разгледаме подробно.
Process Devices
Като се има предвид какво е Agile, нека се обърнем към една от най-популярните методологии, известни като Scrum. Какво предлага той? Първо, трябва:
Изберете собственика на продукта. Този човек идва с човек, който вижда какви цели трябва да върви и какво ще свърши.
Определете екипа. За да направите това, имате нужда от група от 3 до 10 души, които имат уменията да получат резултата.
Изберете отговорен специалист. Това е човек, който ще следи развитието на проекта и ще помогне на екипа да преодолее трудностите.
За преодоляване на трудностите. Тя трябва да се събира на едно мястовсички съществуващи изисквания за продуктите и да се приоритизират. Собственикът на продукта трябва да събере всичките си желания тук. Тогава екипът ги оценява и разбира, дали може да се реализира и колко време отнема за това.
Необходимо е да се раздели целият обем работа на продължителност от една седмица или две, през която екипът ще изпълнява определени задачи.
Всеки ден трябва да се провеждат срещи, с продължителност не повече от петнадесет минути. За да обсъдим какво е направено, какви са плановете за днес и пречките, които пречат на височината.
Прегледайте резултатите от седмицата (две), по време на която на екипа е разказано какво е направено. Необходимо е да се демонстрира работата на части от продукта.
След всеки период от време е необходимо да се обсъждат проблемите и да се търсят решения. Нещо повече, всяка работа трябва да се изпълни незабавно.
Как да идентифицираме Agile?
Методологията на управление, независимо от избраната посока, винаги има следните характеристики:
Минимизиране на рисковете. Това е основната цел, преследвана от всеки гъвкав подход.
Итеративно развитие. В този случай имаме предвид робот в малки цикли.
Най-важното е хората и комуникацията между тях. Да си представим реката. На един бряг клиентът. Вторият е екип. В този случай гъвкавата методология на развитие има предимства за всички:
Клиентът се нуждае от минимален работен продукт. В същото време по време на създаването му условията могат да се променят.
За екипа е полезно да комуникирас колеги и клиенти. В този случай рискът от неправилно разбиране се свежда до минимум, прозрачността на процесите се увеличава, проблемите се решават бързо, намаляват се шансовете за изненада при създаването на продукт.
Социален фактор
Когато става въпрос за казвайки Agile, обикновено се говори за положителни неща. И наистина, взаимодействието вътре в екипа се подобрява. Всички хора се фокусират върху една идея, не създават тайни помежду си, поемат ангажимент. В резултат на това екипът работи в комфортни условия и бързи темпове. Този подход ви позволява да сортирате хаоса. От създаването си той е успял да намери признание в технологичните области. В момента се използва широко за проектиране на нови софтуерни продукти. Но в рамките на общата бизнес практика този подход все още е малко известен. Ето защо тези, които не са срещнали Agile, са предпазливи по отношение на това. Трябва също да се разбере, че тя трябва да се използва само в случаите, когато задачата на интелектуалния труд е изправена пред хора.
Малък пример
Да разгледаме как работят тези методологии за разработка на софтуер. Например, имаме Питър, собственик на продукта. Той не знае техническите подробности, но има визия за общата картина. Той знае защо един продукт се нуждае от проблем, който ще реши кой ще задоволи. Има и заинтересовани лица. Те могат да използват продукта, да го поддържат или как да се включат преди неговото създаване. Можете също така да си направите собствени истории, в коитоизразяват се желанията на заинтересованите лица. Например: система за резервиране на билети за автобусни автобуси Москва-Санкт Петербург трябва да се търси по време на полет. Петър ще помогне на засегнатите. Той ще поеме контрола върху изпълнението на идеите на потребителските истории. Има и екип от разработчици. Това са хора, които ще изградят работеща система. Тъй като се използва гъвкава методология за развитие, потребителските истории не се натрупват до голямото издание и се издават веднага след приключване и колкото е възможно по-често. Броят на обработените хитове е пропускателната способност на екипа за една седмица. За да поддържа темпото и да не се занимава с ръчно тестване, екипът трябва да работи по автоматизирана интеграция. За какво става въпрос? За всеки работен момент се записва автоматичен тест. Ако има толкова много истории, може да има бързане, загуба на мотивация, по-ниска производителност и качество. В такива случаи е предвиден методът "вчерашното време". Тя се състои в това, че е необходимо да се установи строг обхват на работа и да се подбира внимателно какво ще се изпълнява. Посоченият по-горе Канбан предлага да се определи лимит на задачите.
И какво да правим с завоя?
Добре, тук екипът реши, че може да се справи с четири истории на седмица. Но как да се ориентираш във всичко, което е? Да предположим, че потребителите качват десет истории на седмица. Четири са обработени. По този начин опашката ще нараства постоянно. В този случай има само един ефективен метод - думата "не". За собственика на продукта еизключително важно. Да се каже "да" не е трудно. Много по-трудно и по-важно е да се реши какво да се направи не е необходимо. И за това е необходимо да носим отговорност. Ето защо е необходимо да се реши защо да се обръща внимание сега и какво трябва да се отложи. За правилното определяне на приоритетите, собственикът на продукта трябва да разбере стойността и обема на всяка история.
Ние вземаме решение
Част от историите са изключително необходими. Други просто представляват хубав бонус. Някои истории ще бъдат разработени няколко часа. Създаването на други ще отнеме месеци. Много често правят връзка между размера на историята и нейната стойност. Но това не винаги е правилно. Още - не по-добре. Петър счита, че приоритетите трябва да бъдат адресирани правилно от сложността и стойността на изпълняваната задача. Как да определим тези характеристики в количествено изражение? Но няма начин. Това е истинска игра на познаване. И за по-голяма ефективност трябва да привлече много хора. Това е екип от разработчици, които ще информират за обхвата на работата и заинтересованите лица. Но трябва да се разбере, че всички получени по този начин данни са приблизителни предположения. Тук няма точни числа. Първо ще има пропуски. Но с натрупването на опит техният брой и мащаб ще намаляват.
Възможни рискове
За да се избегнат проблеми, е необходимо да се дадат честни отговори на редица въпроси. Това е:
Правим ли правилните неща? Това е бизнес риск.
Можем ли да осъзнаем това, от което се нуждаем? Това е социален риск.
Ще работи ли проектът на тази платформа. Това е технически риск.
Достатъчно ли епари, и ще имаме ли време? Това са рисковете от изпълнението и разходите.
В този случай е необходимо знание. Те могат да се разглеждат като противоположни на рисковете. Когато се регистрира значително ниво на несигурност, ние придобиваме знания - например, създаваме прототипи на интерфейса или технически експерименти. И вече ги притежаваме, ние вземаме решение по коя посока да се движим.
Как да се учим?
ИТ индустрията се развива изключително бързо и за да не загуби в дългосрочен план, е необходимо непрекъснато да се учат, да се повишават квалификациите и ефективността на работата. Следователно, както никога преди, въпросите за обучението и изпълнението. Откъде да започнем? Най-добрият вариант е да си сътрудничите с компания, която вече използва Agile. Проучването в този случай ще се извършва от хора, за които не се говори, че знаят какво е гъвкаво развитие. Но това, за съжаление, не винаги е възможно. Най-често използваният е специалист от трета страна, който знае какво е Agile. Прилагането на този подход е под негов надзор. Вярно е, че услугите на такъв специалист си струват парите. Но ако нарисувате наистина опитен човек, тогава всички разходи ще бъдат изплатени на стотни. Всъщност в днешния свят ефективността на служителите играе важна роля.
Какво може да се очаква в бъдеще?
Методологиите за разработване на софтуер постоянно се развиват. Търсене на нови начини и възможности за повишаване на ефективността на работа и работа. Да се каже, че чакаме бъдещето е доста проблематично. Вероятно ще бъде интегрирана гъвкава система за развитие с средствата за автоматизация на производствените процеси. Например, ще бъде възможно да се решипроблеми дори когато са далеч от местоположението на компанията. В много отношения се определя бъдещето на новите информационни технологии. В крайна сметка, когато възникнат, трябва да овладеете нови методи за работа с тях. И в този случай има развитие, затворено в цикъл.
В заключение
Тук и там завърши екскурзията с гъвкави методи на развитие. Но трябва да се напомни, че едно нещо е теорията, а съвсем друго - практиката. Новите нови информационни технологии предизвикват голям брой разработчици. Как да направим екипа по-ефективен? Отговорът на този въпрос е открит от всички. Представената тук информация може да се използва за създаване на скелет. На практика обаче ще трябва да работи със съществуващия модел и да актуализира ситуацията със съществуващите предизвикателства. Тогава екипът може ефективно да изпълни целите си.
