Цель данной заметки (или конспекта) — предложить строгим (но конструктивным :-) критикам перечень группы требований и способы их структурирования, предъявляемых к коммерческому корпоративному сайту. Планируемый жизненный цикл сего текста — сначала она будет доступна только участникам соответствующего блога. Затем, всем. Так что спешите критиковать.
Эти требования важно предусмотреть при проектировании сайта, и задокументировать в концепции сайта и техническом задании на проект. Публикация не претендует на полноту и завершенность, однако вместе мы сможем ее приблизить к идеалу.

Задачи аналитика при проектировании сайта

Кто в проекте работает с требованиями? Бизнес-аналитик. Однако, на малых проектах его функцию выполняют технические директора, директора по разработке, менеджеры проектов. Задачи аналитика:

1. Идентифицировать все источники требований
2. Выявить требований (часть требований существует, но клиент их не всегда осознает — в этом поможет опыт аналитика по веб-проектам)
3. Сформулировать требования и уточнить их
4. Назначить приоритет требованиям.
5. Сформулировать технические задания

Участники:
Асхат Уразбаев, Денис Бесков, Денис Миллер, Никита Филиппов

Темы
* Классический аналитик
* Кто создаёт требования и делает сбор, когда
* Управление требованиями
* Управление изменениями требованиями

Денис Бесков — руководитель отдела системного анализа Лаборатории Касперского, евангелист системного анализа разработки ПО в России.

(RSS для iTunes)

Москва – управление требованиями и Scrum

10 февраля в Москве будет однодневный тренинг по Scrum. Сразу за ним 11–12 февраля двухдневный тренинг по требованиям в Agile (Agile Requirements). Вести тренинги будет Никита Филиппов.

Что будет интересного?

• Управление продуктом
• Жизненный цикл требований от концепции до (пере-)планирования релизов.
• Разберемся с User Story и еще одним инновационным методом – Story Mapping.
• Изучим контракты с фиксированной ценой и T&M
• Затронем вопрос «полезных» метрик.
• Ну и куча всего другого полезного
  

Стоимость тренинга — 3000 рублей за AD-Agile Development with Scrum и 16000 рублей за REQ-Agile Requirements Analysis.

Екатеринбург – Scrum и Test Driven Development

Еще на февраль планируется набег на Екатеринбург при поддержки компании Microsoft и «СКБ Контур». 11 февраля будет однодневный тренинг по Scrum. Его будет читать Асхат Уразбаев. А сразу за ним – однодневный тренинг по Test Driven Developement от Дмитрия Лобасева.

Тренинг по Scrum стоит 2000 рублей, по TDD — 6000 рублей

Предлагаю обсудить одно из возможных решений проблемы изменяющихся требований, используемое в нашей компании.

Прежде чем перейти к описанию конкретных решений и инструментария, пара слов о политике в отношении новых требований. Пожалуй, самое важное что мы поняли, это то, что требования меняются всегда и вместо того чтобы «бороться со стихией» надо научится управлять изменяющимися требованиями. Конечно, есть ТЗ и бюджет, но часто переговоры о включении новых требований стоят дороже, чем сами изменения. С другой стороны нельзя делать все, что захочет заказчик — тогда проект вообще никогда не будет запущен. Поэтому, требованиями надо именно управлять.

Поскольку наша компания состоит из менеджеров и программистов, наше любимое занятие это организация процессов разработки и разработка средств автоматизации этой самой разработки.
Но вот уже как пару лет мы почти этим не занимаемся, хотя есть и время и средства. Все просто — после долгих поисков мы нашли решение, которое у нас стабильно работает. В рамках этого поста я не буду рассказывать обо всем — получится слишком много, а расскажу об одном из основных приемов в нашей работе. Мы называем его «базовые тикеты».

Всем привет,
Предлагаю обсудить одно из возможных решений проблемы 20/80, реально используемое в нашей компании.

Многим менеджерам проектов известен закон Парето (в общем виде формулируется как «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата»), в нашем варианте «на последние 20% проекта требуется 80% ресурсов». Проще говоря, проект по настоящему начинают делать за 3 дня до открытия. В результате: аврал, срыв сроков, низкое качество, беготня, стресс и прочие удовольствия PM'a.

Частая ошибка – дать разработчикам ТЗ и ждать пока они все сделают, а потом начать проверять. Это работает, когда проект очень маленький. Значит, надо из одного большого проекта сделать несколько маленьких. Путем проб и ошибок для себя мы нашли решение, которое условно назвали «недельные итерации» (хотя это не итерации в полном смысле, когда каждая итерация это мини-проект, включающий все фазы, от анализа до внедрения) — задачи объединяются в итерацию так, чтобы они могли быть выполнены за неделю. Теперь самое важное — итерация должна быть сделана полностью и проверена.

Добрый день, уважаемое хабросообщество!

Я уже давно являюсь читателем этого замечательного ресурса и вот, наконец, решил попробовать и свои силы. Я заметил, что тема управления проектами на Хабре освещена довольно широко в соответствующем блоге, а вот об управлении требований ничего найди не удалось. Что ж, пришло время восполнить этот пробел!

Введение

В условиях современной экономики выигрывает тот, кто производит больше с меньшими затратами. Сокращение затрат возможно как с использованием более дешевого сырья и материалов, дешевой рабочей силы, оптимизации процессов, так и их автоматизации. Автоматизация не ведет к стопроцентному сокращению затрат, но позволяет обрабатывать большее количество информации с меньшими затратами.

Основным инструментом автоматизации деятельности являются информационные системы. Информационная система — это совокупность информационного, математического, лингвистического, технического программного и другого обеспечения, а также персонала для оперативной подготовки информации для лиц, принимающих решения.

Про scrum написано много, но примеры реального применения встречаются не так часто. Некоторое время я занимался внедрением scrum в потоковой web-разработке, хотел бы поговорить на эту тему и поделиться своими мыслями.

Бум интереса к этой методологии прошел, однако до сих пор многие молодые команды легко очаровываются теоретической магией scrum, обещанием щелкать новые требования, как орешки, и не морочиться по ТЗ, бросаются внедрять на своем производстве и тут же натыкаются на трудности. Scrum вообще родился как методология разработки ПО, если вдруг кто забыл, и для успешного использования в web-разработке требует некоторой настройки. Это отдельный вопрос, в этой заметке я хотел бы затронуть другую тему и предостеречь от очевидных, в общем-то, ошибок, связанных с формированием требований к проекту. В любом описании методологии по запросу в Google говорится про важность роли scrum master'a и изложении требований к проекту в виде историй, но никто не говорит о том, откуда берутся требования, и нужно ли вообще их реализовывать. Без понимания этого момента сделать что-то путное вряд ли получится, и методология тут ни при чем.

Добрый день, %userName%.

В своем предыдущем топике по Управлению требованиями к IT-проектам я затронул тему идентификации требований с использованием концептов и повторное использование уже реализованных требований из одного проекта в другом. В данном топике я бы хотел развить данную тему.

Далее идет немного математики, теоретических выкладок и много букв.

Есть идея, провести в Киеве тренинг по UML и управлению требованиями в IT. Идея возникла после того, как пришлось столкнутся с выпускниками некоторых бизнес-курсов, семинаров и тренингов, и стало понятно, что можем сделать лучше и качественнее. Собственно, так как задумка пока еще на уровне идеи, то есть несколько вопросов:

• Что было бы интересно послушать на тренинге именно Вам?
• В каком формате Вам был бы интересны занятия: тренинг, двухдневный курс, недельный курс и т.д.?
• Что должно быть в тренинге, что бы лично Вам захотелось его посетить?
• Стоит ли разделить UML и управление требованиями на два курса или совместить в одном?

Возможностей и знаний много, но хотелось бы сделать полезный и интересный курс, из которого слушатели могли бы вынести максимум пользы.

Те, кто занимается развитием технологического бизнеса (разработка ПО, интернет-сервисы и т.д.), наверняка читали такие книги, как «Преодоление пропасти» и «Внутри торнадо» авторства Джефри Мура. Из этих книг читателю известна модель жизненного цикла технологий на рынке (хотя сама модель появилась раньше, в книге другого автора, чего сам Мур в своих произведениях не скрывает).

Если вам эти книги не знакомы, то модель легко понимается по схеме (взята с сайта www.techlifecycles.com):

Эпиграф: Верблюд — это лошадь, сделанная по всем требованиям заказчика.

Если вы когда-либо участвовали в интернет-проектах — любой сложности и в любой роли — вы наверняка знаете, что определение целей и границ будущей системы — это фундамент решения любой проектной задачи. Сбор, анализ и управление требованиями — та часть проекта, в которой опыт команды и методология играют определяющую роль: цена ошибки на этом участке очень высока.

Опытные и слаженные команды в России есть, а вот методологии управления требованиями — единой, прозрачной и удобной в использовании — до сих пор нет. Даже в одной организации от проекта к проекту меняются инструменты и методы управления требованиями, роли участников процесса, и, как следствие, нашим организациям не хватает «зрелости» — гарантии повторяемости проектных процедур со стабильно высоким качеством выдаваемых результатов.

Зачем менять то, что работает? Действительно, поговорка гласит: «Не трогай матчасть и она тебя не подведет». «Есть у нас Redmine и мы им пользуемся. Так зачем же нам менять его на YouTrack, да еще и за деньги?» — резонный вопрос, задаваемый коллегами. Вопрос известен и ответ на него очевиден: незачем. Но давайте взглянем на проблему с другой стороны.

Всем привет! Продолжаю тему постов про подход к сбору требований под названием Spec By Example. Я уже делал вебинар про общие ценности данного подхода (о нем чуть ниже), а сегодня хочу показать как оно на работает на примере достаточно простого, на первый взляд требования. Самого требование звучит очень просто:

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

В принципе, ничего сложного, но давайте посмотрим, какие сюрпризы таятся внутри!

Эту статью я хочу посвятить временами нелегкой, но увлекательной профессии ИТ-аналитика. На Хабре не так много материалов по данной дисциплине. К примеру, по управлению проектами – на порядок больше. Но выложенные недавно две статьи (раз и два), похоже, вызвали интерес, посему я тоже хотел бы внести свой скромный вклад. Сам работаю более 8 лет в роли аналитика, так что постараюсь не потратить Ваше время зря.
Не стану пересказывать теорию (ее можно почерпнуть в замечательной книге Вигерса или в BABOK). Мне бы хотелось сосредоточиться на практической стороне вопроса – описать выжимку из «боевого» опыта, как своего, так и некоторых других людей, с которыми мне посчастливилось работать.

За 3 года существования летнего аналитического фестиваля мы накопили большое количество записей интересных выступлений. И сегодня хотим поделиться с вами подборкой:

1. Предпроектные работы

• Юрий Веденин. Как написать хорошее коммерческое предложение
• Константин Быченков. Цели проекта: Что? Зачем? Как?

2. Выявление требований

• Илья Корнипаев. Креативные техники сбора требований
• Ирина Левенец. Бесконтактное обследование
• Юрий Веденин. Анализ пользователей

Введение

При работе с требованиями возможно применение различных методов их организации: от метода полного хаоса, до интеграции требований с программным кодом (статья Пять уровней зрелости требований). Постепенно улучшая работу с требованиями, обычно, в процесс начинают внедрять различные новые методологии и инструменты. Одним из классов инструментов, призванных упростить работу с требованиями, являются специально обученные «зверьки»: Системы Управления Требованиями (СУТ). Основными возможностями таких систем являются:

• Создание более простой, чем целый документ, единицы управления проектом (требование). Прочитать и подтвердить одно требование намного проще, чем согласовывать целое Техническое задание.
• Указание связей между требованиями. Такая возможность позволяет отслеживать изменения в связанных требованиях. Т.е. если что-то изменилось, то далее система может выделять все элементы, связанные с измененным, как подозреваемые на изменение.
• Выбор представления набора взаимосвязанных требований. При большом количестве требований иногда необходимо представить всю картину их взаимосвязи. Кому-то удобнее просмотреть эту информацию в виде таблицы (матрицы трассировки), кому-то в виде иерархического дерева, кому-то в виде сетевых графиков (статья Системы управления требованиями: что и зачем?).

Среди данных программ есть известные «Монстро-звери», такие как: IBM Rational DOORS, Borland Caliber, Polarion Requirements и др. с большим количеством функциональных возможностей. Такие системы, как правило, являются хорошо зарекомендовавшими себя, но дорогостоящими. Однако среди данного перечня есть маленькие, бесплатные, малоизвестные, но очень полезные «зверьки» типа Axiom.

Публикуем статью, написанную на основании предыдущего доклада Ирины Суровой с прошлой конференции Analyst Days. В этом году Ирина выступает не только в роли докладчика, но и члена программного комитета будущей московской конференции.

Александр Александров — «дедушка тестирования» в СНГ делал доклад на юбилейной 15-ой SQA Days в Москве.

Слайды:
www.slideshare.net/VLDCORP/ss-33747358

Видео выступления:

Понятие BPM (Business Process Management) все более плотно входит в жизнь больших и малых корпораций. Суть его в том, чтобы рассматривать бизнес-процессы компании, как активы, используя которые можно увеличить прибыльность своего бизнеса. Инструмент, который вы для этого используете, может быть любым: лист бумаги, текстовый документ, Visio или любое другое средство создания диаграмм… Но есть класс инструментов, которые специально предназначены для того, чтобы послужить инструментом для трансформации вашего бизнеса — это BPM-платформы.
Задача для такой платформы ставится двояко: с одной стороны необходимо визуализировать бизнес-процесс, а с другой стороны — его нужно исполнить.



Я не буду описывать весь рынок таких платформ, это неплохо сделано в статье независимого агентства Gartner, откуда я взял иллюстрацию выше (полный текст можно скачать с сайта Pega или IBM, но потребуется регистрация, или нагуглить самостоятельно по заголовку: “Gartner BPM Magic Quadrant 2014”).
Цель же данной статьи — провести сравнение технических возможностей двух лидирующих платформ, Pega и IBM BPM, доступных на текущий момент (осень 2014), с точки зрения опыта их использования в проектах по автоматизации бизнес-процессов.

Если вы задумали трансформировать свой бизнес или вам нужно IT-решение, которое позволит достичь бизнес-целей, поставленных высшим руководством, или вы просто интересуетесь BPM-решениями, то добро пожаловать под кат.

Чем грозит долгострой в разработке и с какими трудностями предстоит столкнуться на этом пути? Как бизнес-аналитик компании, которая 15 лет занимается разработкой и поддержкой одного продукта (СЭД), я решила поделиться своими мыслями и примерами из практики. Проблематика управления требованиями в любых программных продуктах с длительным периодом реализации – актуальный вопрос для аналитиков, руководителей проектов и владельцев продуктов. И, возможно, для непосредственных партнёров и заказчиков Docsvision, ожидающих выхода новых версий и заинтересованных в появлении новой функциональности.