Требования постоянно меняются в ходе разработки
Требования могут противоречить друг другу
Меняются приоритеты разработки
Ограничены ресурсы – нужно уметь расставлять приоритеты
Ограничены сроки – нужно ясно понимать, какой функционал к какой дате будет реализован
Требования постоянно меняются в ходе разработки
Требования могут противоречить друг другу
Меняются приоритеты разработки
Ограничены ресурсы – нужно уметь расставлять приоритеты
Ограничены сроки – нужно ясно понимать, какой функционал к какой дате будет реализован
Принципы эффективного управления компаниейНовый Сайт
Коммерческий директор "Новый сайт" Иван Панасюк - о принципам эффективного управления компанией для семинара «Формула компании: новые подходы к внутреннему развитию команды» (19 мая, Минск).
Как оценивать состояние проекта по разработке с помощью формальных метрик и о...Dmitry Andreev
Можете ли вы завтра утром в 8:05 положить на стол руководства детальный отчет по прогрессу разрабатываемой системы, количестве ошибок в разрезе подсистем и требований, качестве юнит-тестов, скорости внесения изменений в код и возникновения ошибок? Можете ли вы с помощью средств аналитики оценить узкие места проекта, например, ответив на вопрос «какая подсистема имеет самое большое количество вновь возникающих ошибок»? Если вы хотите узнать, как это сделать то приходите на доклад о возможностях подсистем отчетности Visual Studio Team System 2010. В докладе будут рассмотрены подходы по созданию формальной системы метрик, индикаторов, отчетов для оценки прогресса и состояния проекта по разработке программного обеспечения.
григорьев андрей, юмисофт, основные ошибки ведения It проектов - от документа...New Business Idea
Основные ошибки ведения IT-проектов - от документации до коммуникаций.
* Сбор и формирование требований к продукту;
* выработка стратегии;
* начальное проектирование;
* документирование процесса;
* построение схемы ролей и коммуникаций;
* дизайн проекта;
* программирование;
* примеры из жизни.
Прагматичный подход к документированию Веб-проектовAnatol Filin
Pragmatic approach to documenting Web projects. Talk at RIT conference, April 2010.
Речь идет о документировании процесса разработки Веб-систем. В работе над проектом как правило участвует команда, состоящая из специалистов разных областей: инвесторы, владельцы бизнеса, бизнес-менеджеры, аналитики, разработчики, юзабилисты, дизайнеры, тестировщики, системные администраторы. Эти специалисты обладают разным опытом, имеют разные цели и говорят на разных языках (причем часто – в прямом смысле этого слова). Некоторые роли могут отсутствовать, другие роли могут «склеиваться».
Существует достаточно развитая культура документирования проектов, которая включает как традиционные артефакты: видение (vision), бизнес-требования (BRD), функциональные требования (FRD), требования к интерфейсу, технические и архитектурные требования (TAD), требования к тестированию, требования к инфраструктуре, так и аджайльные артефакты: пользовательские истории (user stories), визуальные истории (visual stories).
Все Веб-проекты разные: интерфейсные проекты и проекты со сложной логикой (финансовые, научные), средние по размеру проекты и крупные проекты, проекты, которые пишутся с нуля и унаследованные от других разработчиков. Кроме того заказчики могут предъявлять разные требования к документированию: кому-то достаточен список характеристик, кто-то требует детальные функциональные требования, кто-то готов «идти в Agile». Команды тоже бывают разные: полные (свои аналитики, дизайнеры и т.д), локальные и распределенные.
В докладе не предлагается один рецепт на все случаи жизни. Главная идея доклада состоит в том, чтобы в соответствии с особенностями проекта и проектной команды рациональным образом выбрать тот набор документов, который абсолютно необходим для его успешного развития.
Доклад на конференции AnalystDays 2013 ( Санкт-Петербург )
Авторы доклада: Дмитрий Безуглый, Ирина Сурова
У каждого руководителя вместе с успехом неизбежно наступает момент, когда компания/команда растет, задач непочатый край, а специалисты по анализу, как и сам руководитель, "не резиновые". Остро встает вопрос где взять, как выбрать и как включить аналитика в команду.
Типичные проблемы с которыми сталкивается руководитель в этом процессе:
Проверенный специалист, отлично зарекомендовавший себя в нескольких проектах, "ни с того ни с сего" проваливает проект.
Отличный кандидат, взятый на вырост, месяц за месяцем проедает ваше время и силы и когда остается еще чуть-чуть упирается в невидимую стену и прекращает расти сколько его не "окучивай", или еще хуже, сразу после завершения обучения уходит в другой проект или компанию.
Опытный профессионал "с репутацией", пришедший в команду, так и не находит себе места, проходят месяцы, а результата нет. И приходится расставаться, потеряв и время и деньги. Хорошо если обойдется без обид и взаимных обвинений.
Такова жизнь или все-таки можно что-то сделать?
Разумеется можно и что для этого нужно делать мы расскажем в своем докладе.
В рамках доклада мы хотим раскрыть тему компетентности и эффективности аналитика.
Основные вопросы на которые вы получите ответы:
Требования к личностным характеристикам аналитика, простые инструменты их идентификации и взаимосвязи с эффективным применением в проекте
Структура и методы оценки знаний и навыков аналитика
Методология применения модели компетенций к отбору и развитию компетенции специалистов и отдела бизнес и системного анализа в целом
Для кого: Руководители групп аналитиков, Специалисты по методологии, Аналитики и желающие ими стать.
Review key roles around product. Discuss key areas: Customer Focus, Differentiation, Unexpected Stakeholders and Cases, Blue Ocean Matrix, Culture Code tools to be a more successful with a new Product.
Принципы эффективного управления компаниейНовый Сайт
Коммерческий директор "Новый сайт" Иван Панасюк - о принципам эффективного управления компанией для семинара «Формула компании: новые подходы к внутреннему развитию команды» (19 мая, Минск).
Как оценивать состояние проекта по разработке с помощью формальных метрик и о...Dmitry Andreev
Можете ли вы завтра утром в 8:05 положить на стол руководства детальный отчет по прогрессу разрабатываемой системы, количестве ошибок в разрезе подсистем и требований, качестве юнит-тестов, скорости внесения изменений в код и возникновения ошибок? Можете ли вы с помощью средств аналитики оценить узкие места проекта, например, ответив на вопрос «какая подсистема имеет самое большое количество вновь возникающих ошибок»? Если вы хотите узнать, как это сделать то приходите на доклад о возможностях подсистем отчетности Visual Studio Team System 2010. В докладе будут рассмотрены подходы по созданию формальной системы метрик, индикаторов, отчетов для оценки прогресса и состояния проекта по разработке программного обеспечения.
григорьев андрей, юмисофт, основные ошибки ведения It проектов - от документа...New Business Idea
Основные ошибки ведения IT-проектов - от документации до коммуникаций.
* Сбор и формирование требований к продукту;
* выработка стратегии;
* начальное проектирование;
* документирование процесса;
* построение схемы ролей и коммуникаций;
* дизайн проекта;
* программирование;
* примеры из жизни.
Прагматичный подход к документированию Веб-проектовAnatol Filin
Pragmatic approach to documenting Web projects. Talk at RIT conference, April 2010.
Речь идет о документировании процесса разработки Веб-систем. В работе над проектом как правило участвует команда, состоящая из специалистов разных областей: инвесторы, владельцы бизнеса, бизнес-менеджеры, аналитики, разработчики, юзабилисты, дизайнеры, тестировщики, системные администраторы. Эти специалисты обладают разным опытом, имеют разные цели и говорят на разных языках (причем часто – в прямом смысле этого слова). Некоторые роли могут отсутствовать, другие роли могут «склеиваться».
Существует достаточно развитая культура документирования проектов, которая включает как традиционные артефакты: видение (vision), бизнес-требования (BRD), функциональные требования (FRD), требования к интерфейсу, технические и архитектурные требования (TAD), требования к тестированию, требования к инфраструктуре, так и аджайльные артефакты: пользовательские истории (user stories), визуальные истории (visual stories).
Все Веб-проекты разные: интерфейсные проекты и проекты со сложной логикой (финансовые, научные), средние по размеру проекты и крупные проекты, проекты, которые пишутся с нуля и унаследованные от других разработчиков. Кроме того заказчики могут предъявлять разные требования к документированию: кому-то достаточен список характеристик, кто-то требует детальные функциональные требования, кто-то готов «идти в Agile». Команды тоже бывают разные: полные (свои аналитики, дизайнеры и т.д), локальные и распределенные.
В докладе не предлагается один рецепт на все случаи жизни. Главная идея доклада состоит в том, чтобы в соответствии с особенностями проекта и проектной команды рациональным образом выбрать тот набор документов, который абсолютно необходим для его успешного развития.
Доклад на конференции AnalystDays 2013 ( Санкт-Петербург )
Авторы доклада: Дмитрий Безуглый, Ирина Сурова
У каждого руководителя вместе с успехом неизбежно наступает момент, когда компания/команда растет, задач непочатый край, а специалисты по анализу, как и сам руководитель, "не резиновые". Остро встает вопрос где взять, как выбрать и как включить аналитика в команду.
Типичные проблемы с которыми сталкивается руководитель в этом процессе:
Проверенный специалист, отлично зарекомендовавший себя в нескольких проектах, "ни с того ни с сего" проваливает проект.
Отличный кандидат, взятый на вырост, месяц за месяцем проедает ваше время и силы и когда остается еще чуть-чуть упирается в невидимую стену и прекращает расти сколько его не "окучивай", или еще хуже, сразу после завершения обучения уходит в другой проект или компанию.
Опытный профессионал "с репутацией", пришедший в команду, так и не находит себе места, проходят месяцы, а результата нет. И приходится расставаться, потеряв и время и деньги. Хорошо если обойдется без обид и взаимных обвинений.
Такова жизнь или все-таки можно что-то сделать?
Разумеется можно и что для этого нужно делать мы расскажем в своем докладе.
В рамках доклада мы хотим раскрыть тему компетентности и эффективности аналитика.
Основные вопросы на которые вы получите ответы:
Требования к личностным характеристикам аналитика, простые инструменты их идентификации и взаимосвязи с эффективным применением в проекте
Структура и методы оценки знаний и навыков аналитика
Методология применения модели компетенций к отбору и развитию компетенции специалистов и отдела бизнес и системного анализа в целом
Для кого: Руководители групп аналитиков, Специалисты по методологии, Аналитики и желающие ими стать.
Review key roles around product. Discuss key areas: Customer Focus, Differentiation, Unexpected Stakeholders and Cases, Blue Ocean Matrix, Culture Code tools to be a more successful with a new Product.
Irrational People: What to Know in Analysis and ManagementAnton Vityaz
People Irrational. You know? But how irrational aspects would impact the decision-making in project, during the requirements' definition. Do we really understand personas impacted by irrational factors?
When you pool 50+ acting delivery managers in organization, you can find a lot of surprises HOW they understand Delivery Management role. This is definitely surprising you. How to treat results, what PAEI management model says and how to deal with this variety.
How to apply ALM to Enterprise Business AnalysisAnton Vityaz
How we can gain more benefits from the Azure DevOps for Business Analyst by having more than just backlog? Can we manage more views to Enterprise Architecture, Business Process and Data Model?
How we should perceive modern No Code Approach? How No Code approach differs from Code-based approach in software development. Is it silver bullet in creating business solutions?
Very detailed research regarding key points of the Finnish Culture. This presentation could be used before you actually start to work within Finland or with Finnish team
What you have to know regarding Norway / Sweden / Finland when you just start to work with? Pay attention on the traditional core values, see the differences and build effective way of communication within the team
What toxic requirements is? How they can impact to your project? What you can deal with the strongest toxic requirements like: "and etc" or "nice interface"
Успешный запуск продукта: совместная работа BA, PO, PMAnton Vityaz
Успешный запуск продукта: совместная работа Business Analyst, Product Owner, Product Manager + инвестор. Что нужно знать бизнес аналитику для построения эффективного и результативного взаимодействия на старте - насколько понятен "голубой океан" продукта, целевые сегменты, процессы по всему жизненному циклу продукта. Выстроено ли Agile взаимодействие?
Клуб аналитиков Thinkersware: Анализ на входеAnton Vityaz
Какие важные моменты пропускает аналитик на старте? Как провести анализ исходных требований, что делать с бизнес целями и приоритетами, почему важны рамки проекта и работа с заинтересованными лицами. Стоит ли доверять пользовательским требованиям, принимать неопределенности и двусмысленности.
1. < PRESENTATION >
Title = “ALM: from analysis to solution development with Microsoft TFS Online”
Author = “Anton Vityaz”
2. Who is Mr. Vityaz?
• Что я делаю
• Solution Design & Consulting
• Project / Team management
• Develop
• Какие типы решений
• Автоматизация корпоративных бизнес процессов
• Работа с контентом
• Управление проектами
• Что использую
• Платформы Microsoft SharePoint, Project, Dynamics CRM
• “Рисую” Workflow & Forms
• Часть времени пишу код “бизнес логики” C#, JS
6. Потеряшки & Забывашки
• Забыли уточнить …
• Забыли согласовать …
• Не вписали решение для …
• Пропустили оценку …
• Откуда это взялось?
• C чем это связано?
7. Управляшки
• Что надо создать?
• Кто что должен делать?
• По каким требованиям?
• Какие вопросы?
• Какие проблемы?
• Что меняем?
8. Упростяшки
• Не хотим писать документы
• Документ = База данных
• Не хотим клепать отчеты
• Отправить выгрузку …
• Упростить коммуникации
• Написать письмо по поводу …
• Отправить ссылку на …
15. 4. Интеграция
• Интеграция с Visual Studio
• Контроль версий
• Work items query
• Интеграция с Excel
• Выгрузка данных
• Редактирование и создание данных
• Интеграция с Microsoft Project
21. Ура! Мы договорились с
клиентом об автоматизации
заявки на получение
пропуска на SharePoint и К2
BlackPoint.
22. •Авторизованные сотрудники
могут оставлять заявку на
пропуск
•В заявке надо указать кто будет
встречать, где будет проходить
встреча
•Заявка должна быть
согласована
Если что-то не ясно – уточните, давайте оценку и
побыстрее начинаем кодить!
Требования очень простые:
28. < / Заводим initial requirements >
• Value area = Business
• Тип work item = Requirements
• Если несколько исходных документов - Иерархия по документам
• Длинные требования можно разбивать на дочерние элементы
(требования)
• Нельзя изменять исходные требования существенно
30. Уточняем
• Нужно продумать и зарегистрировать все вопросы
• Почему спрашиваем
• Что предлагаем
• Кого мы спрашиваем
• Нужно отправить вопросы
• Поштучно или
• Пакетом
• Нужно завести ответы
• Иногда их заводит клиент сам!
34. < / Clarification >
• Value area = Business
• Work item type = Review
• Можно несколько вопросов загонять в один Review если хотим
уменьшить количество вопросов и из них составлять повестку
• Ответы заносим в Review
• Если потом будут доп вопросы – отдельный Review
35. < Define product >
Продумываем
компоненты
Связываем с
требованиями
Выявляем
скрытые
требования
36. Фичи-Фичи-Фичи
• Начинаем продумывать что нужно в решении для реализации
требования
• Появляется реестр фич (Features)
• Фичи идут Related связями к требованиям
42. Общие принципы
• Отделяем от бизнес области: Value area = Architectural
• Используйте тип work item Requirements
• Заводите все что делаете и все что надо согласовать с
заказчиком – таблицы для данных, формы, …
• Баланс между элементами и описанием в Word надо поймать.
• Мне не хватает стандартных подтипов
• Используем тэги для определения подтипов объектов.
Например: List, Content type, View, Form, Webpart
• Если у вас большое количество объектов одного типа – бейте на
пакеты. Пакет можно создать используя тэг – например UCG1,
UCG2
47. Оценка проекта
• Определяем фичи архитектурные – все-все!
• Создаем нужный уровень детализации в виде иерархии фич
• Предварительные оценки можем занести в оценку эффортов
фич – это первичная оценка
• Накидываем задач, оцениваем в задачах эффорты
• Задачи можем классифицировать по функционалу –
Analyse, C# Coding, JS Coding etc
• Выгрузка в Microsoft Project позволяет на все посмотреть с точки
зрения загрузки ресурсов, ганта
57. Хинт 1. ВЫГРУЖАЙТЕСЬ
Работайте в Excel с основными таблицами
С глубокой иерархией – в Project
С датами – в Project (только осторожно)
Выгрузки храните в TFS Source Control
Архивы храните нетронутыми