Управление проектами → Курс бизнес анализа в Киеве
Есть идея, провести в Киеве тренинг по UML и управлению требованиями в IT.
Идея возникла после того, как пришлось столкнутся с выпускниками некоторых бизнес-курсов, семинаров и тренингов, и стало понятно, что можем сделать лучше и качественнее.
Собственно, так как задумка пока еще на уровне идеи, то есть несколько вопросов:
Возможностей и знаний много, но хотелось бы сделать полезный и интересный курс, из которого слушатели могли бы вынести максимум пользы.
Идея возникла после того, как пришлось столкнутся с выпускниками некоторых бизнес-курсов, семинаров и тренингов, и стало понятно, что можем сделать лучше и качественнее.
Собственно, так как задумка пока еще на уровне идеи, то есть несколько вопросов:
- Что было бы интересно послушать на тренинге именно Вам?
- В каком формате Вам был бы интересны занятия: тренинг, двухдневный курс, недельный курс и т.д.?
- Что должно быть в тренинге, что бы лично Вам захотелось его посетить?
- Стоит ли разделить UML и управление требованиями на два курса или совместить в одном?
Возможностей и знаний много, но хотелось бы сделать полезный и интересный курс, из которого слушатели могли бы вынести максимум пользы.
Ненормальное программирование → Использование семантической аннотации для идентификации требований
Добрый день, %userName%.В своем предыдущем топике по Управлению требованиями к IT-проектам я затронул тему идентификации требований с использованием концептов и повторное использование уже реализованных требований из одного проекта в другом. В данном топике я бы хотел развить данную тему.
Далее идет немного математики, теоретических выкладок и много букв.
Agile → Scrum и управление требованиями в web-разработке
Про scrum написано много, но примеры реального применения встречаются не так часто. Некоторое время я занимался внедрением scrum в потоковой web-разработке, хотел бы поговорить на эту тему и поделиться своими мыслями.
Бум интереса к этой методологии прошел, однако до сих пор многие молодые команды легко очаровываются теоретической магией scrum, обещанием щелкать новые требования, как орешки, и не морочиться по ТЗ, бросаются внедрять на своем производстве и тут же натыкаются на трудности. Scrum вообще родился как методология разработки ПО, если вдруг кто забыл, и для успешного использования в web-разработке требует некоторой настройки. Это отдельный вопрос, в этой заметке я хотел бы затронуть другую тему и предостеречь от очевидных, в общем-то, ошибок, связанных с формированием требований к проекту. В любом описании методологии по запросу в Google говорится про важность роли scrum master'a и изложении требований к проекту в виде историй, но никто не говорит о том, откуда берутся требования, и нужно ли вообще их реализовывать. Без понимания этого момента сделать что-то путное вряд ли получится, и методология тут ни при чем.
Бум интереса к этой методологии прошел, однако до сих пор многие молодые команды легко очаровываются теоретической магией scrum, обещанием щелкать новые требования, как орешки, и не морочиться по ТЗ, бросаются внедрять на своем производстве и тут же натыкаются на трудности. Scrum вообще родился как методология разработки ПО, если вдруг кто забыл, и для успешного использования в web-разработке требует некоторой настройки. Это отдельный вопрос, в этой заметке я хотел бы затронуть другую тему и предостеречь от очевидных, в общем-то, ошибок, связанных с формированием требований к проекту. В любом описании методологии по запросу в Google говорится про важность роли scrum master'a и изложении требований к проекту в виде историй, но никто не говорит о том, откуда берутся требования, и нужно ли вообще их реализовывать. Без понимания этого момента сделать что-то путное вряд ли получится, и методология тут ни при чем.
Разработка → Управление требованиями к IT-проектам из песочницы
Добрый день, уважаемое хабросообщество!
Я уже давно являюсь читателем этого замечательного ресурса и вот, наконец, решил попробовать и свои силы. Я заметил, что тема управления проектами на Хабре освещена довольно широко в соответствующем блоге, а вот об управлении требований ничего найди не удалось. Что ж, пришло время восполнить этот пробел!
В условиях современной экономики выигрывает тот, кто производит больше с меньшими затратами. Сокращение затрат возможно как с использованием более дешевого сырья и материалов, дешевой рабочей силы, оптимизации процессов, так и их автоматизации. Автоматизация не ведет к стопроцентному сокращению затрат, но позволяет обрабатывать большее количество информации с меньшими затратами.
Основным инструментом автоматизации деятельности являются информационные системы. Информационная система — это совокупность информационного, математического, лингвистического, технического программного и другого обеспечения, а также персонала для оперативной подготовки информации для лиц, принимающих решения.
Я уже давно являюсь читателем этого замечательного ресурса и вот, наконец, решил попробовать и свои силы. Я заметил, что тема управления проектами на Хабре освещена довольно широко в соответствующем блоге, а вот об управлении требований ничего найди не удалось. Что ж, пришло время восполнить этот пробел!
Введение
В условиях современной экономики выигрывает тот, кто производит больше с меньшими затратами. Сокращение затрат возможно как с использованием более дешевого сырья и материалов, дешевой рабочей силы, оптимизации процессов, так и их автоматизации. Автоматизация не ведет к стопроцентному сокращению затрат, но позволяет обрабатывать большее количество информации с меньшими затратами.
Основным инструментом автоматизации деятельности являются информационные системы. Информационная система — это совокупность информационного, математического, лингвистического, технического программного и другого обеспечения, а также персонала для оперативной подготовки информации для лиц, принимающих решения.
Блог компании QSOFT → Возможный способ обойти правило Парето
Всем привет,
Предлагаю обсудить одно из возможных решений проблемы 20/80, реально используемое в нашей компании.
Многим менеджерам проектов известен закон Парето (в общем виде формулируется как «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата»), в нашем варианте «на последние 20% проекта требуется 80% ресурсов». Проще говоря, проект по настоящему начинают делать за 3 дня до открытия. В результате: аврал, срыв сроков, низкое качество, беготня, стресс и прочие удовольствия PM'a.
Частая ошибка – дать разработчикам ТЗ и ждать пока они все сделают, а потом начать проверять. Это работает, когда проект очень маленький. Значит, надо из одного большого проекта сделать несколько маленьких. Путем проб и ошибок для себя мы нашли решение, которое условно назвали «недельные итерации» (хотя это не итерации в полном смысле, когда каждая итерация это мини-проект, включающий все фазы, от анализа до внедрения) — задачи объединяются в итерацию так, чтобы они могли быть выполнены за неделю. Теперь самое важное — итерация должна быть сделана полностью и проверена.
Предлагаю обсудить одно из возможных решений проблемы 20/80, реально используемое в нашей компании.
Многим менеджерам проектов известен закон Парето (в общем виде формулируется как «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата»), в нашем варианте «на последние 20% проекта требуется 80% ресурсов». Проще говоря, проект по настоящему начинают делать за 3 дня до открытия. В результате: аврал, срыв сроков, низкое качество, беготня, стресс и прочие удовольствия PM'a.
Частая ошибка – дать разработчикам ТЗ и ждать пока они все сделают, а потом начать проверять. Это работает, когда проект очень маленький. Значит, надо из одного большого проекта сделать несколько маленьких. Путем проб и ошибок для себя мы нашли решение, которое условно назвали «недельные итерации» (хотя это не итерации в полном смысле, когда каждая итерация это мини-проект, включающий все фазы, от анализа до внедрения) — задачи объединяются в итерацию так, чтобы они могли быть выполнены за неделю. Теперь самое важное — итерация должна быть сделана полностью и проверена.
Блог компании QSOFT → Полезные советы: управление проектами в условиях изменяющихся требований
Предлагаю обсудить одно из возможных решений проблемы изменяющихся требований, используемое в нашей компании.
Прежде чем перейти к описанию конкретных решений и инструментария, пара слов о политике в отношении новых требований. Пожалуй, самое важное что мы поняли, это то, что требования меняются всегда и вместо того чтобы «бороться со стихией» надо научится управлять изменяющимися требованиями. Конечно, есть ТЗ и бюджет, но часто переговоры о включении новых требований стоят дороже, чем сами изменения. С другой стороны нельзя делать все, что захочет заказчик — тогда проект вообще никогда не будет запущен. Поэтому, требованиями надо именно управлять.
Поскольку наша компания состоит из менеджеров и программистов, наше любимое занятие это организация процессов разработки и разработка средств автоматизации этой самой разработки.
Но вот уже как пару лет мы почти этим не занимаемся, хотя есть и время и средства. Все просто — после долгих поисков мы нашли решение, которое у нас стабильно работает. В рамках этого поста я не буду рассказывать обо всем — получится слишком много, а расскажу об одном из основных приемов в нашей работе. Мы называем его «базовые тикеты».
Прежде чем перейти к описанию конкретных решений и инструментария, пара слов о политике в отношении новых требований. Пожалуй, самое важное что мы поняли, это то, что требования меняются всегда и вместо того чтобы «бороться со стихией» надо научится управлять изменяющимися требованиями. Конечно, есть ТЗ и бюджет, но часто переговоры о включении новых требований стоят дороже, чем сами изменения. С другой стороны нельзя делать все, что захочет заказчик — тогда проект вообще никогда не будет запущен. Поэтому, требованиями надо именно управлять.
Поскольку наша компания состоит из менеджеров и программистов, наше любимое занятие это организация процессов разработки и разработка средств автоматизации этой самой разработки.
Но вот уже как пару лет мы почти этим не занимаемся, хотя есть и время и средства. Все просто — после долгих поисков мы нашли решение, которое у нас стабильно работает. В рамках этого поста я не буду рассказывать обо всем — получится слишком много, а расскажу об одном из основных приемов в нашей работе. Мы называем его «базовые тикеты».
Блог компании ScrumTrek → Февральские Тренинги
Москва – управление требованиями и Scrum
10 февраля в Москве будет однодневный тренинг по Scrum. Сразу за ним 11–12 февраля двухдневный тренинг по требованиям в Agile (Agile Requirements). Вести тренинги будет Никита Филиппов.
Что будет интересного?
Стоимость тренинга — 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 рублей
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 рублей
НЛО прилетело и опубликовало эту надпись здесь.
Подкасты → Agile Podcast #5. Сезон 1. Требования в Agile
Участники:
Асхат Уразбаев, Денис Бесков, Денис Миллер, Никита Филиппов
Темы
* Классический аналитик
* Кто создаёт требования и делает сбор, когда
* Управление требованиями
* Управление изменениями требованиями
Денис Бесков — руководитель отдела системного анализа Лаборатории Касперского, евангелист системного анализа разработки ПО в России.
(RSS для iTunes)
Асхат Уразбаев, Денис Бесков, Денис Миллер, Никита Филиппов
Темы
* Классический аналитик
* Кто создаёт требования и делает сбор, когда
* Управление требованиями
* Управление изменениями требованиями
Денис Бесков — руководитель отдела системного анализа Лаборатории Касперского, евангелист системного анализа разработки ПО в России.
(RSS для iTunes)
прослушан 63 раза
Управление проектами → Управление требованиями корпоративного интернет-проекта
Цель данной заметки (или конспекта) — предложить строгим (но конструктивным :-) критикам перечень группы требований и способы их структурирования, предъявляемых к коммерческому корпоративному сайту. Планируемый жизненный цикл сего текста — сначала она будет доступна только участникам соответствующего блога. Затем, всем. Так что спешите критиковать.
Эти требования важно предусмотреть при проектировании сайта, и задокументировать в концепции сайта и техническом задании на проект. Публикация не претендует на полноту и завершенность, однако вместе мы сможем ее приблизить к идеалу.
Кто в проекте работает с требованиями? Бизнес-аналитик. Однако, на малых проектах его функцию выполняют технические директора, директора по разработке, менеджеры проектов. Задачи аналитика:
Эти требования важно предусмотреть при проектировании сайта, и задокументировать в концепции сайта и техническом задании на проект. Публикация не претендует на полноту и завершенность, однако вместе мы сможем ее приблизить к идеалу.
Задачи аналитика при проектировании сайта
Кто в проекте работает с требованиями? Бизнес-аналитик. Однако, на малых проектах его функцию выполняют технические директора, директора по разработке, менеджеры проектов. Задачи аналитика:
- Идентифицировать все источники требований
- Выявить требований (часть требований существует, но клиент их не всегда осознает — в этом поможет опыт аналитика по веб-проектам)
- Сформулировать требования и уточнить их
- Назначить приоритет требованиям.
- Сформулировать технические задания