В ходе доклада обсудим:
— Какие методологии сейчас используют чаще всего.
— Как типы разработки влияют на решение: взять аналитика в команду или нет.
— В чем суть негибкого процесса. Этапы и поставки аналитических работ.
— Нужен ли аналитик в негибком проекте продуктовой разработки - все за и против.
Прагматичный подход к документированию Веб-проектовAnatol Filin
Pragmatic approach to documenting Web projects. Talk at RIT conference, April 2010.
Речь идет о документировании процесса разработки Веб-систем. В работе над проектом как правило участвует команда, состоящая из специалистов разных областей: инвесторы, владельцы бизнеса, бизнес-менеджеры, аналитики, разработчики, юзабилисты, дизайнеры, тестировщики, системные администраторы. Эти специалисты обладают разным опытом, имеют разные цели и говорят на разных языках (причем часто – в прямом смысле этого слова). Некоторые роли могут отсутствовать, другие роли могут «склеиваться».
Существует достаточно развитая культура документирования проектов, которая включает как традиционные артефакты: видение (vision), бизнес-требования (BRD), функциональные требования (FRD), требования к интерфейсу, технические и архитектурные требования (TAD), требования к тестированию, требования к инфраструктуре, так и аджайльные артефакты: пользовательские истории (user stories), визуальные истории (visual stories).
Все Веб-проекты разные: интерфейсные проекты и проекты со сложной логикой (финансовые, научные), средние по размеру проекты и крупные проекты, проекты, которые пишутся с нуля и унаследованные от других разработчиков. Кроме того заказчики могут предъявлять разные требования к документированию: кому-то достаточен список характеристик, кто-то требует детальные функциональные требования, кто-то готов «идти в Agile». Команды тоже бывают разные: полные (свои аналитики, дизайнеры и т.д), локальные и распределенные.
В докладе не предлагается один рецепт на все случаи жизни. Главная идея доклада состоит в том, чтобы в соответствии с особенностями проекта и проектной команды рациональным образом выбрать тот набор документов, который абсолютно необходим для его успешного развития.
Прагматичный подход к документированию Веб-проектовAnatol Filin
Pragmatic approach to documenting Web projects. Talk at RIT conference, April 2010.
Речь идет о документировании процесса разработки Веб-систем. В работе над проектом как правило участвует команда, состоящая из специалистов разных областей: инвесторы, владельцы бизнеса, бизнес-менеджеры, аналитики, разработчики, юзабилисты, дизайнеры, тестировщики, системные администраторы. Эти специалисты обладают разным опытом, имеют разные цели и говорят на разных языках (причем часто – в прямом смысле этого слова). Некоторые роли могут отсутствовать, другие роли могут «склеиваться».
Существует достаточно развитая культура документирования проектов, которая включает как традиционные артефакты: видение (vision), бизнес-требования (BRD), функциональные требования (FRD), требования к интерфейсу, технические и архитектурные требования (TAD), требования к тестированию, требования к инфраструктуре, так и аджайльные артефакты: пользовательские истории (user stories), визуальные истории (visual stories).
Все Веб-проекты разные: интерфейсные проекты и проекты со сложной логикой (финансовые, научные), средние по размеру проекты и крупные проекты, проекты, которые пишутся с нуля и унаследованные от других разработчиков. Кроме того заказчики могут предъявлять разные требования к документированию: кому-то достаточен список характеристик, кто-то требует детальные функциональные требования, кто-то готов «идти в Agile». Команды тоже бывают разные: полные (свои аналитики, дизайнеры и т.д), локальные и распределенные.
В докладе не предлагается один рецепт на все случаи жизни. Главная идея доклада состоит в том, чтобы в соответствии с особенностями проекта и проектной команды рациональным образом выбрать тот набор документов, который абсолютно необходим для его успешного развития.
* Классификация нефункциональных требований
* Шаблоны нефункциональных требований
* Численные значения нефункциональных требований
* Связи между нефункциональными и функциональными требованиями
* Влияние различных категорий нефункциональных требований друг на друга
* Атрибуты качества продукта и нефункциональные требования
* Роли в проекте, с которыми взаимодействует аналитик при выявлении и уточнении нефункциональных требований
* Классификация нефункциональных требований
* Шаблоны нефункциональных требований
* Численные значения нефункциональных требований
* Связи между нефункциональными и функциональными требованиями
* Влияние различных категорий нефункциональных требований друг на друга
* Атрибуты качества продукта и нефункциональные требования
* Роли в проекте, с которыми взаимодействует аналитик при выявлении и уточнении нефункциональных требований
Макс Гапонов. Тактическое управление продуктами: все еще недостающее звеноScrumTrek
На каждой стратегической сессии выясняется, что реальный объем работ, которые необходимо совершить, в 4-5 раз превышает тот, который запланирован. И, что самое интересное, этот объем озвучивают сами участники, которые и являются авторами предыдущих нереалистичных планов.
Слушайте, с этим пора что-то делать :) Это же не магия какая-нибудь. Это ремесло. Ремесло о том, как системно сформировать и договориться о границах работ; ремесло, как закрепить за ролями ответственность; ремесло, как выстроить управление и коммуникации между разными уровнями доставки бизнес-ценности; ремесло, как оценивать текущую зрелость процессов и обеспечивать непрерывное улучшение.
В докладе я расскажу вам о своем опыте решения этих задач в разных компаниях.
Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool /...Ontico
РИТ++ 2017, Web-scale IT Сonference
Зал Владивосток, 6 июня, 17:00
Тезисы:
http://webscaleconf.ru/2017/abstracts/2553.html
Платформа виртуализации данных на основе Tarantool - система, созданная в Mail.Ru Group в прошлом году. Cовместно с АТ Consulting было создано и запущено в production решение для хранения 100 млн. профилей абонентов компании Beeline, выдерживающее значительные нагрузки.
...
Гибкие методологии при создании ИТ продукта. Сравнения. Основные инструменты.
Дашкин Руслан Валерьевич, тренер-консультант, сертифицированный преподаватель АСКОН.
18 сентября 2014 г.
Kuoll — фиксить баги, даже не воспроизводя их”
Что за стартап Kuoll, и почему я решил уйти в самостоятельную разработку
Kuoll — инструмент для улучшения качества веб продуктов и жизни разработчиков
П.С. Личная практика быстрого старта разработки своего продукта
Similar to Роль аналитика в негибких методологиях разработки (20)
Поговорим, как и зачем функционально тестировать хайлоад, получать от тестов больше, чем «прошёл/не прошёл», а их количество превратить в качество продукта.
Фреймворк Slot, Good Parts, Александр БирюковDevDay
Расскажу о ключевых особенностях продукта: о какой изоморфности идёт речь, как мы управляем состоянием SinglePage-приложения и какой профит для SEO извлекли, с примерами кода. Посмотрим как быстро начать свой проект на Slot.
Рендеринг может больше: vue.js vs React, Андрей СолодовниковDevDay
О том, как перестать вручную контролировать DOM, писать логику навигаций и почему DOM-шаблонизация — это классно, а так же немного самокритики и сравнительных тест-кейсов.
Devops-практики в разработке решений для бизнеса, Максим ПашукDevDay
Обычно разработчик успокаивается как только написан код, решающий задачи бизнеса. На самом деле есть ещё целый ряд вопросов, которые также необходимо решать.
Как донести изменения разработчика до тестирования в согласованном виде (база данных, приложение, конфиги)? Как донести эти же изменения до production и ничего не потерять по дороге? Что делать если продукт — распределённая многокомпонентная система, работающая в отказоустойчивом кластере? Тогда ситуация требует тесной совместной работы разработчиков и администраторов, а это, как известно, люди немного с разных планет.
Я расскажу на примере конкретного проекта на .NET стеке, как мы построили мост дружбы. Как свели воедино систему сборки, развёртывания и автоматизации, используя библиотеку psake и достигли взаимопонимания.
Inversion of Control в деталях, Дмитрий КожевниковDevDay
Казалось бы всё сказано об инверсии управления, особенно в .NET. Но нетривиальные квесты вокруг дизайна, построенного на DI, продолжают возникать из проекта в проект. Предлагаю поговорить немного о прописных истинах, а потом перейти к более любопытным вещам и болезненным вопросам.
Чем плох ServiceLocator? Почему IoC-контейнер — это фреймворк, а не библиотека? Как быть с множественными реализациями? Convention over configuration?
Отдельно поговорим об архитектуре enterprise решений в свете возможностей IoC-контейнеров.
Год от года многие программисты решают одни и те же задачи, но не всегда среди огромного многообразия решений можно найти что-то подходящее. Вот и мы не смогли найти ни одной библиотеки логирования для C++, которая удовлетворяла бы всем нашим требованиям. Теперь у нас есть свой велосипед, и мы расскажем, чем он лучше других.
Манипулятор на Ti Stellaris Launchpad, Лёша РоманенкоDevDay
За последние несколько десятков лет робототехника стала очень доступной. Настолько, что можно собрать робота и запрограммировать его даже в домашних условиях, имея подходящий инструментарий. С чего начать? Как попробовать? Именно об этом мы и поговорим на докладе на примере контроллера TI Stellaris Launchpad (аналог Arduino), управляемого с Android-смартфона.
Все мы привыкли писать программы, результаты работы которых можно увидеть и услышать. Хотите, чтобы их можно было ещё и потрогать? На примере создания электронной игры «Лабиринт» вы увидите, как не имея знаний и опыта сделать первый шаг в мир hardware.
Расскажу про первый продукт 2ГИС, который не совсем про организации – 2GIS Dialer. О трудностях создания, и почему их не нужно бояться. Делая что-то новое, вы обязательно с ними столкнетесь:
— Команда будет меняться.
— Конкуренты будут поджимать и опережать.
— Промо-кампании не будут стрелять.
«Бегущий по лезвию. Продуктовые сценарии в дизайне», Макс Карпылев DevDay
С чего начинается проектирование и дизайн новых продуктов — со сценариев. Продуктовые сценарии работы — ключевой элемент в пазле проектирования новых взаимодействий. В докладе покажу какое место сценарии занимают в 2ГИСе, почему они важны и какие сценарии бывают.
«Роль исследований в формировании продуктового видения компании», Лиза Алексе...DevDay
В своем докладе я расскажу о постановке цели и подготовительном этапе при проведении продуктовых исследований. Мы рассмотрим наиболее популярные виды исследований. Специфику исследований на локальном и междунароных рынках. Прикладную ценность результатов исследований. И это всё на примерах продуктов компании 2ГИС.
Матвей Мальков «Ещё один поиск контактов на Android»DevDay
Многие дайлеры не умеют делать поиск по Т9 клавиатуре. Те, что умеют, в большинстве своем делают поиск только по имени/фамилии контакта или по началу номера, а кто-то только с использованием английского алфавита. В 2GIS Dialer нам хотелось искать все контакты по имени, фамилии, телефону (любому из списка и с любого символа), а так же по должности и месту работу (опционально: e-mail и вебсайт, адрес и группы контактов). Кроме того, нам хотелось, чтобы пользователь на любом языке мог найти свои контакты. И в завершение необходимо было, чтобы весь этот поиск работал быстро. О том, как мы добились прогресса в этом деле я и расскажу.
Матвей Мальков «Ещё один поиск контактов на Android»
Роль аналитика в негибких методологиях разработки
1. Ирина Сурова для DEVDAY
Роль аналитика в «негибких» методологиях
разработки
2. Обо мне
В продуктовой разработке 12 лет, из них:
в системном анализе 5 лет
в тестировании 7 лет
опыт создания и поддержки процессов
разработки 2 года
соавтор клуба прикладного системного
анализа проекта Stratoplan.ru
участник сообщества аналитиков uml2.ru
6. Водопадный процесс / ГОСТ 34
Бизнес-
требования
Бизнес-правила
Пользовательские
требования
Ограничения
Атрибуты качества
Функциональные
требования
Системные
требования
8. RUP. Точки принятия решений
Завершение Начальной стадии — сформировано видение и
границы проекта, риски сформулированы и оценены
Концепция/Vision (содержит ключевые бизнес-требования,
пользовательские требования, бизнес-правила, ограничения и
атрибуты качества, ключевые системные и функциональные
требования)
Завершение итерации Уточнения — уточнены оценки сроков и
рисков, построена исполняемая архитектура
ТЗ/ЧТЗ/SRS (Бизнес-требования, пользовательские, системные,
функциональные требования, ограничения, атрибуты качества,
прототипы GUI по функционалу итерации)
Завершение фазы Уточнения
Все требования
9. Как получится и Через %опу.
Точки принятия решений
Надо сделать! Быстро!
Постановка задачи разработчику
10. Обмен ценностями в ходе разработки
class Обмен ценностями
Бизнес передает технологам
плату или инвестиции Бизнес
Технологи поставляют
Технологию Потребителю в
виде продукта/сервиса
$$$ $$$
Потребитель использует
Технологию и платит плату Потребитель Технологии
Бизнесу Продукт
Источник модели - презентация Дениса Бескова
«4 производственных контекста»
11. Внутренняя разработка и внедрение (in-
house)
Типовые цели:
смесь бизнеса / потребителя / технологии
class Внутрення разработка
Организация
Бизнес
$$$ $$$
Технологии Потребитель
Продукт
12. Заказная разработка
Типовые цели:
• Заказчик - Получение ПО, позволяющего добиться бизнес-
целей
• Подрядчик - исполнение контракта с сохранением
рентабельности
class Заказная разработка
Заказчик Подрядчик
Бизнес Бизнес
Потребитель
Технологии
13. Продуктовая разработка
Типовые цели:
• Производитель — успех продукта на рынке
• Покупатель — быстрое получение ПО, позволяющего
добиться бизнес-целей
class Продуктовая разработка
Покупатель
Покупатель Производитель
Бизнес Бизнес
Потребитель
Технологии
14. Системная интеграция/внедрение
Типовые цели:
• Заказчик: получение ПО, позволяющего добиться бизнес-
целей
• Подрядчик: соблюдение контракта с сохранением
рентабельности
• Производитель: Успех продукта на рынке
class Внедрение
Заказчик Подрядчик Производитель
Бизнес Бизнес Бизнес
Потребитель Технологии
Технологии
15. Продукты для массовой аудитории
Типовые цели:
• Производитель: достижение бизнес-показателей при росте
количества/активности пользователей
• Бизнес-пользователь: привлечение аудитории/увеличение
узнаваемости своего бренда за счет рекламы в сервисе
• Пользователь: получение нужного и удобного сервиса
бесплатно или дешево.
deployment Продукты для массовой аудитории
Производитель Бизнес-потребители
Бизнес
Бизнес
Пользователи
Потребитель Технологии
Потребитель
16. Итоги:
Аналитик:
Делает задачу понятней — программисты
делают быстрее, тестеры понимают, что
является багой — повышает качество.
Но удорожает продукт и является
передаточным звеном (формально не
приносит ценности в продукт)