- - - - - - - - -
Как правильно учиться в IT - сфере. ТОП ошибок при обучении. Конкретный план обучения.
- - - - - - - - -

Как правильно учиться в IT - сфере? В этом выпуске автор даст конкретные советы о том, как, на его взгляд, правильно эффективно обучаться в IT - сфере, в том числе программированию. Разберет частые ошибки, мешающие эффективному обучению, расскажет как про бесплатное самообразование, так и обучение на платных курсах и в университетах.

https://www.youtube.com/watch?v=eKZNKA-jAYY

https://www.youtube.com/watch?v=eKZNKA-jAYY

- - - - - - - - -
Полезные статьи. Часть 5.
- - - - - - - - -

1. Что такое тестирование функциональности в программном обеспечении: https://tryqa.com/what-is-functionality-testing-in-software/
2. Автоматизация тестирования производительности: основные положения и области применения: https://svyatoslav.biz/technologies/performance_testing/
3. Типы тестирования производительности: https://msdn.microsoft.com/en-us/library/bb924357.aspx

Вопрос №24

Q: Расскажите про основные особенности Agile подхода к разработке ПО
A: Раньше продукты делали сразу целиком, т. е. в рамках каскадной модели (Waterfall model), где все происходит поэтапно и последовательно. Для этого они шли по цепочке:
1. идея
2. техзадание
3. дизайн
4. программирование
5. тестирование
6. Релиз

Если на этапе дизайна появлялась новая идея, приходилось игнорировать её или переделывать все предыдущие этапы. Это было неудобно — проект или получался хуже, чем мог бы, или растягивался во времени и не укладывался в бюджет. Прогрессивные разработчики стали пробовать новые подходы к работе. Так появились Скрам, Канбан и ещё с десяток новых техник. Команды могли тестировать и изменять продукты в процессе работы. Эксперименты оказались удачными: клиенты получали отличные продукты, разработчики выдерживали сроки и бюджеты, а размеры компании не влияли на продуктивность команд.

Чтобы найти формулу успешных продуктов, в 2001 году 17 практиков современных подходов собрались в маленькой горной деревушке Сноубёрд. Они обсудили свои стратегии разработки и сделали открытие: подходы у всех разные, но общие идеи совпадают. Эти идеи легли в основу «гибкой» философии, которую назвали Аджайлом. Их записали в Agile Манифесте и дополнили Принципами Аджайла.

Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum, FDD.

На что обратить внимание в определении?
1. Agile - серия подходов к разработке. Это значит, что Agile включает в себя целое семейство методик. И говорить, к примеру, что Agile - это SCRUM(хотя SCRUM и является самой популярной Agile методологией), абсолютно некорректно.
2. Agile подразумевает итеративную разработку. Работа идет короткими отрезками времени(спринтами), по окончанию отрезка - промежуточный вариант рабочего продукта. Работающий продукт выпускается как можно чаще, с периодичностью от пары недель до пары месяцев. Тем самым удовлетворяются потребности заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
4. Требования к продукту формируются динамически. Команды могут тестировать и изменять продукты в процессе работы — за это Agile подходы и назвали гибкими. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе. Изменение требований приветствуется, даже на поздних стадиях разработки.
5. Команда состоит из специалистов различного профиля.

Итого:
1. Самое главное люди и взаимодействие.
2. Работающий продукт важнее исчерпывающей документации(которую очень ча

сто еще никто и не читает).
3. Сотрудничество с заказчиком важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.

Вопрос №25

Q: Расскажите про основные преимущества Agile подхода к разработке ПО
A: Что получаем мы (как команда)?
1. Больше общения.
С командой: внутри коллектива складываются настоящие команды, где один за всех, и все за одного. Такие мушкетёры делятся проблемами и в нужный момент приходят товарищу на помощь ради успеха общего дела.
С заказчиком: команде на руку общение с заказчиком(чтоб без этого: «Вы меня неправильно поняли — переделайте все быстренько. И да, это надо вчера!»), прозрачность процессов, что уменьшает шансы на неожиданности, быстрое решение проблем. Ну и многие понимают, куда девается время и где работа стопорится. Мелочь (на самом деле нет), а приятно.

2. Свобода от диктата бумажек и начальников.
Профессионалы могут больше времени посвящать интересным задачам и развитию своего потенциала, и меньше — подготовке формальных отчётов или бессмысленным митингам ради регламента.

3. Отключение от матрицы рядовых сотрудников.
Они перестают быть винтиками, от которых ничего не зависит. Люди задумываются о профессиональном развитии, работа становится важной и интересной. Сотрудники перестают ждать окончания рабочего дня, чтобы выйти из офиса и начать жить.

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

Что с заказчиками?
Заказчик вовремя получает хотя бы минимально работоспособный продукт (не важно, речь идет о ПО или же о других процессах и явлениях), меняет условия, при этом не оставаясь с дыркой от бублика в кармане, — это уже к вопросу о страховании рисков.

 - - - - - - - -
Собеседование Тестировщика - как тестировать карандаш
- - - - - - - - -

Типичное задание на собеседовании тестировщика - запрос протестировать карандаш, кружку, лифт или любой другой предмет.

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

https://www.youtube.com/watch?v=RCkXBY6W2XY&list=WL&index=10

https://www.youtube.com/watch?v=RCkXBY6W2XY

Вопрос №26

Q: Расскажите про основные недостатки Agile подхода к разработке ПО
A: С Agile легко потерять чувство равновесия. В разработке программного обеспечения нет волшебной пилюли или бесплатного сыра. Если вы хотите принять гибкие принципы, вы должны быть уверены, что менеджмент и команда понимают все правила. Также нужно признать, что требования заказчика могут быстро стать подводными камнями:

1. Меньше предсказуемости
Для некоторых программных продуктов разработчики не могут в полной мере количественно оценить требуемые усилия, особенно в начале жизненного цикла разработки крупных продуктов. Команды, не имеющие опыта гибкой разработки, боятся этих неизвестных. Этот страх приводит к разочарованию, плохим практикам и часто к плохим решениям. Более регламентированный каскадный процесс (Waterfall model) позволяет легко определить количество усилий, времени и стоимости поставки конечного продукта.

2. Больше времени и приверженности
Тестировщики, клиенты и разработчики должны постоянно взаимодействовать друг с другом. Потребуются многочисленные беседы лицом к лицу, так как они являются лучшей формой общения. Все участвующие в проекте люди должны тесно сотрудничать. Ежедневно клиенты должны быть доступны для оперативного тестирования и утверждения на каждом этапе, так чтобы разработчики смогли отметить его как выполненный, прежде чем перейти к следующей функции. Благодаря этому продукт лучше соответствует ожиданиям пользователей, но процесс является обременительным и отнимает много времени. Он требует больше времени и энергии всех участников.

3. Повышенные требования к клиентам
Принципы Agile требуют тесного сотрудничества и активного участия пользователя. Хотя это интересная и полезная система, она требует большего участия клиентов для успешного завершения проекта. Клиенты должны пройти обучение, чтобы помочь в разработке продукта. Любой недостаток участия клиента будет влиять на качество программного обеспечения и конечный успех.

4. Отсутствие необходимой документации
Поскольку требования к программному обеспечению уточняются как раз во время разработки, документация не слишком подробна. Это означает, что если к команде присоединятся новые члены, они не будут знать подробностей, некоторых особенностей или как они должны действовать. Это создает недоразумения и трудности.

5. Проект легко сбивается с пути
Этот метод не требует подробного планирования для начала работы и предполагает, что потребности заказчика постоянно меняются. Такие недостаточные исходные данные могут ограничить использование Agile. Затем, если обратная связь заказчика не ясна, разработчик может сфокусироваться на разработке в неправильном направлении. Кроме того, имеется опасность неконтролируемого расширения границ проекта, и постоянно меняющийся продукт становится бесконечным.
Подводя итог:

Да, у Agile есть свои подводные камни. Да, не факт, что методология сразу начнет работать на вас, а не против. Но поверьте, при грамотном подходе и полном

понимании сути и всех нюансов Agile методологии Вы получите действительно рабочую и эффективную схему выстраивания рабочего процесса в Вашей команде.

- - - - - - - - -
Полезные статьи. Часть 6.
- - - - - - - - -

1. Тестирование на основе поведенческих моделей. Введение: https://www.womentesters.com/behaviour-driven-testing-an-introduction/
2. Что такое переходное тестирование в тестировании программного обеспечения: https://tryqa.com/what-is-state-transition-testing-in-software-testing/
3. Хороший пользовательский интерфейс: https://cmsmagazine.ru/journal/items-186846/

Вопрос №27

Q: Что такое SCRUM?
A: SCRUM - одна из методологий гибкой разработки.
SCRUM состоит из:
1. Скрам Команд (Scrum Teams), внутри которых распределены соответствующие роли (roles),
2. Мероприятий (events),
3. Артефактов (artifacts),
4. Правил (rules)

Каждый компонент SCRUM имеет свое предназначение и является ключевым для его успеха и использования. В последующих постах рассмотрим каждый из компонентов подробнее.

Вопрос №28

Q: Расскажите про роли участников SCRUM команды.
A: SCRUM команда состоит из:
1. Владельца Продукта (Product Owner);
2. Команды Разработчиков (сюда же включаем тестировщиков) (Development Team);
3. Скрам Мастера (Scrum Master).

Скрам Команды являются самоуправляемыми и кроссфункциональными. Самоуправляемые команды сами выбирают, как наилучшим образом выполнить работу, и не ждут указаний от людей, не входящих в состав Команды. Кроссфункциональные команды имеют все необходимые навыки, чтобы выполнить работу и не зависеть от остальных, не являющихся частью их Команды. Командная модель Скрама создана для оптимизации гибкости, креативности и продуктивности.
Подробнее про составляющие команды:

1) Владелец Продукта
Владелец Продукта ответственен за достижение максимальной ценности продукта и работы, исполняемой Командой Разработчиков. Он является единственным человеком в Команде, отвечающим за бэклог(он же Журнал Требований к Продукту или Product Backlog). Управление бэклогом включает в себя:
1. Четкое определение и упорядочивание элементов бэклога;
2. Ответственность за ценность работы, исполняемой Командой Разработчиков;
3. Обеспечение доступности, прозрачности и понятности бэклога, а также отображения тех требований, над которыми Скрам Команде предстоит работать в ближайшее время;
4. Ответственность за понимание Командой Разработчиков требований бэклога на надлежащем уровне.

Владелец Продукта может либо сам выполнять вышеперечисленные функции, либо предоставить их выполнение членам Команды Разработчиков. Однако, подотчетным считается именно Владелец Продукта. Владелец Продукта это только один человек, а не группа. Владелец Продукта может представлять интересы группы в бэклоге, но желающие изменить приоритетность требований бэклога должны в первую очередь убедить в этом Владельца Продукта. Для успешного выполнения Владельцем Продукта своих обязанностей все члены организации должны уважать его решение.

2) Команда Разработчиков
Команда Разработчиков состоит из профессионалов, выполняющих работу по разработке потенциально “готового” к выпуску Инкремента продукта в конце каждого Спринта. Инкремент создают только члены Команды Разработчиков. Команды Разработчиков являются структурированными и уполномоченными самим организовывать и управлять своей работой. Эта синергия усиливает продуктивность и эффективность работы Команды Разработчиков.
Командам Разработчиков присущи следующие характеристики:
1. Они самоуправляемы. Никто (и даже Скрам Мастер) не может указывать Команде, как правильно превращать Журнал Продукта в Инкременты работающей функциональности.
2. Команды Разработчиков кроссфункциональны, и обладают всеми навыками, необходимыми для разработки Инкремента продукта.
3. Скрам не признает никаких других должностей в Команде Разработчиков, кроме Разработчика, невзирая на вид работы, выполняемой человеком. У этого правила нет исключений.
4. Отдельные члены Команды Разработчиков могут владеть специализированны

ми знаниями в различных областях, однако ответственность лежит на всей Команде Разработчиков, подразумевающейся одним целым.
5. У Команды Разработчиков нет структурных подразделений, которые бы выполняли отдельные функции, как, к примеру, подразделение тестирования или бизнес-анализа.

3) Скрам Мастер
Скрам Мастер ответственен за то, чтобы Скрам был гарантированно понят всеми участниками и работал. Скрам Мастер достигает этого, следя за тем, чтобы все участники Команды придерживались теории, практик и правил Скрама. Скрам Мастер является слугой-лидером для Скрам Команды. Скрам Мастер также помогает людям, не входящим в состав Скрам Команды, понять, какие из их взаимодействий со Скрам Командой являются полезными, а какие нет. Скрам Мастер содействует изменению таких взаимодействий для увеличения ценности продукта, создаваемого Скрам Командой.
Скрам Мастер во многом помогает остальным членам команды.

Владельцу Продукта:
Обнаруживает методы эффективного управления Журналом Продукта.
Сообщает видение, цели и элементы Журнала Продукта Команде Разработчиков.
Учит Команду Разработчиков создавать лаконичные и понятные элементы Журнала Продукта.
Осуществляет долгосрочное планирование по продукту в эмпирической среде.
Понимает и практикует гибкие методы разработки и управления.
По требованию или необходимости может выступить ведущим мероприятий Скрама.

Команде Разработчиков:
1. Учит Команду Разработчиков самоуправлению и кроссфункциональности.
2. Учит и ведет за собой Команду Разработчиков при создании продуктов с высокой ценностью.
3. Устраняет помехи, которые возникают в процессе работы Команды Разработчиков.
4. При необходимости проводит мероприятия Скрама.
5. Проводит необходимые тренинги для Скрам Команды в тех организационных областях, в которых Скрам еще не до конца внедрен и понят.

Организации:
1. Ведет и тренирует организацию на ее пути внедрения Скрама.
2. Планирует этапы внедрения Скрама в пределах организации.
3. Помогает сотрудникам компании и заинтересованным лицам понять и внедрить Скрам и принципы эмпирической разработки продукта.
4. Выступает инициатором изменений, усиливающих продуктивность Скрам Команды.
5. Работает совместно с другими Скрам Мастерами для более эффективного использования Скрама в пределах организации.

- - - - - - - - -
Виртуализация. Виртуальные машины. Гипервизоры. Контейнеры.
- - - - - - - - -

Важность и применение виртуализации простирается далеко за пределы виртуальных машин. Ни одно из достижений в области информационных технологий не имело столь огромной ценности как виртуализация. Многие IT-специалисты думают о виртуализации с точки зрения виртуальных машин (VM) и связанных с ними гипервизоров и операционных систем, но это только вершина айсберга. Все более широкий спектр технологий, стратегий и возможностей виртуализации переопределяет основные элементы IT в организациях по всему миру.

https://smartiqa.ru/blog/virtualization

 - - - - - - - - -
Как войти в IT. Кем быть: тестировщиком или аналитиком?
- - - - - - - - -

Сфера IT стремительно развивается. Это, пожалуй, одна из сфер бизнеса, которая за последние год-полтора не только не потеряла в доходе, а наоборот выросла. Хотели бы начать работать в IT сфере?
В этом видео автор расскажет о двух профессиях, с которых проще всего начать свой путь в мире IT.

Сравнит профессии тестировщиков и аналитиков, посмотрит требования к начинающим специалистам на примере вакансий крупных компаний, рассмотрим потенциальный карьерный рост в каждой из этих профессий.

https://www.youtube.com/watch?v=WfjHcgdaMzs&list=WL&index=66

https://www.youtube.com/watch?v=WfjHcgdaMzs

 Вопрос №29

Q: Какие SCRUM мероприятия вы знаете?
A: Четко установленные мероприятия используются в Скраме для того, чтобы придать процессу разработки регулярность и минимизировать потребность в совещаниях, не предписанных Скрамом. Скрам использует ограниченные по времени мероприятия, поэтому каждое мероприятие имеет свой верхний предел продолжительности. Это гарантирует, что планирование будет проводиться в предназначенное время, не позволяя потерь времени в процессе планирования.

Кроме главного мероприятия, собственно самого Спринта, который включает все остальные мероприятия, каждое мероприятие Скрама является возможностью что-то проверить и провести адаптацию чего-нибудь. Такие мероприятия являются специально разработанными для обеспечения необходимой прозрачности и контроля.
И все-таки что же такое Спринт?

Спринт является сердцем Скрама. Это промежуток времени длиной в один месяц или менее, в результате которого создается ценный и потенциально “готовый” к выпуску Инкремент продукта.

Длина Спринта является постоянной на протяжении всего периода разработки. Следующий Спринт начинается сразу же по окончании предыдущего.

Во время Спринта:
1. Не допускается внесение никаких изменений, которые бы повлияли на Цель Спринта (Sprint Goal).
2. Состав Команды Разработчиков и цели по качеству продукта остаются неизменными.
3. Границы, в пределах которых ведется разработка в Спринте, могут быть уточнены и повторно обговорены между Владельцем Продукта и Командой Разработчиков по мере большего понимания.

В течение Спринта регулярно проводятся следующие мероприятия(Meetings):
1. Планирования Спринта(Sprint Planning);
2. Ежедневные Скрамы(Standups);
3. Обзоры Спринта(Sprint Review);
4. Ретроспективы Спринта(Sprint Retrospective).