developmentmanage1.0

19
Управление разработкой высоконагруженных проектов

Upload: highload2009

Post on 16-Jun-2015

3.455 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: Developmentmanage1.0

Управление разработкой высоконагруженных проектов

Page 2: Developmentmanage1.0

В чем особенность разработки высоконагруженных интернет-проектов?

• Больше 1m хитов?• Любой интернет-проект может стать высоконагруженным.

• Интернет - быстро меняющаяся среда в которой от команды требуется исключительная гибкость.

• Больше 10 серверов?

• Больше 5 разработчиков?

• Высоконагруженные интернет-проекты должны быть беспредельно масштабируемы в любом узком месте.

Page 3: Developmentmanage1.0

Из чего состоит разработка?

Определяет технологические решения.

Определяют стоимость и качество продукта.

Определяет мотивацию и ответственность.

• Команда

• Технологии

• Менеджмент и планирование

Самая важная часть процесса разработки – люди, а вовсе не технологии.

Page 4: Developmentmanage1.0

С чего начинается разработка?С подробного технического задания?

С разработки методик тестирования?

С выбора технологий?

С поиска и найма команды!

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

Page 5: Developmentmanage1.0

Как нужно нанимать разработчиков?

Групповое собеседование.

Начинаем собеседование с написания кода.

На собеседовании спрашивайте только то, что вам точно нужно.

Тратьте на собеседование достаточно времени.

Помните, отличники нанимают отличников – а хорошисты троечников.

Page 6: Developmentmanage1.0

КомандаВсе разработчики хотят разрабатывать (но хотят ли они разрабатывать для Вас?).

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

Разработчики любят чувство ответственности и «собственности» своего куска программного кода.

Руководитель команды должен быть наиболее авторитетным сотрудником.

Прозрачность в принятии решений.

Открытые коммуникации.

Page 7: Developmentmanage1.0

Роли в IT командеIT-manager\Team leader: играющий тренер, знает кто что делает, почему сейчас и «когда будет готово».

Архитектор: привносит новые технологические идеи в команду, работает со сложными задачами (реализация практического R&D).

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

Администратор \ ответственный за production – человек необходимый для связи разработчиков с реальностью.

Тестеры – группа пользователей имеющая возможность общаться с разработчиками напрямую.

Page 8: Developmentmanage1.0

Выбор технологии

НЕТ!- «Я слышал, что это работает.»- «По тестам журнала “Линуксоид и Ко” эта база самая

быстрая.»- «Нам нужен всего лишь сервер помощнее.»

ДА!- «Эта технология знакома нашей команде.»- «Я знаю людей которые придут и разработают эту часть

проекта.»- «Эта технология позволит нам поставить столько

серверов, сколько нам нужно.»

Page 9: Developmentmanage1.0

ПроектированиеПринимает участие вся команда от PM до бета-тестеров.

По каждому этапу должны быть найдены ответы на вопросы: 1. Как мы будем масштабировать нагрузку?2. Как мы можем применить что-то из уже существующего

кода?3. Как мы будем использовать это в последующих

разработках?4. Кто из команды лучше всего разбирается в этом вопросе \

Кто будет это делать?5. Когда мы это сделаем?

Page 10: Developmentmanage1.0

Инструментарий

• Таск трекер – «память» проекта.

• Система контроля версий – версификация и развертывание.

• Радар – задачи в работе.

• «Список Идей» - позволяет коллекционировать идеи на будущее.

• «Wiki» - для документации.

• «Средство учета времени» – self-test IT-менеджера.

Page 11: Developmentmanage1.0

Процесс разработки

ДА!

Длинна проекта >месяца.Работает несколько команд.Есть удаленные команды.Есть outsource разработчики.

НЕТ!

Короткий проект.Проект, который уже делали.Маленькая команда.

Нужно ли техническое задание?

Лучшее тех.задание – работающий макет.

Page 12: Developmentmanage1.0

Процесс разработкиЕсть команда? Есть ТЗ? – Самое время для определения последовательности этапов.

Планирование должно быть осуществлено на весь срок разработки проекта. Результатом каждого этапа должен являться визуальный результат.

2009 2010 2011 2011 2012 2013 2014 2015 2016 2017 2018

IT Manager Product Manager

Page 13: Developmentmanage1.0

Процесс разработки

Дробим на минимальные кванты не длиннее недели.

Результат работы над каждым квантом – развертывание.

Разрешайте разработчикам выбирать задачи.

Боритесь с расслоением команды. Обсуждайте сложности.

Не начинайте разработку пока есть нерешенные вопросы.

Page 14: Developmentmanage1.0

2009 2010 2011 2011 2012 2013 2014 2015 2016 2017 2018

Выбор задач

на текущую

неделю

Еженедельный план

Ежедневная встреча всех участников проекта.

Развертывание +ЕженедельноеОбсуждение Результатов

Не более 15 минут.Кто и что делает?Какие проблемы существуют?

Что получилось хорошо?Что получилось плохо?Почему?

Каждая еженедельная разработка должна заканчиваться развертыванием.

Page 15: Developmentmanage1.0

Тестирование

Нужно ли выделенное подразделение тестеров в интернет-проекте?

• Нагрузочное тестирование - за разработчиком.

• Системное тестирование - за проектным менеджером.

• Функциональное тестирование – за автоматизированным ПО.

• Финальное тестирование - за группой пользователей-бетатестеров.

Если вы не можете найти пользователей, которые хотят протестировать ваш продукт – подумайте стоит ли делать такой продукт.

Page 16: Developmentmanage1.0

Что, если…

Произошел сдвиг сроков: • Обязательно обсудите со всей командой видение причин сдвига сроков.

(причины могут быть как в ошибочной оценке, так и в дополнительных задачах).

• Назначьте и зафиксируйте новые сроки, не пытайтесь сделать невозможного – это выльется в низкое качество проекта.

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

Page 17: Developmentmanage1.0

Что, если…Изменилось ТЗ: • Обсудите с командой изменение ТЗ, объясните почему это произошло.

• Выберите что из уже реализованного ПО можно использовать в новой задаче.

• Всегда лучше закончить текущую разработку, а потом начать следующую, чем переключиться в процессе разработки на новую задачу – цена переключения очень велика.

• Даже мелкие изменения ТЗ – меняют сроки, не забывайте менять срок готовности в плане разработки.

Page 18: Developmentmanage1.0

Слово о развертывании в production.

Развертывание – это еще и этап тестирования.

Все развертывание должно быть полностью автоматизировано.

«Боевое» и тестовое развертывание с помощью одних и тех же утилит.

Развертывание – дело группы эксплуатации.

Развертывание - только из системы контроля версий.

Page 19: Developmentmanage1.0

Если у Вас нет вопросов, то я повторю презентацию.

Владимир Габриелян. [email protected]