В последние годы внедрение agile-методологий в разработку ПО стало целой индустрией: по этой теме выпускается специальная литература, собираются тематические конференции, устраиваются тренинги. На рынке труда возникли совершенно новые профессии, такие как agile-коуч или скрам-мастер. Появились целые компании, которые специализируются на внедрении гибких методологий в других компаниях.

В таких условиях кажется совершенно логичным заказать внешний консалтинг и «призвать» в свою компанию профессионального скрам-мастера на несколько месяцев. И это идеальный случай, просто мечта.

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

В таких условиях у разработчика есть два пути: продолжать терпеть или брать инициативу в свои руки.

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

Представляю вам серию из двух постов, где я постараюсь рассказать о разработке довольно типового решения VDI для предприятия среднего размера. В первой части – подготовка к внедрению, планирование; во второй – реальные практически примеры.

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

Например, у одного из заказчиков, крупной отечественной софтверной компании, имеется довольно большой парк серверов и систем хранения. В том числе — несколько серверов HP ProLiant 6-го и 7-го поколения и система хранения HP EVA, которые были в резерве. Именно на их базе нужно было разработать решение.
Озвученными требованиями к решению VDI были:

• Floating Desktops Pool (с сохранением изменений после окончания сессии);
• Начальная конфигурация — 700 пользователей, с расширением до 1000.

Мне предстояло просчитать какое количество серверов и систем хранения в итоге перейдут из резерва в состав решения.
В качестве среды виртуализации выбрана VMware. Схема работы получилась примерно такая:

Это продолжение серии из двух постов, в которых я рассказываю о построении VDI-решения для крупной российской софтверной компании. Первый пост здесь.

Немного математики

Опираясь на описанную в предыдущем посте теорию, проведем расчеты:

Одновременно от 6 до 9 пользователей VDI могут использовать одно физическое ядро CPU. Для упрощения возьмем среднюю цифру — 7 пользователей.

Согласно требованиям заказчика необходимо обеспечить работу 700 пользователей по VDI с расширением до 1000.