Developmentmanage1.0

3,597 views

Published on

1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total views
3,597
On SlideShare
0
From Embeds
0
Number of Embeds
3,150
Actions
Shares
0
Downloads
81
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

Developmentmanage1.0

  1. 1. Управление разработкой высоконагруженных проектов<br />
  2. 2. В чем особенность разработки высоконагруженных интернет-проектов?<br /><ul><li>Больше 10 серверов?
  3. 3. Любой интернет-проект может стать высоконагруженным.
  4. 4. Больше 1m хитов?
  5. 5. Больше 5 разработчиков?
  6. 6. Интернет-быстро меняющаяся среда в которой от команды требуется исключительная гибкость.
  7. 7. Высоконагруженные интернет-проекты должны быть беспредельно масштабируемы в любом узком месте.</li></li></ul><li>Из чего состоит разработка?<br />Самая важная часть процесса разработки – люди, а вовсе не технологии. <br /><ul><li>Команда</li></ul>Определяет технологические решения. <br />Определяют стоимость и качество продукта.<br /><ul><li>Технологии
  8. 8. Менеджмент и планирование</li></ul>Определяет мотивацию и ответственность.<br />
  9. 9. С чего начинается разработка?<br />С подробного технического задания?<br />С разработки методик тестирования?<br />С выбора технологий?<br />С поиска и найма команды!<br />Выберите группу лучших разработчиков и заставьте их искать себе подобных. <br />
  10. 10. Как нужно нанимать разработчиков?<br />Групповое собеседование.<br />Начинаем собеседование с написания кода.<br />На собеседовании спрашивайте только то, что вам точно нужно.<br />Тратьте на собеседование достаточно времени.<br />Помните, отличники нанимают отличников – а хорошисты троечников.<br />
  11. 11. Команда<br />Все разработчики хотят разрабатывать (но хотят ли они разрабатывать для Вас?). <br />Все разработчики хотят уважения и признания их заслуг в реализации проекта.<br />Разработчики любят чувство ответственности и «собственности» своего куска программного кода.<br />Руководитель команды должен быть наиболее авторитетным сотрудником. <br />Прозрачность в принятии решений.<br />Открытые коммуникации.<br />
  12. 12. Роли в IT команде<br />IT-managerTeam leader: играющий тренер, знает кто что делает, почему сейчас и «когда будет готово».<br />Архитектор: привносит новые технологические идеи в команду, работает со сложными задачами (реализация практического R&D).<br />Разработчик – боевая единица, полностью ответственная за качественный и временной результат.<br />Администраторответственный за production – человек необходимый для связи разработчиков с реальностью.<br />Тестеры –группа пользователей имеющая возможность общаться с разработчиками напрямую.<br />
  13. 13. Выбор технологии<br />НЕТ!<br />-«Я слышал, что это работает.»<br /><ul><li>«По тестам журнала “Линуксоид и Ко” эта база самая быстрая.»
  14. 14. «Нам нужен всего лишь сервер помощнее.»</li></ul>ДА!<br />- «Эта технология знакома нашей команде.»<br /><ul><li>«Я знаю людей которые придут и разработают эту часть проекта.»
  15. 15. «Эта технология позволит нам поставить столько серверов, сколько нам нужно.»</li></li></ul><li>Проектирование<br />Принимает участие вся команда от PM до бета-тестеров.<br />По каждому этапу должны быть найдены ответы на вопросы: <br />Как мы будем масштабировать нагрузку?<br />Как мы можем применить что-то из уже существующего кода?<br />Как мы будем использовать это в последующих разработках?<br />Кто из команды лучше всего разбирается в этом вопросе Кто будет это делать?<br />Когда мы это сделаем?<br />
  16. 16. Инструментарий<br /><ul><li>Тасктрекер – «память» проекта.
  17. 17. Система контроля версий – версификация и развертывание.
  18. 18. Радар – задачи в работе.
  19. 19. «Список Идей» - позволяет коллекционировать идеи на будущее.
  20. 20. «Wiki» - для документации.
  21. 21. «Средство учета времени» – self-test IT-менеджера.</li></li></ul><li>Процесс разработки<br />Нужно ли техническое задание?<br />ДА!<br />Длинна проекта &gt;месяца.<br />Работает несколько команд.<br />Есть удаленные команды.<br />Есть outsource разработчики.<br />НЕТ!<br />Короткий проект.<br />Проект, который уже делали.<br />Маленькая команда.<br />Лучшее тех.задание – работающий макет.<br />
  22. 22. Процесс разработки<br />Есть команда? Есть ТЗ? – Самое время для определения последовательности этапов.<br />IT Manager<br />Product Manager<br />Планирование должно быть осуществлено на весь срок разработки проекта. Результатом каждого этапа должен являться визуальный результат.<br />
  23. 23. Процесс разработки<br />Дробим на минимальные кванты не длиннее недели.<br />Результат работы над каждым квантом – развертывание.<br />Разрешайте разработчикам выбирать задачи.<br />Боритесь с расслоением команды.<br />Обсуждайте сложности.<br />Не начинайте разработку пока есть нерешенные вопросы.<br />
  24. 24. Что получилось хорошо?<br />Что получилось плохо?<br />Почему?<br />Ежедневная встреча всех участников проекта.<br />Не более 15 минут.<br />Кто и что делает?<br />Какие проблемы существуют?<br />Выбор задач на текущую неделю<br />Развертывание<br /> +<br />Еженедельное<br />Обсуждение <br />Результатов<br />Каждая еженедельная разработка должна заканчиваться развертыванием. <br />
  25. 25. Тестирование<br />Нужно ли выделенное подразделение тестеров в интернет-проекте?<br /><ul><li>Нагрузочное тестирование - за разработчиком.
  26. 26. Системное тестирование - за проектным менеджером.
  27. 27. Функциональное тестирование – за автоматизированным ПО.
  28. 28. Финальное тестирование - за группой пользователей-бетатестеров.</li></ul>Если вы не можете найти пользователей, которые хотят протестировать ваш продукт – подумайте стоит ли делать такой продукт.<br />
  29. 29. Что, если…<br />Произошел сдвиг сроков: <br /><ul><li>Обязательно обсудите со всей командой видение причин сдвига сроков. (причины могут быть как в ошибочной оценке, так и в дополнительных задачах).
  30. 30. Назначьте и зафиксируйте новые сроки, не пытайтесь сделать невозможного – это выльется в низкое качество проекта.
  31. 31. Не злоупотребляйте овертаймом, помните, что каждый человек может эффективно работать строго ограниченное количество времени (а находиться на работе он может намного больше).</li></li></ul><li>Что, если…<br />ИзменилосьТЗ:<br /><ul><li>Обсудите с командой изменение ТЗ, объясните почему это произошло.
  32. 32. Выберите что из уже реализованного ПО можно использовать в новой задаче.
  33. 33. Всегда лучше закончить текущую разработку, а потом начать следующую, чем переключиться в процессе разработки на новую задачу – цена переключения очень велика.
  34. 34. Даже мелкие изменения ТЗ – меняют сроки, не забывайте менять срок готовности в плане разработки.</li></li></ul><li>Слово о развертывании в production.<br />Развертывание – это еще и этап тестирования.<br />Все развертывание должно быть полностью автоматизировано.<br />«Боевое» и тестовое развертывание с помощью одних и тех же утилит. <br />Развертывание – дело группы эксплуатации.<br />Развертывание - только из системы контроля версий.<br />
  35. 35. Если у Вас нет вопросов, то я повторю презентацию.<br />Владимир Габриелян. <br />gabrelyan@corp.mail.ru<br />

×