Product lifecycle ws software development (sef)Dmitry Bezuglyy
В предлагаемом докладе делается сравнительный анализ общепринятого подхода к построению процесса создания новых продуктов и наиболее распространенных процессов разработки ПО таких как OUP, MSF и Scrum.
Product lifecycle ws software development (sef)Dmitry Bezuglyy
В предлагаемом докладе делается сравнительный анализ общепринятого подхода к построению процесса создания новых продуктов и наиболее распространенных процессов разработки ПО таких как OUP, MSF и Scrum.
В презентации представлен методологический подход и опыт автора по комбинированному использованию иерархических (водопад, набегающая волна) и гибких (Scrum, Agile) подходов для разработки, выпуска, сопровождения и развития программных продуктов и приложений для мобильных устройств.
Соотнесение уровня изменений для компании: стратегическое, тактическое, операционное и управления портфелями - программами - проектами.
Managing organizational changes through portfolio, programs, and projects
Optimizing Your Management for Business ExpansionAmanda Collette
Efficient business management is a must especially if you're planning to expand. Among the first things you should establish to ensure your business runs smoothly are systems for your employees covering job descriptions, delegation, compensation and training. Read this document from Alliance Accounting for details.
В презентации представлен методологический подход и опыт автора по комбинированному использованию иерархических (водопад, набегающая волна) и гибких (Scrum, Agile) подходов для разработки, выпуска, сопровождения и развития программных продуктов и приложений для мобильных устройств.
Соотнесение уровня изменений для компании: стратегическое, тактическое, операционное и управления портфелями - программами - проектами.
Managing organizational changes through portfolio, programs, and projects
Optimizing Your Management for Business ExpansionAmanda Collette
Efficient business management is a must especially if you're planning to expand. Among the first things you should establish to ensure your business runs smoothly are systems for your employees covering job descriptions, delegation, compensation and training. Read this document from Alliance Accounting for details.
Создание СУИБ в организации на примере 5 реализованных проектов LETA 2010-201...LETA IT-company
Презентация Акатьевой Марии,
заместителя директора департамента продуктов и услуг компании LETA
проведенная в рамках конференции «Грани ИБ Законодательство, процессы, технологии» 13-15 октября 2011 г. в «Атлас Парк-Отель»
Mykola Mytko — "Быть, а не казаться Agile" it-network
Николай рассказал, что же значит Agile и как правильно его внедрять.
✔️Agile — это обучение и выполнение работы через опыт.
✔️Изменения - это нормально, нужно ошибаться, делать выводы и учиться.
✔️Agile — это мышление. Есть 2 подхода к Agile: делать и быть.
✔️Попробуйте модель обучения СюХаРи.
✔️Задача Agile коучей - научить людей мыслить.
Гибкие методологии при создании ИТ продукта. Сравнения. Основные инструменты.
Дашкин Руслан Валерьевич, тренер-консультант, сертифицированный преподаватель АСКОН.
18 сентября 2014 г.
Акатов Николай Борисович, к.э.н, руководитель Президентской программы по проектно-ориентированному обучению, доцент кафедры «Менеджмента и маркетинга» Пермского национального исследовательского политехнического университета
григорьев андрей, юмисофт, основные ошибки ведения It проектов - от документа...New Business Idea
Основные ошибки ведения IT-проектов - от документации до коммуникаций.
* Сбор и формирование требований к продукту;
* выработка стратегии;
* начальное проектирование;
* документирование процесса;
* построение схемы ролей и коммуникаций;
* дизайн проекта;
* программирование;
* примеры из жизни.
Большие компании и корпорации имеют сложную Орг структуру, множество Бизнес-процессов (БП), Систем, Данных. Все это очень тесно переплетно и сильно влияет друг на друга. Изменили структуру отдела или заменили людей, забыли про БП - получили проблему. Изменили Систему, забыли про другую Систему - получили проблему. Поменяли БП, забыли про людей и Системы - получили проблему. И т.д....
Чтобы все это увязать и управлять придумано много фреймворков - Zachman, TOGAF, FEA и т.д. И везде требования ставятся во главу угла. Но нужны ли все практики и такие сложные фреймвоки? В каких российских компаниях они внедрены? Мне кажется, что можно взять из этих фреймворков все самое лучше и необходимо и построить свой подход по управлению корпоративной архитектурой.
Аналитики не нужны требования (поставь запятую, где нужно)Alexander Baikin
Я часто слышу: «А зачем нам Аналитики? Хорошие разработчики — вот это сила!» или «Зачем нам требования? Мы и так по Agile шарашим!».
Тогда почему многие жалуются:
«Мы одно и тоже по нескольку раз переделываем!»,
«Заказчик все время орет, что мы делаем не то, что ему нужно!»,
«Мы как будто разговариваем с Заказчиком на разных языках!»,
«Да блин, этот Заказчик сам не знает, что хочет!»,
«У нас постоянно расширяется скоуп проекта!»,
«Мы развиваем большой проект, но уже никто не знает, как он работает! В одном месте правим, в другом ломается!»,
«Но мы же договаривались о другом!!!»
и т. д.
Чтобы решить эти и другие проблемы на проекте как раз нужны Аналитики, которые пишут правильные требования.
Я вас не убедил, что вам нужны правильные Аналитики и хорошие требования?! Тогда послушайте вебинар:
Задача Джоэля Спольски
Зачем нужны аналитики?
Кто такой хороший аналитик?
Как бороться с извечными проблемами?
Как быть с Agile?
Описание бизнес-правил и дополнительных требований в вариантах использования (use cases)
Все прекрасно знают, что варианты использования (ВИ) отлично описывают функциональные требования, но что делать с не функциональными требованиями? Кто-то пишет их отдельно, кто-то включает в текст спецификации ВИ, кто-то про них вообще забывает. В докладе будет рассказано про основные подходы описания бизнес-правил в ВИ:
* Отделенные бизнес-правила
* Размазанные бизнес-правила
* Привязанные бизнес-правила
* Группированные бизнес-правила
* Решения вместо бизнес-правил
* Как делаю я?
Requirements Engineering: People Processes ToolsAlexander Baikin
Треугольник работы с требованиями: люди, процессы, инструменты
Многие начинающие аналитики и менеджеры делают огромную ошибку, возлагая большие надежды на инструменты управления требованиями и проектом. На самом деле нужно сначачала найти (сделать) хороших людей, потом наладить процессы, а далее уже искать способы автоматизации рутинных операций (инструменты).
В докладе:
почему аналитики любят инструменты,
рекомендации по тому, что должен знать и уметь хороший аналитик,
как наладить процесс разработки и управления требованиями
какие необходимы инструменты управления требованиями и для каких проектов
Есть мнение, что совещание - это лучшее место отдохнуть от работы, показать себя, порисовать у доски, перекусить и произвести впечатление на коллег. На самом деле, совещание - это тяжелая работа всех его участников. И чтобы эта работа привела к успешному результату, необходимо знать и применять несложные приемы проведения совещаний.
В докладе будет раскрыта психология проведения совещаний, техники, позволяющие собрать максимальное число мнений и приемы для принятия решения, которое бы удовлетворяло всех его участников.
В презентации:
• Что такое Концепция требований, для чего она нужна и что туда должно войти?
• Какие техники сбора и анализа требований можно использовать на старте проекта?
• Как можно формировать ТЗ к такому проекту и что туда должно войти?
• Какие моменты нужны учесть и какие инструменты можно использовать при управлении требований?
* Показаны и рассказаны реальные примеры докладчика.
Из данной презентации Вы узнаете:
Кто такой Аналитик?
Чем он занимается?
Что он должен знать и уметь?
Почему требования так важны?
Что Вас ждет дальше?
Презентация предназначена для знакомства с ролью Аналитика (или ИТ специалиста, работающего с требованиями) и презентации полного курса «Разработка и управление требований к ПО".
Запись вебинара: http://vimeo.com/61915197
* Классификация нефункциональных требований
* Шаблоны нефункциональных требований
* Численные значения нефункциональных требований
* Связи между нефункциональными и функциональными требованиями
* Влияние различных категорий нефункциональных требований друг на друга
* Атрибуты качества продукта и нефункциональные требования
* Роли в проекте, с которыми взаимодействует аналитик при выявлении и уточнении нефункциональных требований
Requirement Managament System based on Wiki (Confluence+Jira)Alexander Baikin
Что такое Система Управление Требованиями (СУТ)?
Какие есть еще СУТ кроме Telelogic Doors, Rational RequisitePro и Borland Together?
Как Wiki + Issue Tracker + SVN использовать для СУТ?
Варианты Использования (use cases) - это наиболее популярный метод описания пользовательских требований в последние нескольких лет. Но только единицы владеют этим <<искусством>>. Да-да, не побоюсь этого слова, т.к. при правильном применении варианты использования дают неоспоримые преимущества: интуитивно понятны заказчикам и разработчикам; помогают выявить функциональные требования; диаграмма
помогает представить требования в целом; Аналитик фокусируется на потребностях Пользователя, а не на Системе и т.д.
На мастер классе будут даны основные понятия вариантов использования, их шаблоны и конечно будет разобран пример моделирования и описания вариантов использования для одной из популярных веб систем.
Для проведения полноценного тренинга обращайтесь ко мне.
Типичные проблемы Выявления Требований и их РешениеAlexander Baikin
На протяжении многих лет написано огромное количество книг и статей по методам Выявления Требований и их применению, но все хорошо в теории. На практике же Аналитики, раз за разом, натыкаются на одни и те же грабли: не выявлены все требования; заказчик не знает, что хочет; «да, но …» синдром и т.д. В данном докладе описаны основные проблемы, с которыми сталкиваются Аналитики на этапе Выявления Требований и предложены пути их решения.
В докладе предложены последовательность и практические действия по созданию и описанию процесса управления требованиями для работы конкретной команды, а так же описаны действия по планированию и адаптации процесса управления требованиями для использования в условиях конкретного проекта.
Место Аналитика в разработке
Почему так получается?
Требования
Работа с требованиями
Кто такой Аналитик?
Системный Ан. vs Бизнес Ан.
Основные функции Бизнес Ан.
Литература и Профстандарты
2. Пара слов об авторе…
Зовут
• Архипов Игорь
Образование
• Высшая Школа Экономики
Специализация
• Моделирование и оптимизация бизнес-процессов
Опыт работы
• Баннерообменное ПО
• Электронная коммерция
• Купонный бизнес
Летний Аналитический Фестиваль 2012
3. О чем речь
Требование является ключевой
коммуникацией между заказчиком и
разработчиком системы
Летний Аналитический Фестиваль 2012
4. Определение процесса
Бизнес-процесс - это совокупность
взаимосвязанных мероприятий или
задач, направленных на создание
определенного продукта или услуги для
удовлетворения потребностей клиента
4
Летний Аналитический Фестиваль 2012
5. Процессный уровень
Инжиниринг Управление
требований требованиями
• Идентификация • Управление
стейкхолдеров изменениями Ad hoc
• Сбор • Контроль ревизия
требований версий
• Организация • Контроль требований
требований состояний На момент
• Верификация • Контроль над сдачи/приѐмки
требованиями системы и при
Начало работ по Начало реализации выводе ее из
проекту требований эксплуатации
Летний Аналитический Фестиваль 2012
6. Окружение и сервисы процесса
Доступ к
требованиям
Фиксация Работа с Актуализация
требований требованиями требований
Летний Аналитический Фестиваль 2012
7. Реализации процесса управления требованиями
Реализации процесса
ТРАДИЦИОННАЯ РАЗРАБОТКА
Планирова Проектиров Тестирован
Анализ Разработка Внедрение
ние ание ие
RAD 24 часа
Документирование
Совместная требований недели
2-4
разработка
Продуктовый Спринт Готовый
бэклог Итеративная Спринты
бэклог Проектирование
разработка
продукт
Пользовательское
ревью
Разработка
Восстановление требований
Самоорганизующаяся модель разработки
Модель «быстрой разработки»
Итеративная модель
Каскадная модель
Модель «Гибкой
(Обратный инжиниринг)
Летний Аналитический Фестиваль 2012
8. Все подходы отличаются…
• Разные подходы реализуемы и в целом
эффективны в разных условиях
• В них различны:
• Стоимость внесения изменений на разных
этапах проекта
• Требования, предъявляемые к команде
разработки, организационной и
информационной среде, стейкхолдерам …
Летний Аналитический Фестиваль 2012
10. Мир сошёл с ума?
Летний Аналитический Фестиваль 2012
11. Так давайте быть готовыми!
Неспособность менять процессы
ведет к исчезновению компаний с
рынка
Летний Аналитический Фестиваль 2012
12. За счёт чего?
– способность восстановиться после
шока, изменения
Упругость
Стрессоустойчивость
Летний Аналитический Фестиваль 2012
13. Как же этого добиться?
Иерархия Сеть
• Безопасно • Очень быстро
• Но меееедленно • Сверх реагирование
Есть контроль, Нет контроля,
нет дистрибуции сигнала есть дистрибуции сигнала
Летний Аналитический Фестиваль 2012