Аджайл — это не язык программирования, не фреймворк, не какая-то сложная

техническая штука. Это настолько всё просто, что если вы досмотрите этот ролик

до конца, вы перестанете бояться этого слова. Если вы увидите вакансию с...

меня зовут Екатерина Вестер. Я проработала 10 лет в крупных корпорациях. Одним из проектов

например, было создание беспилотного автомобиля Chevrolet Bolt в компании

General Motors. Я занимаюсь обучением техническим навыкам. Например, сейчас у

меня есть два курса: один по базам данных SQL и один по… У меня фишка в том, что очень

очень много практики. Мои ученики много-много пишут на языке и… Ссылка на

мои курсы в описании под этим видео. А теперь давайте продолжим касательно

Аджайл. Чтобы понять, для чего его вообще придумали, я сейчас объясню, как было

раньше. Примерно в 70-е годы было несколько ступеней, так называемый

Waterfall, водопад, каскадная модель разработки. Несколько ступеней. Как это

вообще выглядело? Допустим, у вас проект для какой-нибудь банковской системы.  Банку нужно,

чтобы у него много там всего было: отправка договоров, заключение сделок с

другими банками, ипотека и так далее. Это есть большой такой крупный

Для продукта сначала пишутся требования, собираются данные, всё это длится месяц, согласуется.

Потом переходит на следующую фазу — проектирование. Проектируется вся система целиком, вся функциональность.

Затем разработчики пишут код — месяц, два, три, в зависимости от объёма работы.

Дальше всё передаётся в тестирование.  Сначала и до конца тестируется.

Представьте, если на этапе тестирования возникли несогласованности с требованиями, с тем, что хотел заказчик, и тем, что разработали разработчики...

Всё это возвращается обратно спустя много месяцев.  После тестирования поставляется заказчику.

Происходит запуск, инсталляция в среде заказчика, и… ничего не работает.

Вся работа, которая шла по фазам, оказывается не то что коту под хвост…

Вот такая ситуация, и теперь нужно вернуться к истокам. Да, там имена, а кто и...

фазе, где что-то упало, там это всё переделывать, и ещё ответственный...

Например, если вы меняете проектирование, то это может повлечь множество других

изменений, и, как вы видите, процесс разработки получается длинный. Вы в конце

не знаете, что вы получите, получится ли то, что ожидал заказчик, или да, он...

как-то той картинке, где ожидание не сходится с реальностью, и...

кроме того, это получается соответственно дорого, и такая тяжеловесная

система разработки ещё и медленная. Но в текущем мире, если вы разрабатываете, да...

там вам нужно мобильное приложение, и вы работаете таким образом, то вы ваш бизнес

вообще поздравите со всем на свете. Поэтому придумали гибкие процессы

разработки, так называемый Agile. Да, то есть кто-то говорит, что это методология

разработки программного обеспечения, а сами создатели Agile говорят, что это

вообще философия, то есть это то, как ты живёшь. И в чём разница, если

была вот такая каскадная модель, the waterfall, или всё вот это дело...

она как будто схлопывается, да, и делится на маленькие итерации, от 2 до, не знаю...

Дам 8 недель, допустим, возьмем там три недели. У нас есть три недели, в этот…

Эти 3 недели берется какое-то одно требование, оно проектируется,

разрабатывается, тестируется и поставляется заказчику, и сразу

спрашивает: "Это то, что вы хотели? Дайте нам фидбэк", и переходим дальше. Еще три

недели, еще три недели, и получается вот такая гибкая система. То есть это вот waterfall,

в грубом говоря, миниатюре. И какие плюсы

таких маленьких имплементаций? Во-первых, вы не берете всю систему, вы берете

маленькие кусочки, и по каждому кусочку вы можете получить сразу фидбэк от

заказчика. В этом одно из преимуществ данного подхода.

Соответственно, вы можете быстро что-то изменить, среагировать. То есть получается быстрая

разработка, и стоит это соответственно дешевле. И у вас

нету вот этого подарка в конце целого проекта, чтобы *бах* — и все взорвалось.  Да,

казалось бы, звучит это все круто, но тем не менее, у него или есть свои минусы.

Основной минус — что при таком подходе проект получается мало задокументирован.

То есть, если кто-то уходит, то знания могут уйти вместе с этим человеком. Нет…

времени писать там очень подробную документацию, на это не заморачиваются.

Есть подход такой: fast and dirty — быстро и грязно. Вот разработка

получается быстро, но не всегда задокументирована. Если мы говорим о

каких-то серьёзных проектах, да, там, как

банковская система, то тогда, конечно, предпочитают другие методы разработки,

чтобы была полная, чёткая документация, чтобы ничто никогда не потерялось.

Создатели Agile написали целый манифест, он описывает 12 принципов Agile и 4

ценности. Вы можете почитать об этом в Википедии, там очень просто и понятно

написано. А теперь подведём просто итог: да что такое Agile? Agile — это гибкая

методология или гибкий подход к разработке программного обеспечения,

при котором получается, что коммуникация в команде важнее, чем процессы или

инструменты. На вот насчёт вот этого всего не заморачиваются. Готовый продукт

важнее, чем что бы то ни было. Уважают коммуникации,  встречи осуществляются

часто, как правило, в конце каждой итерации. И при этом Agile — это гибкий

подход, а соответственно, команда готова к изменениям, готова что-то менять по ходу.

Дела, еду, забыла сказать, что "Agile" — это обобщающий термин, существует много

различных подходов, основанных на методологии Agile, таких как Scrum, Kanban,

ну, там и другие. Поэтому имейте в виду, что Agile — это основа, база, из которой

могут вытекать различные вот такие направления по управлению проектами. Вот

и всё. Если вы видите в вакансии слово "Agile", вы теперь понимаете, что это значит.

Понимают, как работает команда. Да, то есть, когда вы только вливаетесь в группу, вы

уже имеете представление, как это выглядит. Я прям настоятельно рекомендую:

если вы открываете вакансию, если просто пробегитесь по всем непонятным словам,

посмотрите определение. Может быть, это что-то такое простое, как тот же

Agile, что можно погуглить за час-два и быстро

разобраться. И это не должно вас останавливать, чтобы не подать резюме на какую-то

вакансию. Я, к слову, интересный пример:  входил в сферу, и один из моих

подписчиков, которому, на минуточку, 42 года, то есть он зашёл с нуля, без

образования соответствующего. То переходите к следующему ролику. На этом

ЧТО ТАКОЕ AGILE - АДЖАЙЛ ЭТО..

Ekaterina Wexler - Айти - Айтишечка

애자일은 프로그래밍 언어, 프레임워크 또는 복잡한 기술 도구가 아닙니다.

예카테리나 웩슬러 소개, 제너럴 모터스 등 대기업에서의 경험, 실용적인 기술 교육에 중점을 두고 있습니다.

실무 적용에 중점을 둔 SQL 및 기타 강좌에 대해 언급합니다.

애자일과 그 기원에 대한 설명으로 전환합니다.

소프트웨어 개발의 폭포수 모델

소프트웨어 개발에 사용되는 다단계 프로세스인 워터폴 모델에 대한 설명(70년대).

워터폴 모델의 단계인 요구 사항 수집, 설계, 개발, 테스트 및 배포를 설명하는 은행 시스템 프로젝트의 예입니다.

워터폴의 문제점: 테스트 중에 발견된 불일치로 인해 상당한 재작업과 지연이 발생했습니다.

폭포수 접근 방식의 결과: 프로젝트 실패 및 처음부터 다시 시작해야 하는 경우.

워터폴 모델의 단점: 긴 프로세스, 최종 제품에 대한 불확실성, 높은 비용, 느린 개발 속도.

워터폴 모델의 한계에 대응하는 애자일은 유연한 개발 프로세스 또는 철학으로 설명됩니다.

애자일의 반복적 접근 방식: 프로젝트를 더 작은 반복(예: 3주 스프린트)으로 세분화합니다.

애자일의 장점: 고객의 잦은 피드백, 빠른 개발, 비용 절감, 프로젝트 실패 위험 감소.

주요 단점: 덜 포괄적인 문서화, 팀원 이탈 시 잠재적인 지식 손실.

'빠르고 간편한' 접근 방식과 다양한 프로젝트 규모에 대한 적합성에 대해 언급합니다.

애자일 선언문과 그 12가지 원칙 및 4가지 가치는 위키피디아에서 확인할 수 있습니다.

요약: 애자일은 커뮤니케이션, 빈번한 피드백, 적응력을 우선시하는 유연한 방법론입니다.

애자일은 스크럼, 칸반 등 다양한 접근 방식을 포괄하는 포괄적인 용어입니다.

직무 지원 시 애자일을 이해하도록 권장합니다.

직무 설명에서 낯선 용어를 조사할 것을 권장합니다.

IT 분야로의 성공적인 경력 전환 사례.