Роль аналитика в негибких методологиях разработки

868 views
734 views

Published on

В ходе доклада обсудим:
— Какие методологии сейчас используют чаще всего.
— Как типы разработки влияют на решение: взять аналитика в команду или нет.
— В чем суть негибкого процесса. Этапы и поставки аналитических работ.
— Нужен ли аналитик в негибком проекте продуктовой разработки - все за и против.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
868
On SlideShare
0
From Embeds
0
Number of Embeds
310
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Роль аналитика в негибких методологиях разработки

  1. 1. Ирина Сурова для DEVDAYРоль аналитика в «негибких» методологиях разработки
  2. 2. Обо мне В продуктовой разработке 12 лет, из них: в системном анализе 5 лет в тестировании 7 лет опыт создания и поддержки процессов разработки 2 года соавтор клуба прикладного системного анализа проекта Stratoplan.ru участник сообщества аналитиков uml2.ru
  3. 3. Аналитик проецирует образ решения от Заказчика в команду Исполнителя
  4. 4. Какие бывают методологии?Методология 2009 2011 2012Scrum 14 18 21XP 3 1 1Agile-based (не Scrum, не XP) 11 18 27RUP-based 5 5 5CMM/CMMI 2 1 -Как получится 21 18 15Через %опу 35 30 18MSF 1 1 1Водопад/Waterfall - 5 8Другое 8 3 4Голосов 122 913 850 Результаты опросов Happy-PM http://www.happy-pm.com/blog/?p=6559
  5. 5. Методологии в картинках
  6. 6. Водопадный процесс / ГОСТ 34 Бизнес- требования Бизнес-правила Пользовательские требования Ограничения Атрибуты качества Функциональные требования Системные требования
  7. 7. Rational Unified Process
  8. 8. RUP. Точки принятия решений Завершение Начальной стадии — сформировано видение и границы проекта, риски сформулированы и оценены Концепция/Vision (содержит ключевые бизнес-требования, пользовательские требования, бизнес-правила, ограничения и атрибуты качества, ключевые системные и функциональные требования) Завершение итерации Уточнения — уточнены оценки сроков и рисков, построена исполняемая архитектура ТЗ/ЧТЗ/SRS (Бизнес-требования, пользовательские, системные, функциональные требования, ограничения, атрибуты качества, прототипы GUI по функционалу итерации) Завершение фазы Уточнения Все требования
  9. 9. Как получится и Через %опу. Точки принятия решений Надо сделать! Быстро! Постановка задачи разработчику
  10. 10. Обмен ценностями в ходе разработки class Обмен ценностями Бизнес передает технологам плату или инвестиции Бизнес Технологи поставляют Технологию Потребителю в виде продукта/сервиса $$$ $$$ Потребитель использует Технологию и платит плату Потребитель Технологии Бизнесу Продукт Источник модели - презентация Дениса Бескова «4 производственных контекста»
  11. 11. Внутренняя разработка и внедрение (in- house)Типовые цели:смесь бизнеса / потребителя / технологии class Внутрення разработка Организация Бизнес $$$ $$$ Технологии Потребитель Продукт
  12. 12. Заказная разработкаТиповые цели:• Заказчик - Получение ПО, позволяющего добиться бизнес-целей• Подрядчик - исполнение контракта с сохранениемрентабельности class Заказная разработка Заказчик Подрядчик Бизнес Бизнес Потребитель Технологии
  13. 13. Продуктовая разработкаТиповые цели:• Производитель — успех продукта на рынке• Покупатель — быстрое получение ПО, позволяющегодобиться бизнес-целей class Продуктовая разработка Покупатель Покупатель Производитель Бизнес Бизнес Потребитель Технологии
  14. 14. Системная интеграция/внедрениеТиповые цели:• Заказчик: получение ПО, позволяющего добиться бизнес-целей• Подрядчик: соблюдение контракта с сохранениемрентабельности• Производитель: Успех продукта на рынке class Внедрение Заказчик Подрядчик Производитель Бизнес Бизнес Бизнес Потребитель Технологии Технологии
  15. 15. Продукты для массовой аудиторииТиповые цели:• Производитель: достижение бизнес-показателей при ростеколичества/активности пользователей• Бизнес-пользователь: привлечение аудитории/увеличениеузнаваемости своего бренда за счет рекламы в сервисе• Пользователь: получение нужного и удобного сервисабесплатно или дешево. deployment Продукты для массовой аудитории Производитель Бизнес-потребители Бизнес Бизнес Пользователи Потребитель Технологии Потребитель
  16. 16. Итоги:Аналитик: Делает задачу понятней — программисты делают быстрее, тестеры понимают, что является багой — повышает качество. Но удорожает продукт и является передаточным звеном (формально не приносит ценности в продукт)
  17. 17. Самая главная картинка
  18. 18. Спасибо за внимание!Вопросы? Ирина Сурова Mailto:irr.suri@gmail.com

×