Разработка веб-сервисов осень 2013 лекция 3

259 views

Published on

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
259
On SlideShare
0
From Embeds
0
Number of Embeds
26
Actions
Shares
0
Downloads
15
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Разработка веб-сервисов осень 2013 лекция 3

  1. 1. Разработка веб-сервисов Беседа 3: Техническое задание
  2. 2. План занятия  Принципы создания технического задания  Сбор требований, необходимость и достаточность  Согласование ТЗ и его изменений.  Дрейф требований  Декомпозиция технического задания  Оценка сроков выполнения задач, принципы оценки 2
  3. 3. Этапы создания проекта Этапы: 1. Анализ предметной области и постановка задачи 2. Проектирование, уточнение ТЗ 3. Разработка 4. Анализ разработанного продукта (ревью, тесты) 5. Ввод в эксплуатацию 3
  4. 4. Зачем нужно ТЗ  Разработка — сложная и длительная работа  Заказчик и исполнитель говорят на разных языках Все, что может быть понято не так, будет именно не так и понято  ТЗ — инструмент коммуникаций  ТЗ позволяет увеличить шансы на успех 4
  5. 5. Примеры ТЗ «Экран оплатить, выбор источника средств, если привязано меньше 2 карт, то предлагать привязать» Формальное решение:  проверить, сколько карт у пользователя (1строка кода)  отобразить модальное всплывающее окно с вопросом о привязке карты (1 строка кода).  обработать результат и направить пользователя на экран регистрации новой карты в текущем стеке навигации (4 строки кода) Общее время выполнения задачи: 15 минут, 6 строк кода 5
  6. 6. Примеры ТЗ «Экран оплатить, выбор источника средств, если привязано меньше 2 карт, то предлагать привязать» Что хотел менеджер:  На форме оплаты в селекторе выбора способа оплаты, при наличии у пользователя менее двух привязанных карт, добавить дополнительную опцию (привязать новую карту).  Реализация: проверка наличия карты и создание опции в селекторе выбора, добавление логики в обработчик событий селектора, реализация логики переключения между вкладками в правильный таб для регистрации новой карты Общее время выполнения задачи: 2.5 часа, 40 строк кода 6
  7. 7. Зачем нужно ТЗ ТЗ позволяет заказчику и исполнителю  Осознать, как будет выглядеть результат работ  Уменьшить число ошибок и несоответствий  Проверить результат в соответствии с исходными требованиями  Управлять изменениями во время разработки 7
  8. 8. Зачем нужно ТЗ ТЗ позволяет заказчику  Спланировать ход работ, понять когда будут результаты  Определить затраты  Контролировать ход работ  Требовать соответствия всем условиям ТЗ 8
  9. 9. Зачем нужно ТЗ ТЗ позволяет исполнителю  Понять суть задачи и показать заказчику как будет выглядеть результат  Оценить трудозатраты и потребности в ресурсах  Спланировать работы согласно принятым практикам  Отказаться от части работ, не попавших в ТЗ 9
  10. 10. Материалы для ТЗ  Наглядность повышает понимание  Одна диаграмма заменяет несколько страниц текста  «Много букав? Ниасилил!»  Эскизы, скриншоты, прототипы 10
  11. 11. Материалы для ТЗ  Документация  Приложите в таск!  Ведите учет!  Опишите сценарий!  Контакты специалистов  Кто заказчик?  Кто из сотрудников может помочь?  К кому обращаться за консультацией? 11
  12. 12. Особенности создания ТЗ ТЗ — совместный труд заказчика и исполнителя  Заказчик знает предметную область  Исполнитель знает технические особенности  Оба — координируют поступление информации 12
  13. 13. Особенности создания ТЗ ТЗ — лучше говорить, чем писать  Трудности понимания акцентов  Скорость обсуждения выше  Прочитал – повторил - понял 13
  14. 14. Особенности создания ТЗ ТЗ — лучше писать, чем говорить  Нюансы могут забываться  ТЗ можно использовать как документацию  Обсудил голосом? Напиши резюме! 14
  15. 15. Этапы создания ТЗ  Сбор информации  Анализ и обработка информации  Написание документа  Согласование документа с участниками 15
  16. 16. Разделы ТЗ  Описание целей разработки и решаемых задач  Описание функциональных требований  Описание процесса запуска  Описание сроков и затрат 16
  17. 17. Разделы ТЗ  Описание целей разработки и решаемых задач  Зачем всё это?  Описание ключевых особенностей  Описание ограничений  Описание границ ответственности 17
  18. 18. Разделы ТЗ  Описание функциональных требований  Требования к системе в целом  Описание компонентов и взаимодействие между ними  Требования к отдельным компонентам 18
  19. 19. Разделы ТЗ  Описание процесса запуска  Что и как будет проверяться  Какова последовательность работ  Как определяется, что работа сделана успешно 19
  20. 20. Разделы ТЗ  Описание сроков и затрат  План-график работ  Необходимые затраты  Зависимости от внешних условий 20
  21. 21. Согласование ТЗ  Необходимые требования  Дрейф требований  waterfall  agile 21
  22. 22. Декомпозиция задачи Цели декомпозиции  Снижение неопределенности  Повышение качества анализа предметной области  Повышение качества оценки затрат  Улучшение распределения ресурсов  Расстановка приоритетов 22
  23. 23. Декомпозиция задачи Как декомпозировать?  Разные компоненты — разные задачи  Излишняя декомпозиция — зло  Размер подзадачи зависит от методологии  Задача не должна быть длиннее итерации  От 3-4 часов до 1-3 дней 23
  24. 24. Оценка сроков выполнения Оценка времени  Позволяет оценивать необходимые ресурсы  Позволяет понимать прогресс по задачам  Нужно руководителю разработки  Нужно руководителю проекта 24
  25. 25. Оценка сроков выполнения Методы оценки  «На глаз»  Совместная оценка  Учет, статистика и анализ 25
  26. 26. Оценка сроков выполнения Совместная оценка  Вспоминаем Agile-методики  Привлекаем опытных разработчиков  Учитываем особенности исполнителя 26
  27. 27. Оценка сроков выполнения Учет и ретроспективный анализ  Типы задачи — ограниченное множество  В задачах можно вести учет затраченного времени  Для повторяющихся задач видны закономерности 27
  28. 28. Оценка сроков выполнения Учет и ретроспективный анализ  Что учитывать?  Как систематизировать? 28
  29. 29. Оценка сроков выполнения Учет и ретроспективный анализ Учет времени. Сколько?  На любую задачу тратится время.  Занесение времени — почетная обязанность  Возможны погрешности  Мелкие задачи — точность 5-15 минут  Средние задачи — точность 15-30 минут  Большие задачи — точность 30-60 минут 29
  30. 30. Оценка сроков выполнения Учет и ретроспективный анализ Учет времени. Когда?  Сразу же?  Несколько раз в день?  Раз-два в неделю?  В конце недели? 30
  31. 31. Оценка сроков выполнения Учет и ретроспективный анализ Учет времени. Когда? 1. Всё зависит от методологии 2. Учёт в конце итерации не работает 31
  32. 32. Оценка сроков выполнения Учет и ретроспективный анализ Как систематизировать?  Каждой задаче — свой тип  Каждой задаче — свои метки 32
  33. 33. Оценка сроков выполнения Учет и ретроспективный анализ Метки 33
  34. 34. Оценка сроков выполнения Учет и ретроспективный анализ Метки 34
  35. 35. Оценка сроков выполнения Учет и ретроспективный анализ 35
  36. 36. Оценка сроков выполнения Учет и ретроспективный анализ 36
  37. 37. Оценка сроков выполнения Учет и ретроспективный анализ 37
  38. 38. Оценка сроков выполнения  Итог любого метода — приблизительная оценка затрат  Почему приблизительная? 38
  39. 39. Оценка сроков выполнения Оценка времени  Everybody lies © сами знаете кто  Все программисты — оптимисты © Брукс  Всё будет хорошо  Психология — дело тонкое  Не легко признаваться в ошибках 39
  40. 40. Оценка сроков выполнения Оценка времени  Не учитываются затраты на  Проектирование  Тестирование и ревью 40
  41. 41. Оценка сроков выполнения Оценка времени  Не учитывается обмен данными  Попарное общение сотрудников  Общие совещания  Не учитывается переключение контекста 41
  42. 42. Оценка сроков выполнения Оценка времени  Не учитывается передача знаний  Цели  Особенности  Технологии  План работ 42
  43. 43. Оценка сроков выполнения Оценка времени  Что делать?  Оценивать и улучшать качество оценки 43
  44. 44. Резюме  Качество технического задания – качество продукта  Задачи меняются. И будут меняться всегда  Верить нельзя никому. Особенно разработчику  «Анализируй это» 44
  45. 45. Отчетность Домашнее задание создание технического задания, в котором прописано:  что должен из себя представлять проект в целом  описаны компоненты  описаны основные функции проекта  описаны интерфейсы (сделан прототип)  описаны сценарии использования 45
  46. 46. Вопросы? Максим Бабич tpark@maxbabich.ru +7 916 9415275

×