Как возникла необходимость отойти от классической Каскадной Модели жизненного цикла разработки
В 2009 году мне предложили выбрать и реализовать один из «гиблых» проектов. Приставку «Гиблый» каждый получил за то, что раньше за них уже пробовали браться, но ничего не вышло.
В больших проектах причина неудачи чаще лежит не в профессиональном уровне команды, а в готовности Заказчика дойти до конца и получить отдачу от вложенных собственных усилий. Ситуация должна сложится так, что цели проекта должны совпасть с кратко и среднесрочными целями Заказчика.
Большой пример: только оказавшись под санкциями и цене нефти в 50 долларов за баррель (против 110 ранее) руководство страны перешло от рассуждений и неспешных телодвижений к активным действиям по развитию высокотехнологичной экономики.
Так и один из моих Заказчиков созрел и я взялся сделать для него проект по разработке нового функционального модуля Корпоративной Информационной Системы (ERP-системы), который должен был добавить 400 новых пользователей системе и обеспечить проверку 40 000 ипотечных кредитов в год.
Спустя 2 месяца у нас уже была первая версия Технического Задания, которая состояла из 200 страниц основного ТЗ и 200 страниц приложений к нему с описаниями различных форм и бизнес алгоритмов. Надо сказать, что до этого я видел основное ТЗ на всю корпоративную ИС и на момент внедрения оно состояло всего из 600 страниц. Поэтому ещё в ходе разработки ТЗ на модуль всё чаще возникала мысль, что с таким объемом требований велика вероятность, что мы не взлетим, а если взлетим, то очень не быстро.
После того как ребята из нашего выделенного центра разработки в EPAM озвучили трудоемкость реализации в 6500 часов и длительностью 1,5 года разработки стало ясно что точно не взлетим.
Бизнес-процесс и процедуры, которые нужно было автоматизировать, были живыми и постоянно адаптировались под изменения внутри компании и вовне, как под рыночные, так и под требования Центрального Банка России.
Через полтора года те «штаны», которые мы сошьем для них будут им либо малы либо не подойдут вообще, а это выброшенные на ветер деньги, время и ресурсы разработки. Достаточно один раз попробовать через это пройти, чтобы понять что это точно не вариант и карьерное самоубийство в рамках компании. После этого ничего серьезного уже не доверят.
Отсюда последовал вывод, что Waterfall годится для небольших проектов и тех, где автоматизируемые процессы не подвержены постоянным изменениям. Нужно было что-то другое, предполагающее раннюю доставку и при этом, чтобы это было понятно всем кто вовлечен в процесс разработки. В идеале Waterfall, но не Waterfall. Им оказался Rational Unified Process.
Два слова о контексте
Компания разрабатывает и развивает собственную корпоративную ИС взяв за основу платформу Pivotal CRM. Причина самостоятельной разработки КИС и дополнительных функциональных модулей к ней это отсутствие на отечественном рынке каких бы то ни было альтернатив и дорогая стоимость приобретения западных аналогов в 2000-е годы.
Помимо сотрудников компании в КИС работают сотрудники более 200 компаний Партнеров по всей стране (B2B). Как упоминалось выше, разработка находится на аутсорсинге в компании EPAM Systems. На стороне компании оставлены бизнес-аналитика и управление проектами.
Что не так с методологией Waterfall (особенности и недостатки каскадной модели)
Эта методология Мать для всех последующих и является универсальной. По этой методологии были разработаны первые программы.
Основы, которые держат эту Методологию и заложены в ней:
- От начала и до конца спроектированный конечный результат.
(Архитектурный Проект Результата)
- Инструкция по сборке конечного результата.
(План реализации проекта)
- Последовательная реализация проекта.
Анализ, проектирование, сборка, тестирование и передача в эксплуатацию
- Сопротивление изменениям в Проекте Результата и Инструкции по сборке в процессе реализации проекта.
Изменения в проекте
- Результат проекта доставляется единой поставкой в конце проекта.
Динамика сборки результата проекта
Для того, чтобы реализовать длительный проект по Waterfall со сроками более 1-2 лет нужно сделать предположения о той бизнес-среде, потребностях клиентов и компании, которые будут на момент завершения проекта (допущения связанные с бизнес-целями Проекта). Также нужно предположить и заложить ориентировочную стоимость ресурсов на каждый год жизни проекта (допущения связанные с планом реализации Проекта).
Чем больше содержание проекта, трудоемкость и сроки реализации, тем больше допущений закладывается в проект, которые могут оказаться как верными так и не верными. Самые критичные — это допущения связанные с бизнес-целями Проекта, если они оказываются не верными то все вложенные в проект ресурсы, деньги и время обесцениваются.
Попытки внести существенные изменения в Проект Конечного Результата по ходу реализации требуют цикла перепроектирования Конечного Результата и Инструкции по сборке. Существенные изменения часто не позволяют продолжать уже начатые по первоначальному плану работы и приводят к переделке того, что уже было сделано.
По этой причине команда проекта и стейкхолдеры сопротивляются существенным изменениям в проекте, только если обстоятельства и сыгравшие/обнаружившиеся риски не ставят весь проект под сомнение в необходимости его продолжать. Когда изменения всё-таки вносятся они чаще всего приводят к дополнительным затратам и удлинению сроков. Возросшая длительность опять порождает новые требования и новые изменения. Это словно замкнутый круг из которого невозможно выйти победителем. Отсюда происходит постоянное вылетание из первоначальных сроков и бюджета.
Поэтому эта Методология подходит проектам строительства зданий и сооружений, типа атомной электростанции, но не годится для разработки Продуктов под быстро меняющиеся среды, в которых они будут применяться. У которых срок жизни Продукта в изначальном виде без внесения изменений меньше 5 лет.
Идея итеративной разработки призвана устранить связанные с допущениями риски, дать возможность быстро получить обратную связь, сократить масштаб потерь от неверных бизнес допущений и внести изменения в Проект Конечного Результата на основе обратной связи полученной по окончанию очередной итерации.
Преимущества Rational Unified Process
Методология RUP была целенаправленно разработана для разработки больших программных систем.
Новация №1, заложенная в её основу, это «Бизнес-моделирование» и связанные с ним Сценарии Использования (Use Case).
Сперва разрабатывается бизнес-сценарий использования, где будущая система представляет собою «чёрный ящик», который удовлетворяет все потребности Пользователя/Бизнеса. На его основе разрабатываются системные сценарии использования, описывающие функции системы, которые будут поддерживать выполнение бизнес-сценария.
Главная задача при разработке корпоративной ИС обеспечить непрерывность поддерживаемого бизнес-процесса. Когда ткань бизнес-процесса рвется, то встают все следующие за ним этапы в производственной цепочке, а порой и весь бизнес объемом в десятки миллиардов рублей.
Пример остановки торгов Московской биржейНа фондовом, валютном и срочном рынках Московской биржи нештатная ситуация … Последний раз биржа приостанавливала торги 1 сентября, но это коснулось только секции «Основной рынок». Этот сбой стал четвертым за последние четыре месяца. — Lenta.ru
Поэтому в основе разработки корпоративной ИС лежит проектирование нового бизнес-процесса на основе её использования, чтобы заменить один процесс на другой и сотни людей с определенного дня начали работать по другому чем привыкли до этого. В этом главное и основное отличие разработки корпоративной ИС от других видов программного обеспечения.
Новация №2: На основе выделенных системных сценариев использования системы принимаются архитектурные решения и выделяются компоненты, которые будут поддерживать бизнес-сценарии и решается будут ли они использоваться совместно для поддержки нескольких бизнес-сценариев или останутся заточенными под конкретный сценарий. (Объектно-ориентированное проектирование и программирование)
Наличие отдельных компонент позволяет их переиспользовать и заменять одни на другие. Чем больше компоненты используются совместно тем выше вероятность сломать соседний бизнес-сценарий при внесении изменений в компоненту. Также наличие общих компонент ограничивает скорость и масштаб последующих работ по развитию системы. Если одна команда занимается тем, что меняет какую-то общую компоненту, то другая не может начать работы по её изменению до тех пор пока первая не закончит работы и не отладит свой бизнес-сценарий использования.
Новация №3: Наличие выделенных сценариев использования системы позволяет разделить их на первичные и вторичные. Вторичные основываются на результатах выполнения первичных сценариев, которые по большому счёту самодостаточны. Отсюда появляется возможность выделить итерации и разложить реализацию всех сценариев по ним.
В Waterfall от того нет итераций, так как порой невероятно сложно разделить функциональные требования на самодостаточные блоки и реализовывать их итерациями. Я не говорю, что этого нельзя сделать, можно, но чаще всего результатом этого будет не работающий прототип ИТ-решения, а какая-то часть будущей программы. От этого бизнесу не становится легче, работающий прототип он так и получит через год, наличие итераций здесь помогает, но не сильно.
Вот так выглядит концепт RUP в упрощенном виде:
Каждый бизнес-сценарий разворачивается в системные сценарии использования. Каждый системный сценарий — в требования к интерфейсам, алгоритмам, данным и не функциональные (производительность, время доступности, скорость ответа...). На основе выделенных требований определяется будущая архитектура системы и её функциональные модули (сервисные подсистемы). Подсистемы разбиваются на компоненты. Компоненты содержат исполняемый код.
Основная идея RUP выдать уже в первых итерациях прототип будущей системы с порцией готовых к использованию / применению бизнес-сценариев. Так как доставка части Результата проекта (инкремента) осуществляется в конце каждой итерации, это позволяет начать получать выгоду от использования промежуточных версий Результата и возвращать вложения в проект ещё в ходе его реализации.
Как мы применили RUP
Шаг №1 — Я договорился с руководителем об использовании отличного от принятого в компании шаблона технического задания. В основу нового ТЗ легли бизнес и системные сценарии использования. Это решение было принято раньше чем решение о работе по RUP и по ряду причин о которых можно прочесть в моей статье «Каким должно быть ТЗ на корпоративную ИС?» (ссылка в конце этой статьи в разделе «Что ещё почитать»).
Шаг №2 — Спроектировали целевой бизнес-процесс и подготовили первую версию ТЗ. После того как получили оценки трудоемкости и длительности реализации приняли решение, что попробуем использовать RUP для этого проекта. Разбили целевой бизнес-процесс на 5 бизнес-процедур / 5 этапов реализации проекта. Первая версия ТЗ стала концепцией / дорожной картой по продвижению к целевому процессу.
Шаг №3 — Определились со стратегий автоматизации: двигаться от входной или выходной точки всего бизнес-процесса.
Первая стратегия «от входной точки» создаёт напряжение и заставляет автоматизировать все остальные этапы в цепочке. В последующие этапы бизнес-процесса перестают поступать первичные данные, которые необходимы им для работы.
Вторая стратегия «от выходной точки» не имеет этого напряжения, но и не имеет тех данных и истории, которые создаются и накапливаются на предыдущих этапах. Нужен регулярный перенос необходимой информации в КИС.
Пошли по первой стратегии. Проблему обеспечения последующих этапов необходимой информацией решили выгрузкой данных в Excel. Получили неожиданный эффект в виде растущей мотивации бизнес-пользователей полностью перейти из Excel в КИС вместе с соответствующей поддержкой и готовностью выделять время на работу с бизнес-аналитиком по проработке требований.
Шаг №4 — Подготовили ТЗ на первую часть модуля системы (вторую итерацию). Пока велась разработка первой части, готовили ТЗ на вторую часть (третью итерацию).
Первой итерацией была подготовка Концептуального Технического Задания где прописали полностью бизнес-процесс с использованием КИС, а также разработали первую версию архитектуры будущего модуля.
Шаг №5 — После выхода первой части модуля и старта его опытной эксплуатации, начали готовить дополнение к ТЗ на первую часть и ТЗ на третью часть (четвертую итерацию). В дополнение вошли те требования, что были упущены в начале и те что оказались неудачными в плане использования.
Результат — На всё про всё у нас действительно ушло 1,5 года. Работающий прототип (первая часть модуля системы) был получен спустя 6 месяцев с даты старта проекта. Остальные приходили уже через каждые 2 месяца.
С точки зрения архитектуры компоненты нового функционального модуля были заточены исключительно под него и не использовали компоненты основной ИС. Это позволило:
- Стабилизировать работу системы целиком при возникновении ошибок, порождаемых регулярно вносимыми изменениями в модуль, так и модуль от ошибок изменений вносимых в общий функционал ИС.
- Вести работы по развитию существующего функционала КИС параллельно разработке нового модуля.
Хоть RUP напрямую ассоциируется и связан с нотациями UML, для описания бизнес и системных сценариев использования не обязательно использовать именно их, подойдут и другие нотации. Главное, чтобы используемые нотации были понятны и Бизнес-Пользователям, которые будут согласовывать-утверждать постановку, и Системным Аналитикам и Разработчикам которые будут дальше работать с Техническим Заданием переводя его в проектную-техническую документацию. Мы для описания бизнес-сценария использовали eEPC и ARIS, а также требования нотаций IDEF0/3 для задания рамок системным сценариям: вход процесса, выход процесса, исполнитель.
Статья «Каким должно быть ТЗ на корпоративную ИС?» даст представление о том, как выглядит бизнес-сценарий и системный сценарий использования. В оригинале руководства по RUP не рекомендуется делать наброски пользовательских интерфейсов при составлении системных сценариев, но мы посчитали их необходимыми так как облегчают понимание и бизнес и системного сценариев засчёт визуализации их элементов. Это было практически первым прототипом системы хотя и не кликабельным.
После этого проекта написанное ТЗ стало новым шаблоном (стандартом). Также проект повлиял на весь технологический-производственный процесс разработки ПО в компании сделав его ритмичным.
Немного теории для понимания технической стороны методологии RUP и как её применять
Каждая итерация в RUP это классический Waterfall, содержащий все 5 этапов работ по сбору требований и их анализу, проектированию, разработке, тестированию и доставке. Но RUP также вводит такое понятие как фазы для проекта: Сбор требований и Анализ, Проектирование, Построение, Внедрение.
Теперь об этом подробнее.
Первая итерация, Фаза Анализ
Посвящена сбору требований будущих пользователей к системе. Пользователи рассказывают каждый свой кусочек работы (сценарий использования системы пользователем), а Аналитик из отдельных операций и процедур пытается собрать целый рабочий процесс. Цель этой итерации выйти на бизнес-сценарий использования системы / будущий бизнес-процесс на основе ИС. Их может быть больше чем один, поэтому не стоит замыкаться на том чтобы был обязательно один.
Компания-Заказчик — это Банк. Он решает, что хочет начать предоставлять своим клиентам услугу по удаленной выдаче наличных при помощи банкоматов, установленных в офисах клиентов и на станциях метро.
Для оказания данной услуги, нужно разработать и доработать имеющееся у банка программное обеспечение. В ходе сбора требований и их анализа было выделено три крупных процедуры в бизнес-сценарии услуги:
- Загрузка наличных в банкомат Сотрудниками банка.
- Выдача наличных Клиенту по его запросу со счёта в банке.
- Учет количества загруженных и выданных купюр.
В этой итерации ещё нет работ связанных с проектированием архитектуры будущей системы, разработки программы, тестирования и доставки. RUP не ставит условий, что они обязательно нужны, но по своему усмотрению вы можете их выполнить.
Вторая итерация, Фаза Анализ
После того как бизнес сценарии определены, собранные требования раскладываются по шагам бизнес-сценария и системным сценариям. На этом этапе также выявляются те шаги бизнес-сценариев, что были не выявлены в первой итерации.
В ходе второй итерации были выявлены две дополнительные процедуры к основному бизнес-сценарию:
Для обеспечения доступности услуги выдачи наличных в режиме 24/7.
- Мониторинг и нотификация, направляемая банкоматом в банк, об окончании в нём наличных.
- Мониторинг и нотификация о работоспособности банкомата или наличия на нем проблем/ошибок в работе.
Результатом этой итерации становятся:
- На 90% законченные бизнес-сценарии.
- Намеченные, но не детализированные системные сценарии использования по каждому бизнес-сценарию.
- Собранные требования структурированы по бизнес и системным сценариям.
Третья итерация, Фаза Проектирование
Выявленным бизнес сценариям выставляются приоритеты реализации и самые важные из них становятся предметом проработки на данной итерации. В отобранных бизнес-сценариях выделяются первичные шаги-этапы, которые являются базой для всех последующих и без которых реализация остальных не имеет смысла. Для этих этапов детализируются сценарии использования системы.
Законченный результат передается Системным Аналитикам и Архитектору для моделирования того, что будет происходит внутри системы. Выделяются классы, кооперации между ними, последовательности взаимодействия. Формируется базовое представление об архитектуре будущей системы, выделяются подсистемы, компоненты системы и их распределение по узлам ИТ-решения.
Уже в этой итерации могут быть начаты работы по разработке и результатом итерации станет готовый прототип, поддерживающий выполнение первичных шагов-этапов ключевого бизнес-сценария. Его уже можно показывать пользователям для сбора обратной связи и уточнения требований.
Этот прототип не передается в опытную или промышленную эксплуатацию, так как заложенная в основу архитектура является первым пробным шаром и в последующих итерациях будет скорректирована.
Четвертая итерация, Фаза Проектирование
Стартует параллельно третьей итерации, когда в ней закончены работы по анализу и начаты работы по проектированию.
На этой итерации происходит проработка первичных шагов-этапов остальных бизнес-сценариев. Причина по которой прорабатываются они, а не последующие шаги для ключевых бизнес-сценариев, это определение будущей архитектуры всей программы.
Каждый бизнес-сценарий может потребовать для своей реализации каких-то специфических компонент будущей системы и по этой причине архитектурные решения для каждого бизнес-сценария должны быть согласованы между собой.
Результатом этой итерации станут:
- Архитектурные решения для каждого бизнес-сценария.
- Согласованный проект общей архитектуры системы 1.0
- Вторая версия прототипа с готовыми первыми шагами вторичных бизнес-сценариев в дополнение к первым шагам ключевого бизнес-сценария.
Пятая итерация, Фаза Построения
Стартует параллельно четвертой итерации, когда в ней закончены работы по анализу и начаты работы по проектированию. Предполагается, что к моменту старта итерации уже получена обратная связь по результатам тестирования пользователями прототипа, изготовленного во время третьей итерации. Здесь происходит проработка остальных шагов-этапов ключевого бизнес-сценария и связанных с ними системных сценариев использования.
Предполагается, что к моменту начала этапа работ «Проектирование», уже будет выполнена реализация (разработка) четвертой итерации и начато тестирование второй версии прототипа.
Происходит уточнение согласованного проекта общей архитектуры системы после которого внесение каких-то концептуальных изменений в него практически сводится к нулю, но всё ещё возможно, так как остаются не реализованными полностью вторичные бизнес-сценарии.
Результатом итерации становятся:
- Полностью реализованный ключевой бизнес сценарий.
- Согласованный проект общей архитектуры системы 2.0
- Третья версия системы, реализующая ключевой бизнес-сценарий и первые шаги для вторичных бизнес-сценариев.
Здесь уже возможна передача системы для опытной эксплуатации бизнес-пользователям так как система уже перестаёт быть прототипом и в большей степени похожа на ту, что будет передана бизнес-пользователям как её финальный вариант.
Шестая итерация, Фаза Построения
Стартует параллельно пятой итерации, когда в ней закончены работы по анализу и начаты работы по проектированию.
Прописываются остальные шаги-этапы вторичных бизнес-сценариев и связанных с ними системных сценариев использования. Предполагается что к началу данной итерации выполнено тестирование второй версии прототипа, изготовленной вовремя четвертой итерации и получена обратная связь от пользователей по работе с первичными шагами-этапами вторичных бизнес-сценариев.
Результатом итерации становятся:
- Полностью реализованные вторичные бизнес сценарии.
- Финальный проект общей архитектуры системы 3.0
- Четвертая версия системы, реализующая все бизнес-сценарии.
Начинается полноценная опытная эксплуатация системы бизнес-пользователями и примерка её под промышленное использование.
Седьмая итерация, Фаза Внедрения
Здесь происходит внесение каких-то критических изменений в реализацию бизнес-сценариев, выявленных в ходе опытной эксплуатации и не позволяющих полноценно использовать систему в промышленной эксплуатации.
Восьмая итерация, Фаза Внедрения
На этой итерации проводятся работы по повышению удобства использования системы пользователями и оптимизации изготовленных решений. Пользователей в первую очередь интересует скорость и пропускная способность их участков. Происходит передача системы на поддержку. Проводятся формальные процедуры по завершению и закрытию проекта.
Подитог
Методология RUP не ставит условий по количеству итераций и их распределению по фазам. Концепт фаз и итераций введен для снижения рисков, потребности в ресурсах, задания ритма реализации проекта и предоставления возможности внести требуемые изменения при разработке большой информационной системы.
График зависимости срока проекта от времени начала выявления проблем в ИТ-продукте
Результат каждой итерации уточняет план следующей и даёт больше понимания о том понадобятся ли нам дополнительные ресурсы для следующей итерации, нужны ли будут дополнительные итерации для завершения фазы. Начать работать над проектом может минимальная команда из нескольких человек и её расширение будет обосновываться планом следующей итерации.
Результаты завершения фазы уточняют план и экономику проекта. Здесь принимаются решения продолжать ли проект, нужно ли сузить или расширить содержание проекта (объем бизнес-требований), чтобы остаться в бизнес рамках: нужного срока доставки результата проекта, его стоимости (бюджета) и доходности (рентабельности вложений).
Заключение
Понимаю, что не просто поменять принятые в компании устои как реализовывать ИТ-проекты, особенно если в компании работает Проектный Офис с методологией написанной на основе PMBoK и ГОСТ-ов. Если прочитав статью понимаете что ближайшая перспектива это всё-таки Waterfall, то рекомендую попробовать реализовать следующий минимум:
- Прописать автоматизируемый бизнес-процесс на основе использования ИС. Это больше чем на 50% готовая пользовательская документация и приемочные тесты.
- Заложить в проект время на то, что как минимум 1 раз в течении года придётся выполнить полный комплекс работ по перепроектированию, подготовке и согласованию изменений в проектную документацию.
- Помножить трудоемкость работ по разработке на 1,5. Так как треть сделанной работы придется выкинуть и появятся новые требования. Длительность этапа разработки тоже стоит помножить на 1,5.
- Разделить бюджет проекта на две части: создание и развитие.
На развитие заложить примерно 30% от всего бюджета проекта на создание. Это нужно затем, что когда закончите проект возникнет промежуточное состояние — проект реализован, но не принят на сопровождение.
Принятие на сопровождение, как правило, сопровождается процедурами согласования и выделения бюджета и ресурсов на сопровождение. При этом после окончания проекта начинается самая горячая фаза, когда пользователи будут требовать реализации критических доработок, которые не вошли в содержание (рамки) проекта, но их точно нужно делать и из чего-то финансировать до тех пор пока система не будет принята на сопровождение и переведена на бюджет поддержки.
Это позволит мягко договорится с Заказчиками об окончании фазы реализации проекта, выполненной согласно ТЗ.
На мой взгляд:
- Waterfall – это первая передача (первая скорость с релизом раз в год),
- RUP – вторая (релиз раз в квартал),
- Scrum – третья (релиз раз в две недели / месяц),
- Kanban вместе с автоматической сборкой обновления (Continuous Integration), автоматическим тестированием (Acceptance Test-Driven Development), автоматической доставкой и развертыванием (Continuous Deployment) – четвертая (релиз раз в день).
Что ещё почитать по теме для освоения RUP
- Статья «Каким должно быть ТЗ на корпоративную ИС?»
В статье делается упор на то, что после разработки и создания КИС, начнётся этап её развития. На этом этапе потребуется разработка как новых Технических Заданий на новые функциональные модули, так и внесение изменений в ранее разработанные ТЗ на существующие модули системы в связи с внесением изменений в сценарии их использования.
Обратите внимание на комментарии под статьёй. Они шире раскрывают материал и самой статьи про ТЗ и этой статьи про RUP.
- Книга «Унифицированный процесс разработки программного обеспечения»
Это настольная книга в которой есть всё что нужно, чтобы понять и научиться делать проекты по RUP.
Первая и основная сложность — это научиться проектировать не существующие бизнес-процессы / бизнес-сценарии. Чтобы подступится к ним я рекомендую научиться описывать существующие, после чего проектирование нового взамен старого уже не будет таким сложным.
Авторы книги предлагают для моделирования бизнес-процессов использовать UML, но всё таки книга заточена на проектирование информационной системы и в меньшей степени на проектирование бизнес-процессов. Поэтому рекомендую освоить нотации IDEFx на основе Structured Analysis and Design Technique (книга на русском). Понятие процесса которое заложено в этой методологии является основой для стандартов ISO и PMI. И уже после этого расширять свои знания и умения по использованию других нотаций.
- Изучения языка моделирования напрямую связано с необходимостью освоения какого-либо инструмента. RUP предполагает что вы будете использовать линейку продуктов Rational от IBM. Я рекомендую воспользоваться бесплатной демо-версией Business Studio. В этом видео с 12 минуты объясняется как строить модели с помощью данного инструмента.
Поделиться с друзьями
Комментарии (23)
Lofer
10.06.2017 16:57+1За ней скрывается фреймворк, который детально описан в стандарте PMI (PMBoK).
В PM Book ничего не расписано, никаких frameworks там нету.
Там только набор «Best Practice» и первым абзацем там написано:
Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой. «Хорошая практика» не означает,однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту1.1 Цель Руководства PMBOK®
Повсеместное признание, которое завоевывает управление проектами, является показателем того, что применение соответствующих знаний, процессов, навыков, инструментов и методов может иметь решающее значение для проекта. Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой. «Обычно считается» означает, что описываемые знания и практики применимы к большинству проектов в большинстве случаев, причем относительно их значения и пользы существует консенсус. «Хорошая практика» означает, в целом существует согласие относительно того, что правильное применение этих знаний, навыков, инструментов и методов способно повысить вероятность успеха для широкого диапазона различных проектов. «Хорошая практика» не означает, однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту.
Locolind
10.06.2017 17:26В PM Book ничего не расписано, никаких frameworks там нету.
В пятой версии начиная со страницы 417 «Приложение А1 Стандарт управления проектом»
А фазы, что вы указали для RUP присутствуют в любом проекте.
А вы не путаете фазы проекта с типами работ?
В классическом представления каждая фаза проекта соответствует одному типу работ. В парадигме RUP в каждой фазе проекта могут быть выполнены все типы работ: Сбор требований, Анализ, Проектирование, Разработка, Тестирование и Внедрение, — и не по одному разу, если фаза содержит более одной итерации.
Поэтому указанные типы работ действительно присутствуют во всех проектах, а вот Фазы не всегда используются. Это должен быть осознанный выбор и их практикование Руководителем проекта.
Вам повезло, что заказчик уже побегал по граблям и согласился на вменяемый бизнес-анализ
Это так, я Заказчиков, с которыми не везёт, не беру. Но в данном случае мой Заказчик по граблям не бегал, у нас с ним была история успешного сотрудничества, поэтому был высокий кредит доверия, что мне видней как лучше это сделать.
Про вменяемый бизнес-анализ скажу, что для того, чтобы его сделать, нужно знать что такое «вменяемый бизнес-анализ», уметь его делать и трассировать в техническую постановку.
Благодарю что оценили наше грамотное планирование.
Вдохновлялись книгой Ivar Jacobson «The Unified Software Development Process»
Lofer
10.06.2017 18:20В пятой версии начиная со страницы 417 «Приложение А1 Стандарт управления проектом»
Далее идет расшифровка понятия «стандарт». Опять же в контексте — соблюдение повышает шансы успеха, но не гарантирует их.
Стандарт как ... руководящие принципы или характеристики продуктов, процессов и услуг, для общего и постоянного использования, соответствие которым не является обязательнымМеждународная организация по стандартизации (International Organization for Standartization, ISO) и другие организации определяют стандарт как «документ, одобренный признанным учреждением, устанавливающий правила, руководящие принципы или характеристики продуктов, процессов и услуг, для общего и постоянного использования, соответствие которым не является обязательным». (ISO/IEC 2:2004) [11]
Данный стандарт описывает суть процессов управления проектом с точки зрения интеграции процессов, их
взаимодействия и целей, которым они служат.
SbWereWolf
10.06.2017 23:18«Kanban» не требует указания сроков, сроки ни как не оговариваются в этой «методологии», «Scrum» — это о сроках, там сроки — это краеугольный камень.
он для того что бы загружать «участок» работы ( сотрудника, команду ) таким образом что бы не замедлять работу всей «линии» ( проектной команды, фирмы ), то есть «Kanban» для гармоничной загрузки участков производства, а «Scrum» это что бы регулярно ( в заранее определённые сроки ) делать релизы.Locolind
11.06.2017 00:00Бизнес всегда интересуют сроки, когда они получат новую нужную им «фичу».
Это он требует указания срока, какой бы вы технологический подход/метод не использовали бы для разработки.
В Kanban как и в Scrum есть Product Backlog. В обоих случаях они должны быть приоритезированны, чтобы можно было понять какие задач делать в первую очередь и в какой последовательности.
Сроки для задач в в Scrum высчитываются из длительности спринта, его емкости (часов в спринте) и трудоемкости задачи (часов на её выполнение). Часы здесь условно, хоть в попугаях может быть единица измерения.
Гибкое планирование выпуска релизов 101 (на основе Excel)
Сроки в Kanbane определяются на основе показателя срока нахождения задачи на доске (время цикла) и ограничения на количество задач в работе. Если одновременно делать можно две задачи. То приведенному выше списку задач также можно построить прогноз.
Канбан в IT (Kanban Development).
Проблема и Waterfall, и RUP, и Scrum в том, что внутри списка релиза всегда находятся уже выполненные задачи, которые ждут даты назначенной для выхода релиза.
В случае с Waterfall — полгода, c RUP — квартал, с Scrum — от недели до месяца. В Kanban, в его космическом варианте, выполненная задача не ждёт выполнения остальных задач для её релиза, она сразу идёт релизится.
Rabajaba
11.06.2017 10:46В Kanban, в его космическом варианте, выполненная задача не ждёт выполнения остальных задач для её релиза, она сразу идёт релизится.
Никакого космоса, это вполне реально. На мой взгляд, все сводится к двум вещам: как сделать задачку поменьше и как выкатить её побыстрее. Первое достигается по большей части планированием — можно ведь
выкатить форму из 10 полей, а не из 20, без умной геолокации и подсказок при вводе. Тут скорее вопрос в том, готов ли ваш менеджмент продавать настолько быстро меняющийся продукт. Второе чисто техническая задача и решается она "инженерными подходами":
- SRP и модульность (ака "микросервисы"): понижает связность кода, позволяя разделять ужас на более мелкие ужасы вашей реализации. В результате измнения в одном маленьком модуле технически не влияют на другие
- TDD/BDD — позволяет создавать ТОЛЬКО то, что нужно, без излишеств, не тратя время по-напрасну
- хороший уровень авто-тестов — не только про регрессию, имея хороший уровень модульности можно не напрягаясь гонять тесты параллельно среди модулей
- быстрый CI — позволяет деплоить задачу по клику мышки (мы пока до деплоя по коммиту не дошли) и не думать о том как там все устроено и какой опять конфиг надо править
Ко всему этому можно прийти, тут ничего сложного. Как? Я в своё время это очень просто объяснял коллегам: теперь в нашем Definition of Done десятым пунктом стоит "prod deploy" и "prod test" — с таким подходом все стали искать возможности выкатываться максимально быстро, стали делить задачи на куски, уходить от зависимостей, лучше понимать значение "Lean философия". Сейчас каждый релизит свою задачу самостоятельно, когда посчитает нужным.
Тут главное, что Kanban далеко не всем нужен, и то, как работает команда исполнителей, должно быть продиктовано условиями сверху, со стороны бизнеса, а не снизу, со стороны самих исполнителей.
SbWereWolf
12.06.2017 13:45мой комент был о том что в Kanban мы заранее себе сроки не назначаем, как раз Kanban это про поиск гармоничных сроков, а в Scrum у тебя есть ритм работы и ты выбираешь себе часть работы которая в этот ритм уложиться.
Kanban — о том как выдать результат (готовый продукт).
Scrum — о том как всегда в пятницу выкатить очередной промежуточный релиз.
Kanban — сделать с тем что бы завершить.
Scrum — делать с тем что бы продолжить.
поэтому я согласен что Scrum это двухнедельные релизы, но не согласен с тем что Kanban — ежедневные, могут быть недельные, могут быть месячные, могут быть годовые — как работу выстроите.
Lofer
11.06.2017 11:33В Kanban, в его космическом варианте, выполненная задача не ждёт выполнения остальных задач для её релиза, она сразу идёт релизится.
Никакого космоса, это вполне реально. На мой взгляд, все сводится к двум вещам: как сделать задачку поменьше и как выкатить её побыстрее.
Имелось ввиду, что «родители» этих методологий разные, вышли они из разных «источников» и решали задачи в условиях разного приоритета одних и тех же требований. Вроде как не имеет смысла поставить ядерный реактор на подпорках в первой итерации а потом обкладывать бетоном.
ИТ — просто адаптировал под себя методологии, ища наиболее удобную и технологически реализуемую. Вот развитие и привело к «развертыванию по комиту». Но опять-же, скорость адаптации бизнеса и людей в нем- конечна, и менять по 3 раза в день логику и UI не самое разумное.
dmitrybelsky
11.06.2017 12:29Достаточно странно смотреть на «большой» проект. У вас трудоемкость 6500 часов, т.е. 3 человекогода. Если смотреть на срок в полтора года, то получаем чудовищную команду в 2 землекопа. Бюджет аж миллионов 10-15 рублей
Для подобного чудовищного ПРОЕКТА нужно примерно 0.2-0.3 FTE нормального РМа.
Мораль — автора надо увольнять за профнепригодность и трату времени на всякую хрень вместо работыLocolind
11.06.2017 12:45dmitrybelsky у вас корректная математика.
Специально для вас написал статью Причина недопонимания между нами и неверного использования технологий. По мотивам статьи «Пять миров» (ПО)
Вы упускаете из виду окружающий контекст проекта: был ли у меня в работе только этот проект или их было много, может ли быть вся команда разработки отдана Заказчику на данный проект и все прочие работы по развитию системы остановлены, позволяет ли архитектура системы распараллелить работы по разным проектам…
И делаете выводы:Мораль — автора надо увольнять за профнепригодность и трату времени на всякую хрень вместо работы
dmitrybelsky
12.06.2017 22:42Какая разница? На нормального проджекта можно свободно повесить от 3 до 10 таких мега-проектов.
Если РМ не справляется с управлением ожиданиями у заказчика или иных стейкхолдеров или не может выбить ресурсы — то вывод смотри в моем первом сообщении)
Вы потратили дофига собственного времени на все эти свистоперделки вместо того, чтоб один раз прочитать РМВОК и заняться непосредственно работой. По моим оценкам данная статья на хабре встала вашему работодателю как мин в 200к прямых убытков и ещё пару мультов косвенныхLocolind
12.06.2017 23:42dmitrybelsky,
Моему работодателю эта статья не стоила ни копейки, а проект имел защищенное Технико-Экономическое Обоснование и генерировал прибыль компании более 5 лет.
Руководство принимало непосредственное участие в принятии решении о том, что будем на этом проекте пробовать новый подход к выполнению работ. Все затраты времени были санкционированы.
На нормального проджекта ничего нельзя повесить. Где сели, там с него и слезите, потому что это нормальный проджект. Нормальный РМ работает на своё портфолио и репутацию. На не нормального можно повесить хоть 100 таких проектов. В этот раз вы уже не в ладу с собственной математикой про 0.2-0.3 FTE.
Судя по вашей манере общения, вы менеджер среднего звена (B-level) которому повезло перескочить уровень работы «нормальным PM-ом», потому позволяете себе много вольностей и видимо не только на сайте, но и в работе. «Чего нет в игре, того нет и в жизни.» (с — Сергей Кириенко)
В плане выстраивания взаимоотношений, в том числе и со стейкхолдерами, у вас явно присутствует недостаток квалификации иначе не позволяли бы себе подобных публичных высказываний, которые потом не сможете удалить.
Пишите свои статьи и выносите их на суд ИТ-сообщества, чтобы получить независимую оценку своей квалификации. Буду ждать, даже специально подписался на вас.dmitrybelsky
13.06.2017 09:49Когда я говорю про затраты работодателя — то имею в виду
1. Использование непроверенных методологий несет дополнительные риски. Их оценки я не увидел
2. Освоение этих технологий стоит денег. Ориентировочно — в районе одного человекомесяца.
3. Пока идет освоение — страдают другие проекты и этот не движется с места
Если руководство было радо экспериментам, то ок. Вы грамотно продали идею повышения квалификации за счет работодателя
У любого РМа есть начальник PMO. С ним всегда можно договориться.
Про нормативы — если критикуете, то дайте свою оценку вовлеченности PMa в проект с командой из двух человек (даже из трех :) ) в тех самых презренных FTE. Пока я вижу высказывания в духе: «Вы все врёте»
Про ярлыки — сразу скажу, вы по всем пунктам дали промах. РМом я был всего пару-тройку лет. И менеджером
Касательно выступлений — не вижу ни одного высказывания со своей стороны, которое я не мог бы подтвердить еще раз основываясь на вашем же тексте.
Недостаток опыта виден скорее с вашей стороны, иначе бы появилось банальное обоснование выбора конкретной методологии для данного проекта
С моей точки зрения вся статья выглядит следующим образом:
У нас есть мелкий ненужный проект.
Ура, мы тут обнаружили новый фреймворк управления проектами!
Попробуем!
Проект вроде сделали
Запилим статью на хабреLofer
13.06.2017 11:19Когда я говорю про затраты работодателя — то имею в виду
1. Использование непроверенных методологий несет дополнительные риски. Их оценки я не увидел
2. Освоение этих технологий стоит денег. Ориентировочно — в районе одного человекомесяца.
3. Пока идет освоение — страдают другие проекты и этот не движется с места
С каких пор RUP не проверенная методолгия? начало 200х была известна.
Что значит «дополнительные риски»? Риски есть всегда, вопрос цены рисков, стратегии их обработки или отказа.
Что значит «освоени методологии»? или ты понимашеь что делаешь и зачем или нет. Ресурсам — задачи и сама мотодология им побоку в общем случае.
Не движется с места «куда»? Все работы играли ту или иную роль. Все работы играли на руку подрядчику. Все предварительные работы должны быть проведены или подрядчик просто попадает на штрафы из-за не выполненных условий договора.
Работа РМ — идентифицировать цели проекта, оценить риски, выбрать методолгию управления проектом и адаптировать под цели клиента. Уж после думать про всякие ресурсы/capacity management, communication plan и прочее.
Или вы полагаете, что нужно быть тупо подписать контракт без юридической защиты и без предварительной оценки? смешно.
Locolind
15.06.2017 01:15dmitrybelsky,
Сперва вы были против того, что я назвал проект большим, а по вашим меркам он таковым не является. (Общепринятого стандарта-мерки нет или приведите ссылку на него, чтобы доказать обратное)
Теперь вы против того, что мы проэкспериментировали с новым фреймворком управления проектами на «мелком ненужном проекте», то есть мы должны были взять что-то покрупнее, чтобы словить указанные вами риски и увеличенные соразмерные проекту затраты на освоение на крупном проекте, верно?
ganqqwerty
11.06.2017 14:29+1Мне нравился RUP всем, кроме какого-то чудовищного обилия бумажек. А если бумажка создалась, кто-то должен поддерживать ее актуальность. Есть ли метод сократить количество производимых документов?
Locolind
12.06.2017 02:09ganqqwerty, вы задали хороший вопрос.
Краткий ответ таков: Не делайте документацию, которая вам не нужна.
Длинный ответ:
У RUP и у Стандарта управления проектами (PMI, PMBoK) предусмотрено множество документов, которые призваны помочь сделать проект/продукт, но это не значит что в первом случае надо обложится всевозможными UML-диаграммами, а во втором — планами на каждый возможный чих.
Пишите только те документы, которые помогают вам решать проблемы во взаимодействии между разными заинтересованными сторонами и участниками команды, экономят команде время на следующих этапах работ и позволят без травм для бизнеса и системы переделать функциональный модуль (подсистему) через Н-лет, когда это понадобится.
Поэтому предлагаю делить документацию на базовую (core) и факультативную (optional). Первая однозначно нужна в любом случае и должна быть всегда актуальной. Вторая делается под конкретную ситуацию и необязательна должна быть актуальной.
Вот моё представление о базовой документации:
- В основе всего лежит один документ, который описывает текущую реализацию бизнес-процесса в контексте использования информационной системы. В карточке описания бизнес-процесса указывается, на каких функциональных модулях системы он построен.
- Как только бизнес хочет начать работать по другому, мы перепроектируем бизнес-процесс и указываем какие его участки на что меняем. К этому привязываются изменения в функциональных модулях.
- Если другой бизнес-процесс пытается использовать для себя функциональный модуль, то Реестр ТЗ подсказывает какие бизнес-процессы уже на нём сидят.
- В итоге для бизнеса всё сводится к трём документам: Документ версии 1.0, Вносимые изменения, Документ версии 1.1. И такая же картина с технической стороны для функциональных модулей (подсистем).
Весь список «бумажек» нужный для разработки и доработки:
- Реестр ТЗ.
- ТЗ бизнес-часть (содержит описание бизнес-сценария и его системных сценариев использования).
- Дополнение к ТЗ бизнес-часть (содержит указание что на что меняем в бизнес-сценарии и системных сценариях), как правило, после выполнения работ и подготовки обновленной версии ТЗ «выкидывается».
- ТЗ техническая часть (содержит раскладку системных сценариев на сущности системы).
- Дополнение к ТЗ техническая часть.
Здесь ТЗ в его бизнес-части выступает общей основной, и для пользовательской документации, и для проектно-технической документации.
Завязываться на описание просто самой системы и её возможностей — это потом не разобрать, кто и для чего использует систему, и регулярные жалобы Заказчиков на то, что новая реализация функции, которую мы сделали для одного Заказчика, не устраивает другого Заказчика, который пользовался ею и до её изменения.
Пример того, как это работает Каким должно быть ТЗ на Корпоративную ИС?
Честно скажу, что считаю что вам лучше знакомы методы как уменьшить количество производимых документов. Посмотрел ваши статьи про то что вы разрабатываете базы знаний, а производимая документация и есть база знаний.
Lofer
12.06.2017 10:47Вот моё представление о базовой документации:
…
Весь список «бумажек» нужный для разработки и доработки:
А куда вы включаете «критерии приемки», сценарии приемо-сдаточных испытаний?Locolind
12.06.2017 23:21Lofer бизнес-сценарий и системные сценарии использования это и есть сценарии приемо-сдаточных испытаний.
Критерии приемки:
- это соответствие того, что выдает продукт, тому что записано в качестве выхода для системного сценария использования.
- это отработка всех системных сценариев в симфонии (целостность выполнения бизнес-сценария).
С Заказчиком и Бизнес-Пользователями мы проверяем, что система выполняет нормальный вариант эксплуатации предусмотренный указанными выше системными сценариями и поддерживает новый бизнес-процесс (бизнес-сценарий).
Обычно я говорю что это на 50% готовые приемочные тесты.
Системные сценарии не описывают, что должно происходить при «ненормальной» эксплуатации, ничего не говорят о тестах эмулирующих эксплуатацию под промышленной нагрузкой, регрессионных тестах.
Поэтому создание полной тестовой документации, включая план тестирования, я считаю факультативной задачей. Если система относится к критически важным для бизнеса или есть экономика которая оправдывает высокое качество и покрытие тестированием, то тогда имеет смысл расширять документацию.
Повторюсь, идея такая — делать документацию там где уже есть проблемы или где это экономически оправдано. Иначе вместо работы мы будем заниматься тем, что раскладывать солому во всех местах где можем подскользнуться.
Rabajaba
Вы не корректно используете терминологию.
Waterfall не методолгия, это не фреймворк и не best-practice. Это МОДЕЛЬ. https://en.wikipedia.org/wiki/Waterfall_model
Почитайте Ройса или вот маленькая цитата из той же вики:
Сравнивать "Waterfall" и всякие Agile/Rup/whatever нас научили продавцы этих фреймворков/методологий — консультаты, тренера и иже с ними.
Не вводите себя и других в заблуждение.
Locolind
Согласен с вами.
Каскадная модель — это парадигма.
За ней скрывается фреймворк, который детально описан в стандарте PMI (PMBoK).
К сожалению для него нет другого названия, которое было бы общепринятым, кроме как Waterfall.
Поэтому в статье используется оно.
RUP — это методология, которая относится к Инкрементальным и Итеративным моделям (парадигмам).