Использование ICONIX для анализа требований в Scrum

4,464 views
4,285 views

Published on

Scrum, как управленческий фреймворк, достаточно бегло описывает вопросы сбора и особенно анализа требований, а методы моделирования продукта в нем фактически отсутствуют. Мы адаптировали процесс ICONIX ("подмножество" UML) для работы с требованиями в стиле Agile для распределенных команд, избавившись от "водопадных" потерь при разработке ПО. В докладе будет рассказано про структуру процесса ICONIX и наборе диаграмм, который применяется в нем для сбора и анализа требований. Мы сделали необходимый тюнинг процесса ICONIX, чтобы преодолеть вызовы, с которыми столкнулись (например, выбор политики актуализации модели и кода), и сделали его действительно гибким процессом, отлично сочетающимся с традиционными Agile-практиками.

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

No Downloads
Views
Total views
4,464
On SlideShare
0
From Embeds
0
Number of Embeds
1,723
Actions
Shares
0
Downloads
36
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Использование ICONIX для анализа требований в Scrum

  1. 1. Сбор и анализ требований в Scrum<br />Адаптация процесса ICONIX<br />Вольфсон Борис<br />Руководитель проектовРуководитель регионального отдела веб-разработки<br />Компания Softline<br />
  2. 2. Цели и содержания доклада<br /><ul><li>Среда использования
  3. 3. Описание процесса ICONIX
  4. 4. Диаграммыи процесс
  5. 5. Адаптация процесса ICONIX под Scrum/Agile
  6. 6. Потери при производстве
  7. 7. Синхронизация диаграмм и кода
  8. 8. Соответствие принципам Agile
  9. 9. Обсуждение и вопросы</li></li></ul><li>Среда использования Scrum и ICONIX<br /><ul><li>Компания Softline
  10. 10. Разработка высоконагруженных коммерческих сайтов:
  11. 11. Корпоративные веб-сайты
  12. 12. Веб-сайты для электронной коммерции
  13. 13. Около 100 основных участников проектов
  14. 14. Страны СНГ и дальнего зарубежья
  15. 15. Распределенная команда разработки
  16. 16. Москва, Новосибирск иОренбург</li></li></ul><li>Среда использования Scrum и ICONIX: Product Owner<br />
  17. 17. Сбор и анализ требований в Scrum<br /><ul><li>Создание и нормализация видения продукта
  18. 18. Выявление и описание персонажей
  19. 19. Создание юзер-стори
  20. 20. Как «персонаж», я «действие» для «цель»
  21. 21. Описания юзер-стори хранятся в виде «знаний» команды
  22. 22. Для распределенных командудобно использовать вики</li></li></ul><li>Сбор и анализ требований в Scrum<br />
  23. 23. Как мы понимаем Scrum<br />
  24. 24. Полная UML<br /><ul><li>Большой входной порог
  25. 25. Более 10 видов диаграмм
  26. 26. 900-страничное руководство
  27. 27. Слишком подробное описание
  28. 28. Неявная «Водопадная модель»
  29. 29. Избыточность
  30. 30. Необходимость постоянной актуализации диаграмм</li></li></ul><li>Потери при производстве: UML<br /><ul><li>Перепроизводство
  31. 31. Ожидание
  32. 32. Переключение между задачами
  33. 33. Лишние этапы обработки
  34. 34. Лишние запасы
  35. 35. Ненужные перемещения сотрудников
  36. 36. Дефекты</li></li></ul><li>Что такое ICONIX?<br />
  37. 37. ICONIX подмножество UML<br />
  38. 38. Классическая схема процесса ICONIX<br />Динамика<br />Вариантыиспользования<br />ПротипUI<br />Последовательность<br />Сценариитестирования<br />Робастность<br />Статика<br />Код<br />Предметнаяобласть<br />Обновления предметной области<br />Классы<br />
  39. 39. Диаграмма предметной области<br />
  40. 40. Диаграмма классов<br />
  41. 41. Диаграмма вариантов использования<br />Марья Васильевна как пользователь читает справку, чтобы понять, как использовать систему<br />
  42. 42. Диаграмма робастности<br />
  43. 43. Зачем нужна диаграмма робастности?<br /><ul><li>Проверка полноты юзкейсов
  44. 44. Выявление дополнительных объектов
  45. 45. Проверка текста юзкейсов
  46. 46. Предварительная проработка архитектуры
  47. 47. «Мост» между анализом и архитектурой</li></li></ul><li>Зачем нужна диаграмма робастности?<br />Пропасть<br />Как?<br />(архитектура)<br />Что?(анализ)<br />
  48. 48. Диаграмма последовательности<br />
  49. 49. Практики процесса ICONIX<br /><ul><li>Анализ и уточнение требований
  50. 50. Системный аналитик для Product owner’а
  51. 51. Уменьшение количества неправильных требований
  52. 52. Анализ предметной области
  53. 53. Проектирование взаимодействия с системой
  54. 54. Префакторинг – рефакторинг модели
  55. 55. Синхронизация моделей и кода
  56. 56. Агрессивное тестирование на всех уровнях</li></li></ul><li>Проектирование взаимодействия с системой<br />
  57. 57. Возвращение к водопадной модели?<br />Классический ICONIX:<br /><ul><li>Близок к водопадной модели
  58. 58. Допускает потери при производстве
  59. 59. Перепроизводство - проработка лишних требований
  60. 60. Лишняя обработка - актуализация диаграмм
  61. 61. Лишние запасы – проработка всей модели</li></ul>… но ICONIX отлично адаптируется к Agile<br />
  62. 62. Варианты политик синхронизации диаграмм и кода<br /><ul><li>Актуализация – это потери!
  63. 63. Полная или частичная синхронизация
  64. 64. «Внешние разработчики»
  65. 65. Распределенная команда
  66. 66. Поддержка продукта
  67. 67. Части продукта для синхронизации
  68. 68. Основной функционал
  69. 69. Взаимодействие с внешними системами</li></li></ul><li>Различия между моделью и кодом<br />Количество различий<br />Модель<br />Код<br />Время<br />
  70. 70. Подводное плавание - метафора содержания проекта<br />Размер/рамки проекта<br />Общее описание системы и архитектура<br />Спринт №4<br />Спринт №1<br />Спринт №2<br />Спринт №3<br />Спринт №1<br />Спринт №2<br />Детализация проекта<br />Спринт №3<br />Спринт №4<br />
  71. 71. Нулевой спринт – плаваем на поверхности<br /><ul><li>Видение продукта
  72. 72. Диаграмма предметной области
  73. 73. Диаграмма вариантов использования
  74. 74. Роли и персонажи
  75. 75. Юзер-стори без описания
  76. 76. Проработка юзер-стори для первого спринта</li></ul>Важно ограничить нулевой спринт по времени<br />
  77. 77. Последующие спринты – ныряем на глубину<br /><ul><li>Подробное описание юзер-стори
  78. 78. Не больше двух параграфов
  79. 79. Баланс текстового и графического описания
  80. 80. Диаграмма робастности
  81. 81. Диаграмма последовательности
  82. 82. Диаграмма классов
  83. 83. Обновление диаграммы предметной области и диаграммы юзкейсов</li></li></ul><li>Возможные опасности<br />
  84. 84. Agile Manifesto<br /><ul><li>Люди и их взаимодействие важнее процессов и инструментов
  85. 85. Готовый продуктважнее полной документации
  86. 86. Сотрудничество с заказчиком важнее контрактных ограничений
  87. 87. Реакция на измененияважнее следования плану</li></li></ul><li>Инструменты<br />Простота<br />Функционал<br />
  88. 88. Плюсы и минусы ICONIX<br />
  89. 89. Методологии<br />
  90. 90. Литература<br />
  91. 91. Контакты и вопросы<br /><ul><li>Спасибо за внимание!
  92. 92. Вопросы?</li></ul>Мои контакты<br />borisvolfson@gmail.com<br />borisv@softline.ru<br />www.twitter.com/_blv_<br />

×