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

3. Любой интернет-проект может стать высоконагруженным.

4. Больше 1m хитов?

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

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

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

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

10. Как нужно нанимать разработчиков? Групповое собеседование. Начинаем собеседование с написания кода. На собеседовании спрашивайте только то, что вам точно нужно. Тратьте на собеседование достаточно времени. Помните, отличники нанимают отличников – а хорошисты троечников.

11. Команда Все разработчики хотят разрабатывать (но хотят ли они разрабатывать для Вас?). Все разработчики хотят уважения и признания их заслуг в реализации проекта. Разработчики любят чувство ответственности и «собственности» своего куска программного кода. Руководитель команды должен быть наиболее авторитетным сотрудником. Прозрачность в принятии решений. Открытые коммуникации.

12. Роли в IT команде IT-manageream leader: играющий тренер, знает кто что делает, почему сейчас и «когда будет готово». Архитектор: привносит новые технологические идеи в команду, работает со сложными задачами (реализация практического R&D). Разработчик – боевая единица, полностью ответственная за качественный и временной результат. Администратортветственный за production – человек необходимый для связи разработчиков с реальностью. Тестеры –группа пользователей имеющая возможность общаться с разработчиками напрямую.

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

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

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

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

22. Процесс разработки Есть команда? Есть ТЗ? – Самое время для определения последовательности этапов. IT Manager Product Manager Планирование должно быть осуществлено на весь срок разработки проекта. Результатом каждого этапа должен являться визуальный результат.

23. Процесс разработки Дробим на минимальные кванты не длиннее недели. Результат работы над каждым квантом – развертывание. Разрешайте разработчикам выбирать задачи. Боритесь с расслоением команды. Обсуждайте сложности. Не начинайте разработку пока есть нерешенные вопросы.

24. Что получилось хорошо? Что получилось плохо? Почему? Ежедневная встреча всех участников проекта. Не более 15 минут. Кто и что делает? Какие проблемы существуют? Выбор задач на текущую неделю Развертывание + Еженедельное Обсуждение Результатов Каждая еженедельная разработка должна заканчиваться развертыванием.

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

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

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

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

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

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

35. Если у Вас нет вопросов, то я повторю презентацию. Владимир Габриелян. gabrelyan@corp.mail.ru