Прагматичный  подход к документированию Веб-проектов Анатолий Филин Грамант
О чем   доклад? <ul><li>Факторы влияющие на выбор документов </li></ul><ul><ul><li>Роли и документы </li></ul></ul><ul><ul...
Откуда ноги растут? Научные библиотеки для российского суперкомпьютера Векторный Фортран, векторный ассемблер .  Несколько...
Набор документов =  F( команда ,  проект ) Процесс разработки ?
Роли и документы Концепция системы Бизнес- требования Требования  к архитектуре или  Список фич Функциональные требования ...
Куча артефактов <ul><li>Бизнес-план: Рынок, Цели проекта, этапы, экономика </li></ul><ul><li>Концепция системы ( Vision) :...
Требования:Бизнес  vs  функциональные <ul><li>Может ли задача перейти из состояния «завершена» в состояние «не начата»? </...
Роли и документы Бизнес-требования   Функциональные требования Системный аналитик Видение,  Бизнес-требования Бизнес-анали...
Роли и документы  2 Функциональные требования  Требования к инфраструктуре Системный администратор Бизнес-требования  Маке...
При чем здесь Веб? <ul><li>Б о льшая часть проектов – интерфейсные (широкие, оболочечные) </li></ul><ul><li>Много проектов...
Существенные параметры <ul><li>Проект: </li></ul><ul><li>Глубина  vs  ширина </li></ul><ul><li>Размер и длительность проек...
Проект: глубина  vs  ширина
Проект: глубина - ширина - размер
Команда: география Инвестор Разработчики Заказчик PM Дизайнер
Очевидные правила <ul><li>Если нужна грубая оценка, делаем бизнес-требования ,  если нужна точная оценка – делаем функцион...
А теперь – мастер-класс! <ul><li>Берем ситуацию,  </li></ul><ul><li>обсуждаем и решаем, </li></ul><ul><li>какая нужна доку...
Проект: корпоративный <ul><li>Внутренний заказчик </li></ul><ul><li>Монолитная команда </li></ul><ul><li>Небольшой проект:...
Проект: старт-ап <ul><li>Инвестиционный проект </li></ul><ul><li>Внутренняя команда разработчиков </li></ul><ul><li>Внешни...
Проект: заказная разработка <ul><li>Внешний заказчик </li></ul><ul><li>Полная команда </li></ul><ul><li>Средний проект: 20...
А что если  Agile ? stories итерации Текущий срез системы
Сухой остаток <ul><li>Выбор документов =  F( проект, команда) </li></ul><ul><li>Будьте гуманными: не заставляйте пользоват...
Вопросы ? [email_address] http://www.gramant.ru
Upcoming SlideShare
Loading in …5
×

Прагматичный подход к документированию Веб-проектов

1,264 views

Published on

Pragmatic approach to documenting Web projects. Talk at RIT conference, April 2010.
Речь идет о документировании процесса разработки Веб-систем. В работе над проектом как правило участвует команда, состоящая из специалистов разных областей: инвесторы, владельцы бизнеса, бизнес-менеджеры, аналитики, разработчики, юзабилисты, дизайнеры, тестировщики, системные администраторы. Эти специалисты обладают разным опытом, имеют разные цели и говорят на разных языках (причем часто – в прямом смысле этого слова). Некоторые роли могут отсутствовать, другие роли могут «склеиваться».

Существует достаточно развитая культура документирования проектов, которая включает как традиционные артефакты: видение (vision), бизнес-требования (BRD), функциональные требования (FRD), требования к интерфейсу, технические и архитектурные требования (TAD), требования к тестированию, требования к инфраструктуре, так и аджайльные артефакты: пользовательские истории (user stories), визуальные истории (visual stories).

Все Веб-проекты разные: интерфейсные проекты и проекты со сложной логикой (финансовые, научные), средние по размеру проекты и крупные проекты, проекты, которые пишутся с нуля и унаследованные от других разработчиков. Кроме того заказчики могут предъявлять разные требования к документированию: кому-то достаточен список характеристик, кто-то требует детальные функциональные требования, кто-то готов «идти в Agile». Команды тоже бывают разные: полные (свои аналитики, дизайнеры и т.д), локальные и распределенные.

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

Published in: Technology, Business
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,264
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Прагматичный подход к документированию Веб-проектов

  1. 1. Прагматичный подход к документированию Веб-проектов Анатолий Филин Грамант
  2. 2. О чем доклад? <ul><li>Факторы влияющие на выбор документов </li></ul><ul><ul><li>Роли и документы </li></ul></ul><ul><ul><li>Проекты и команды </li></ul></ul><ul><li>Простые правила выбора документов </li></ul><ul><li>Сделай сам: прагматичный выбор документов </li></ul>
  3. 3. Откуда ноги растут? Научные библиотеки для российского суперкомпьютера Векторный Фортран, векторный ассемблер . Несколько человеко-лет Трейдинговые системы. IT отдел корпорации. С, С++, Perl5. 3-10 человеко- лет Система онлайновой рекламы. Изначально - старт-ап. ColdFusion, Java. 50-100 человеко-лет Заказные проекты. Java , PHP, Grails. 5 –20 человеко-месяцев
  4. 4. Набор документов = F( команда , проект ) Процесс разработки ?
  5. 5. Роли и документы Концепция системы Бизнес- требования Требования к архитектуре или Список фич Функциональные требования Макеты экранов Риски Требования к инфраструктуре Тест-план Бизнес-план
  6. 6. Куча артефактов <ul><li>Бизнес-план: Рынок, Цели проекта, этапы, экономика </li></ul><ul><li>Концепция системы ( Vision) : 1-2 стр, с высоты птичьего полета </li></ul><ul><li>Набор фич (Features list) : Что должна делать система по фичам </li></ul><ul><li>Бизнес-требования: Что? 5-20 страниц </li></ul><ul><li>User stories (Agile) </li></ul><ul><li>Функциональные требования: Как? 20-100 страниц </li></ul><ul><li>Список рисков </li></ul><ul><li>Технические и архитектурные требования </li></ul><ul><li>Эскизы или макеты экранов </li></ul>
  7. 7. Требования:Бизнес vs функциональные <ul><li>Может ли задача перейти из состояния «завершена» в состояние «не начата»? </li></ul><ul><li>Какой может быть интервал повторения (выбор, произвольный) </li></ul><ul><li>Если задача периодическая, как задается количество повторений? </li></ul>Уровень бизнес-требований : Добавить задачу Просмотреть список задач Задача может периодически повторяться Уровень функциональных требований:
  8. 8. Роли и документы Бизнес-требования Функциональные требования Системный аналитик Видение, Бизнес-требования Бизнес-аналитик Концепция Бизнес-требования или набор фич Функциональные требования, Макеты экранов Заказчик ( Business owner) Бизнес-план Концепция системы Бизнес-требования Инвестор
  9. 9. Роли и документы 2 Функциональные требования Требования к инфраструктуре Системный администратор Бизнес-требования Макеты экранов Проектировщик интерфейсов Функциональные требования Требования к тестированию Тестировщик Функциональные требования технические требования Разработчик
  10. 10. При чем здесь Веб? <ul><li>Б о льшая часть проектов – интерфейсные (широкие, оболочечные) </li></ul><ul><li>Много проектов, которые копируют другие известные проекты </li></ul><ul><li>Широкое использование API, других готовых строительных блоков </li></ul><ul><li>Распределенные команды чаще, чем для десктопных приложений </li></ul>
  11. 11. Существенные параметры <ul><li>Проект: </li></ul><ul><li>Глубина vs ширина </li></ul><ul><li>Размер и длительность проекта </li></ul><ul><li>Внутренний или заказной (доверие + точность бюджета) </li></ul><ul><li>Новизна проекта </li></ul><ul><li>Требуемая точность оценки </li></ul><ul><li>Использование готовых блоков </li></ul><ul><li>Команда: </li></ul><ul><li>Полнота команды (свои дизайнеры, аналитики и т.д.) </li></ul><ul><li>Географическая распределенность </li></ul>
  12. 12. Проект: глубина vs ширина
  13. 13. Проект: глубина - ширина - размер
  14. 14. Команда: география Инвестор Разработчики Заказчик PM Дизайнер
  15. 15. Очевидные правила <ul><li>Если нужна грубая оценка, делаем бизнес-требования , если нужна точная оценка – делаем функциональные требования </li></ul><ul><li>Если проектировщик интерфейсов вне команды, нужно задание для проектировщика, либо функциональные требования </li></ul><ul><li>Если проект «интерфейсный» достаточно бизнес-требований и макетов экранов </li></ul><ul><li>Если проект «глубокий» нужна аналитика и соответственно функциональные требования </li></ul>
  16. 16. А теперь – мастер-класс! <ul><li>Берем ситуацию, </li></ul><ul><li>обсуждаем и решаем, </li></ul><ul><li>какая нужна документация </li></ul>
  17. 17. Проект: корпоративный <ul><li>Внутренний заказчик </li></ul><ul><li>Монолитная команда </li></ul><ul><li>Небольшой проект: 3-5 ч/м </li></ul><ul><li>Бизнес-требования </li></ul><ul><li>Экраны </li></ul>Условия: Артефакты?
  18. 18. Проект: старт-ап <ul><li>Инвестиционный проект </li></ul><ul><li>Внутренняя команда разработчиков </li></ul><ul><li>Внешние проектировщики интерфейса </li></ul><ul><li>Средний размер: 15-20 ч/м </li></ul>Условия: <ul><li>Концепция системы </li></ul><ul><li>Бизнес-требования </li></ul>Артефакты? <ul><li>Задание для дизайнера </li></ul><ul><li>Экраны </li></ul>
  19. 19. Проект: заказная разработка <ul><li>Внешний заказчик </li></ul><ul><li>Полная команда </li></ul><ul><li>Средний проект: 20 ч/м </li></ul><ul><li>Удаленный дизайнер </li></ul><ul><li>Бизнес-требования </li></ul><ul><li>Функциональные требования </li></ul><ul><li>Риски </li></ul><ul><li>Макеты экранов </li></ul><ul><li>Технические требования </li></ul>Условия: Артефакты?
  20. 20. А что если Agile ? stories итерации Текущий срез системы
  21. 21. Сухой остаток <ul><li>Выбор документов = F( проект, команда) </li></ul><ul><li>Будьте гуманными: не заставляйте пользователей читать лишнее и тем более - писать лишнее </li></ul>
  22. 22. Вопросы ? [email_address] http://www.gramant.ru

×