2. О Докладчике
Роман Оксюковский
Руководитель выделенного центра разработки, Softheme
roman.oksyukovski@gmail.com
+38.097.796.4117
8 лет в индустрии разработки программного
обеспечения, 3 из которых на руководящих
позициях
3. Методология под проект
«В зависимости
от размера проекта
(числа людей, работу
которых необходимо
координировать), кри-
тичности разрабаты-
ваемого приложения и
основных приоритетов,
в проекте могут
применяться
различные
методологии.»
-Алистэр Коуберн
Humans and Technology Technical Report, TR
99.04, Oct.1999 7691 Dell Rd, Salt Lake City,
UT 84121 USA
4. Пример из жизни ...
Проект разработки
ERP системы для
дистрибьюторской
компании, которая
занимается оптовой
продажей FMCG
товаров в Донецкой
области.
5. Характеристика компании ...
~1000 сотрудников
Географическая
распределенность
филиалов компании
Высокая сложность
некоторых
управленческих
функций
Зависимость к
производительности
и стабильности
работы ИТ-систем
6. Структура команды ...
Спонсор проекта
Спонсор проекта
Руководитель
Руководитель Руководитель
Руководитель
отдела
отдела отдела
отдела Бизнес-аналитик х 2
Бизнес-аналитик х 2
разработки
разработки тестирования
тестирования
Разработчики
Разработчики
Системный
Системный Архитектор
Архитектор бизнес
бизнес Тестировщик х 2
Тестировщик х 2
аналитик
аналитик логики х 5
логики х 5
7. Характеристика команды ...
Спонсор = собственник
компании-заказчика.
Бизнес-аналитики =
ключевые сотрудники
компании-заказчика.
Вся команда физически
расположена в одном
офисе.
Комната для совещаний
оборудована проектором
и досками для рисования,
а также большим столом
для совещаний.
9. Inception
RUP Agile
Обоснование бизнес-идеи Работа в одной команде над
Определение видения определением видения
продукта Интенсивное общение
Наброски архитектуры Прототипирование системы
Определение основных use Каждый влияет на
case определение процессов
Business modeling разработки
Наброски процессов и Получение раннего feedback
структуры артефактов. по прототипам и наброскам
архитектуры
Использование принципа
Simplicity для всего, что
производится
(документация, код,
прототипы).
10. Elaboration
RUP Agile
Уточнение видения Появление итераций, хотя
Проработка деталей use разных по протяженности
cases Проведение Demo спонсору
Старт разработки бизнес- и бизнес-аналитикам,
модулей системы получение feedback
Уточнение процессов Daily Scrum (15 мин)
разработки и тестирования. Формирование Product
Уточнение структуры Backlog и Iteration Backlog
артефактов.
Уточнение ролей
Change Management
Использование UML
11. Construction
RUP Agile
Стабилизация архитектуры Daily Scrums
Минимальные уточнения Стабильные итерации
процессов разработки и протяженностью 1 месяц
тестирования Планирвоание Iteration
Backlog, при котором выбор
задач и оценку трудозатрат
выполняли разработчики
Demo спонсору и бизнес-
аналитикам (Product Owners)
Процесс инкрементальный
(выпуск версий,
поставляемых конечным
пользователям с
получением feedback)
12. Transition …
RUP Agile
Планирование действий по Daily Scrums ☺
внедерению готового Внедрение модулей
продукта в компании системы в «пилотном»
Change Management режиме
Интенсивное тестирование Получение feedback от
модулей системы конечных пользователей и
планирование Iteration
Backlog с учетом
запрошенных изменений
Процесс инкрементальный
13. Что не прижилось ...
RUP: Use Case Points Estimation
– слишком сложно и не
учитывало «особенных»
моментов.
RUP: Unit Tests – из-за
специфика приложения и
динамично изменяющихся
требований.
Agile: Инкрементальность
процесса – в виду того, что
система достаточно сложная и
имела много зависимостей
(рабочие инкременты появились
только при Transition).
В некоторых случаях не работал
принцип Agile – Simplicity.
14. RUP. Best Practices
Разрабатывайте ПО
итеративно
Управляйте
требованиями
Используйте компонето-
ориентированную
архитектуру
Визуально моделируйте
ПО
Постоянно проверяйте
качество ПО
Контролируйте
изменения к ПО
15. RUP и другие методологии
Алексей Закис «RUP и другие методологии разработки ПО»
http://cmcons.com/articles/obshhie_stati_rup/rup_i_drugie_metodologii_razrabotki_po/
16. RUP. Tailoring …
«Applying all of RUP on a
single project will likely result in
an inefficient project
environment, where teams will
struggle to keep focused on the
important tasks, and struggle to
find the right set of information.
Thus, we recommend that all
projects tailor the RUP.»
- RUP. Concepts: RUP
Tailoring
17. Выводы
Под каждый проект следует подбирать
свою методологию и подходы.
Не стоит сравнивать методологии
(лучшехуже) , а стоит знать, понимать,
использовать по назначению и получать
удовольствие от результатов.
Чем больше знаешь инструментов и
ситуации, в которых их использовать, тем
зрелее процессы разработки в каждом
Вашем проекте.