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

1. Сбор и анализ требований в Scrum Адаптация процесса ICONIX Вольфсон Борис Руководитель проектовРуководитель регионального отдела веб-разработки Компания Softline

3. Описание процесса ICONIX

4. Диаграммыи процесс

5. Адаптация процесса ICONIX под Scrum/Agile

6. Потери при производстве

7. Синхронизация диаграмм и кода

8. Соответствие принципам Agile

10. Разработка высоконагруженных коммерческих сайтов:

11. Корпоративные веб-сайты

12. Веб-сайты для электронной коммерции

13. Около 100 основных участников проектов

14. Страны СНГ и дальнего зарубежья

15. Распределенная команда разработки

18. Выявление и описание персонажей

19. Создание юзер-стори

20. Как «персонаж», я «действие» для «цель»

21. Описания юзер-стори хранятся в виде «знаний» команды

23. Как мы понимаем Scrum

25. Более 10 видов диаграмм

26. 900-страничное руководство

27. Слишком подробное описание

28. Неявная «Водопадная модель»

29. Избыточность

31. Ожидание

32. Переключение между задачами

33. Лишние этапы обработки

34. Лишние запасы

35. Ненужные перемещения сотрудников

37. ICONIX подмножество UML

38. Классическая схема процесса ICONIX Динамика Вариантыиспользования ПротипUI Последовательность Сценариитестирования Робастность Статика Код Предметнаяобласть Обновления предметной области Классы

39. Диаграмма предметной области

40. Диаграмма классов

41. Диаграмма вариантов использования Марья Васильевна как пользователь читает справку, чтобы понять, как использовать систему

42. Диаграмма робастности

44. Выявление дополнительных объектов

45. Проверка текста юзкейсов

46. Предварительная проработка архитектуры

48. Диаграмма последовательности

50. Системный аналитик для Product owner’а

51. Уменьшение количества неправильных требований

52. Анализ предметной области

53. Проектирование взаимодействия с системой

54. Префакторинг – рефакторинг модели

55. Синхронизация моделей и кода

58. Допускает потери при производстве

59. Перепроизводство - проработка лишних требований

60. Лишняя обработка - актуализация диаграмм

61. Лишние запасы – проработка всей модели… но ICONIX отлично адаптируется к Agile

63. Полная или частичная синхронизация

64. «Внешние разработчики»

65. Распределенная команда

66. Поддержка продукта

67. Части продукта для синхронизации

68. Основной функционал

70. Подводное плавание - метафора содержания проекта Размер/рамки проекта Общее описание системы и архитектура Спринт №4 Спринт №1 Спринт №2 Спринт №3 Спринт №1 Спринт №2 Детализация проекта Спринт №3 Спринт №4

72. Диаграмма предметной области

73. Диаграмма вариантов использования

74. Роли и персонажи

75. Юзер-стори без описания

76. Проработка юзер-стори для первого спринтаВажно ограничить нулевой спринт по времени

78. Не больше двух параграфов

79. Баланс текстового и графического описания

80. Диаграмма робастности

81. Диаграмма последовательности

82. Диаграмма классов

85. Готовый продуктважнее полной документации

86. Сотрудничество с заказчиком важнее контрактных ограничений

88. Плюсы и минусы ICONIX

89. Методологии

90. Литература

92. Вопросы?Мои контакты borisvolfson@gmail.com borisv@softline.ru www.twitter.com/_blv_