Comments 23
Вы не корректно используете терминологию.
Waterfall не методолгия, это не фреймворк и не best-practice. Это МОДЕЛЬ. https://en.wikipedia.org/wiki/Waterfall_model
Почитайте Ройса или вот маленькая цитата из той же вики:
Royce presented this model as an example of a flawed, non-working model;
Сравнивать "Waterfall" и всякие Agile/Rup/whatever нас научили продавцы этих фреймворков/методологий — консультаты, тренера и иже с ними.
Не вводите себя и других в заблуждение.
Согласен с вами.
Каскадная модель — это парадигма.
За ней скрывается фреймворк, который детально описан в стандарте PMI (PMBoK).
К сожалению для него нет другого названия, которое было бы общепринятым, кроме как Waterfall.
Поэтому в статье используется оно.
RUP — это методология, которая относится к Инкрементальным и Итеративным моделям (парадигмам).
Каскадная модель — это парадигма.
За ней скрывается фреймворк, который детально описан в стандарте PMI (PMBoK).
К сожалению для него нет другого названия, которое было бы общепринятым, кроме как Waterfall.
Поэтому в статье используется оно.
RUP — это методология, которая относится к Инкрементальным и Итеративным моделям (парадигмам).
За ней скрывается фреймворк, который детально описан в стандарте PMI (PMBoK).
В PM Book ничего не расписано, никаких frameworks там нету.
Там только набор «Best Practice» и первым абзацем там написано:
Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой.
«Хорошая практика» не означает,однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту
1.1 Цель Руководства PMBOK®
Повсеместное признание, которое завоевывает управление проектами, является показателем того, что применение соответствующих знаний, процессов, навыков, инструментов и методов может иметь решающее значение для проекта. Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой. «Обычно считается» означает, что описываемые знания и практики применимы к большинству проектов в большинстве случаев, причем относительно их значения и пользы существует консенсус. «Хорошая практика» означает, в целом существует согласие относительно того, что правильное применение этих знаний, навыков, инструментов и методов способно повысить вероятность успеха для широкого диапазона различных проектов. «Хорошая практика» не означает, однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту.
Повсеместное признание, которое завоевывает управление проектами, является показателем того, что применение соответствующих знаний, процессов, навыков, инструментов и методов может иметь решающее значение для проекта. Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой. «Обычно считается» означает, что описываемые знания и практики применимы к большинству проектов в большинстве случаев, причем относительно их значения и пользы существует консенсус. «Хорошая практика» означает, в целом существует согласие относительно того, что правильное применение этих знаний, навыков, инструментов и методов способно повысить вероятность успеха для широкого диапазона различных проектов. «Хорошая практика» не означает, однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту.
А фазы, что вы указали для RUP присутсвуют в любом проекте, вопрос в каком виде.
Вам повезло, что заказчик уже побегал по граблям и согласился на вменяемый бизнес-анализ, что позволило вам адекватно оценить риски и принять меры к их понижению (через грамотное планирование, в первую очередь).
RUP тут, играл такую же весомую роль, как бумага на которой печатался контракт :)
Поэтому рекомендую освоить нотации IDEFx на основе Structured Analysis and Design Technique (книга на русском).
IDEFx штука не плохая, но… несколько неудобная и ракообразная, на мой взгляд.
В PM Book ничего не расписано, никаких frameworks там нету.
В пятой версии начиная со страницы 417 «Приложение А1 Стандарт управления проектом»
А фазы, что вы указали для RUP присутствуют в любом проекте.
А вы не путаете фазы проекта с типами работ?
В классическом представления каждая фаза проекта соответствует одному типу работ. В парадигме RUP в каждой фазе проекта могут быть выполнены все типы работ: Сбор требований, Анализ, Проектирование, Разработка, Тестирование и Внедрение, — и не по одному разу, если фаза содержит более одной итерации.
Поэтому указанные типы работ действительно присутствуют во всех проектах, а вот Фазы не всегда используются. Это должен быть осознанный выбор и их практикование Руководителем проекта.
Вам повезло, что заказчик уже побегал по граблям и согласился на вменяемый бизнес-анализ
Это так, я Заказчиков, с которыми не везёт, не беру. Но в данном случае мой Заказчик по граблям не бегал, у нас с ним была история успешного сотрудничества, поэтому был высокий кредит доверия, что мне видней как лучше это сделать.
Про вменяемый бизнес-анализ скажу, что для того, чтобы его сделать, нужно знать что такое «вменяемый бизнес-анализ», уметь его делать и трассировать в техническую постановку.
Благодарю что оценили наше грамотное планирование.
Вдохновлялись книгой Ivar Jacobson «The Unified Software Development Process»
В пятой версии начиная со страницы 417 «Приложение А1 Стандарт управления проектом»
Далее идет расшифровка понятия «стандарт». Опять же в контексте — соблюдение повышает шансы успеха, но не гарантирует их.
Стандарт как ... руководящие принципы или характеристики продуктов, процессов и услуг, для общего и постоянного использования, соответствие которым не является обязательным
Международная организация по стандартизации (International Organization for Standartization, ISO) и другие организации определяют стандарт как «документ, одобренный признанным учреждением, устанавливающий правила, руководящие принципы или характеристики продуктов, процессов и услуг, для общего и постоянного использования, соответствие которым не является обязательным». (ISO/IEC 2:2004) [11]
Данный стандарт описывает суть процессов управления проектом с точки зрения интеграции процессов, их
взаимодействия и целей, которым они служат.
Данный стандарт описывает суть процессов управления проектом с точки зрения интеграции процессов, их
взаимодействия и целей, которым они служат.
В классическом представления каждая фаза проекта соответствует одному типу работ.
Давно читал RUP. в «детстве» :) В начале 200х. Не сильно впечатлил. Но что вынес из всего этого — умей сам себе собрать «framemework» под проект. Да и Agile практики тогда начали развиваться, так что спланировать и скоординировать типы работ «в нахлест» и итерации проблем не было. Вопросы с инструментарием поддержать все это.
я Заказчиков, с которыми не везёт, не беру.
Мне, чаще приходилось разгребаться с «оставь надежду всяк сюда входящий» :)
«Kanban» не требует указания сроков, сроки ни как не оговариваются в этой «методологии», «Scrum» — это о сроках, там сроки — это краеугольный камень.
он для того что бы загружать «участок» работы ( сотрудника, команду ) таким образом что бы не замедлять работу всей «линии» ( проектной команды, фирмы ), то есть «Kanban» для гармоничной загрузки участков производства, а «Scrum» это что бы регулярно ( в заранее определённые сроки ) делать релизы.
он для того что бы загружать «участок» работы ( сотрудника, команду ) таким образом что бы не замедлять работу всей «линии» ( проектной команды, фирмы ), то есть «Kanban» для гармоничной загрузки участков производства, а «Scrum» это что бы регулярно ( в заранее определённые сроки ) делать релизы.
Бизнес всегда интересуют сроки, когда они получат новую нужную им «фичу».
Это он требует указания срока, какой бы вы технологический подход/метод не использовали бы для разработки.
В Kanban как и в Scrum есть Product Backlog. В обоих случаях они должны быть приоритезированны, чтобы можно было понять какие задач делать в первую очередь и в какой последовательности.
Сроки для задач в в Scrum высчитываются из длительности спринта, его емкости (часов в спринте) и трудоемкости задачи (часов на её выполнение). Часы здесь условно, хоть в попугаях может быть единица измерения.
Гибкое планирование выпуска релизов 101 (на основе Excel)
Сроки в Kanbane определяются на основе показателя срока нахождения задачи на доске (время цикла) и ограничения на количество задач в работе. Если одновременно делать можно две задачи. То приведенному выше списку задач также можно построить прогноз.
Канбан в IT (Kanban Development).
Проблема и Waterfall, и RUP, и Scrum в том, что внутри списка релиза всегда находятся уже выполненные задачи, которые ждут даты назначенной для выхода релиза.
В случае с Waterfall — полгода, c RUP — квартал, с Scrum — от недели до месяца. В Kanban, в его космическом варианте, выполненная задача не ждёт выполнения остальных задач для её релиза, она сразу идёт релизится.
Это он требует указания срока, какой бы вы технологический подход/метод не использовали бы для разработки.
В Kanban как и в Scrum есть Product Backlog. В обоих случаях они должны быть приоритезированны, чтобы можно было понять какие задач делать в первую очередь и в какой последовательности.
Сроки для задач в в Scrum высчитываются из длительности спринта, его емкости (часов в спринте) и трудоемкости задачи (часов на её выполнение). Часы здесь условно, хоть в попугаях может быть единица измерения.
Гибкое планирование выпуска релизов 101 (на основе Excel)
Сроки в Kanbane определяются на основе показателя срока нахождения задачи на доске (время цикла) и ограничения на количество задач в работе. Если одновременно делать можно две задачи. То приведенному выше списку задач также можно построить прогноз.
Канбан в IT (Kanban Development).
Проблема и Waterfall, и RUP, и Scrum в том, что внутри списка релиза всегда находятся уже выполненные задачи, которые ждут даты назначенной для выхода релиза.
В случае с Waterfall — полгода, c RUP — квартал, с Scrum — от недели до месяца. В Kanban, в его космическом варианте, выполненная задача не ждёт выполнения остальных задач для её релиза, она сразу идёт релизится.
В Kanban, в его космическом варианте, выполненная задача не ждёт выполнения остальных задач для её релиза, она сразу идёт релизится.
Никакого космоса, это вполне реально. На мой взгляд, все сводится к двум вещам: как сделать задачку поменьше и как выкатить её побыстрее. Первое достигается по большей части планированием — можно ведь
выкатить форму из 10 полей, а не из 20, без умной геолокации и подсказок при вводе. Тут скорее вопрос в том, готов ли ваш менеджмент продавать настолько быстро меняющийся продукт. Второе чисто техническая задача и решается она "инженерными подходами":
- SRP и модульность (ака "микросервисы"): понижает связность кода, позволяя разделять ужас на более мелкие ужасы вашей реализации. В результате измнения в одном маленьком модуле технически не влияют на другие
- TDD/BDD — позволяет создавать ТОЛЬКО то, что нужно, без излишеств, не тратя время по-напрасну
- хороший уровень авто-тестов — не только про регрессию, имея хороший уровень модульности можно не напрягаясь гонять тесты параллельно среди модулей
- быстрый CI — позволяет деплоить задачу по клику мышки (мы пока до деплоя по коммиту не дошли) и не думать о том как там все устроено и какой опять конфиг надо править
Ко всему этому можно прийти, тут ничего сложного. Как? Я в своё время это очень просто объяснял коллегам: теперь в нашем Definition of Done десятым пунктом стоит "prod deploy" и "prod test" — с таким подходом все стали искать возможности выкатываться максимально быстро, стали делить задачи на куски, уходить от зависимостей, лучше понимать значение "Lean философия". Сейчас каждый релизит свою задачу самостоятельно, когда посчитает нужным.
Тут главное, что Kanban далеко не всем нужен, и то, как работает команда исполнителей, должно быть продиктовано условиями сверху, со стороны бизнеса, а не снизу, со стороны самих исполнителей.
мой комент был о том что в Kanban мы заранее себе сроки не назначаем, как раз Kanban это про поиск гармоничных сроков, а в Scrum у тебя есть ритм работы и ты выбираешь себе часть работы которая в этот ритм уложиться.
Kanban — о том как выдать результат (готовый продукт).
Scrum — о том как всегда в пятницу выкатить очередной промежуточный релиз.
Kanban — сделать с тем что бы завершить.
Scrum — делать с тем что бы продолжить.
поэтому я согласен что Scrum это двухнедельные релизы, но не согласен с тем что Kanban — ежедневные, могут быть недельные, могут быть месячные, могут быть годовые — как работу выстроите.
Kanban — о том как выдать результат (готовый продукт).
Scrum — о том как всегда в пятницу выкатить очередной промежуточный релиз.
Kanban — сделать с тем что бы завершить.
Scrum — делать с тем что бы продолжить.
поэтому я согласен что Scrum это двухнедельные релизы, но не согласен с тем что Kanban — ежедневные, могут быть недельные, могут быть месячные, могут быть годовые — как работу выстроите.
В Kanban, в его космическом варианте, выполненная задача не ждёт выполнения остальных задач для её релиза, она сразу идёт релизится.
Никакого космоса, это вполне реально. На мой взгляд, все сводится к двум вещам: как сделать задачку поменьше и как выкатить её побыстрее.
Имелось ввиду, что «родители» этих методологий разные, вышли они из разных «источников» и решали задачи в условиях разного приоритета одних и тех же требований. Вроде как не имеет смысла поставить ядерный реактор на подпорках в первой итерации а потом обкладывать бетоном.
ИТ — просто адаптировал под себя методологии, ища наиболее удобную и технологически реализуемую. Вот развитие и привело к «развертыванию по комиту». Но опять-же, скорость адаптации бизнеса и людей в нем- конечна, и менять по 3 раза в день логику и UI не самое разумное.
Достаточно странно смотреть на «большой» проект. У вас трудоемкость 6500 часов, т.е. 3 человекогода. Если смотреть на срок в полтора года, то получаем чудовищную команду в 2 землекопа. Бюджет аж миллионов 10-15 рублей
Для подобного чудовищного ПРОЕКТА нужно примерно 0.2-0.3 FTE нормального РМа.
Мораль — автора надо увольнять за профнепригодность и трату времени на всякую хрень вместо работы
Для подобного чудовищного ПРОЕКТА нужно примерно 0.2-0.3 FTE нормального РМа.
Мораль — автора надо увольнять за профнепригодность и трату времени на всякую хрень вместо работы
dmitrybelsky у вас корректная математика.
Специально для вас написал статью Причина недопонимания между нами и неверного использования технологий. По мотивам статьи «Пять миров» (ПО)
Вы упускаете из виду окружающий контекст проекта: был ли у меня в работе только этот проект или их было много, может ли быть вся команда разработки отдана Заказчику на данный проект и все прочие работы по развитию системы остановлены, позволяет ли архитектура системы распараллелить работы по разным проектам…
И делаете выводы:
Специально для вас написал статью Причина недопонимания между нами и неверного использования технологий. По мотивам статьи «Пять миров» (ПО)
Вы упускаете из виду окружающий контекст проекта: был ли у меня в работе только этот проект или их было много, может ли быть вся команда разработки отдана Заказчику на данный проект и все прочие работы по развитию системы остановлены, позволяет ли архитектура системы распараллелить работы по разным проектам…
И делаете выводы:
Мораль — автора надо увольнять за профнепригодность и трату времени на всякую хрень вместо работы
Какая разница? На нормального проджекта можно свободно повесить от 3 до 10 таких мега-проектов.
Если РМ не справляется с управлением ожиданиями у заказчика или иных стейкхолдеров или не может выбить ресурсы — то вывод смотри в моем первом сообщении)
Вы потратили дофига собственного времени на все эти свистоперделки вместо того, чтоб один раз прочитать РМВОК и заняться непосредственно работой. По моим оценкам данная статья на хабре встала вашему работодателю как мин в 200к прямых убытков и ещё пару мультов косвенных
Если РМ не справляется с управлением ожиданиями у заказчика или иных стейкхолдеров или не может выбить ресурсы — то вывод смотри в моем первом сообщении)
Вы потратили дофига собственного времени на все эти свистоперделки вместо того, чтоб один раз прочитать РМВОК и заняться непосредственно работой. По моим оценкам данная статья на хабре встала вашему работодателю как мин в 200к прямых убытков и ещё пару мультов косвенных
dmitrybelsky,
Моему работодателю эта статья не стоила ни копейки, а проект имел защищенное Технико-Экономическое Обоснование и генерировал прибыль компании более 5 лет.
Руководство принимало непосредственное участие в принятии решении о том, что будем на этом проекте пробовать новый подход к выполнению работ. Все затраты времени были санкционированы.
На нормального проджекта ничего нельзя повесить. Где сели, там с него и слезите, потому что это нормальный проджект. Нормальный РМ работает на своё портфолио и репутацию. На не нормального можно повесить хоть 100 таких проектов. В этот раз вы уже не в ладу с собственной математикой про 0.2-0.3 FTE.
Судя по вашей манере общения, вы менеджер среднего звена (B-level) которому повезло перескочить уровень работы «нормальным PM-ом», потому позволяете себе много вольностей и видимо не только на сайте, но и в работе. «Чего нет в игре, того нет и в жизни.» (с — Сергей Кириенко)
В плане выстраивания взаимоотношений, в том числе и со стейкхолдерами, у вас явно присутствует недостаток квалификации иначе не позволяли бы себе подобных публичных высказываний, которые потом не сможете удалить.
Пишите свои статьи и выносите их на суд ИТ-сообщества, чтобы получить независимую оценку своей квалификации. Буду ждать, даже специально подписался на вас.
Моему работодателю эта статья не стоила ни копейки, а проект имел защищенное Технико-Экономическое Обоснование и генерировал прибыль компании более 5 лет.
Руководство принимало непосредственное участие в принятии решении о том, что будем на этом проекте пробовать новый подход к выполнению работ. Все затраты времени были санкционированы.
На нормального проджекта ничего нельзя повесить. Где сели, там с него и слезите, потому что это нормальный проджект. Нормальный РМ работает на своё портфолио и репутацию. На не нормального можно повесить хоть 100 таких проектов. В этот раз вы уже не в ладу с собственной математикой про 0.2-0.3 FTE.
Судя по вашей манере общения, вы менеджер среднего звена (B-level) которому повезло перескочить уровень работы «нормальным PM-ом», потому позволяете себе много вольностей и видимо не только на сайте, но и в работе. «Чего нет в игре, того нет и в жизни.» (с — Сергей Кириенко)
В плане выстраивания взаимоотношений, в том числе и со стейкхолдерами, у вас явно присутствует недостаток квалификации иначе не позволяли бы себе подобных публичных высказываний, которые потом не сможете удалить.
Пишите свои статьи и выносите их на суд ИТ-сообщества, чтобы получить независимую оценку своей квалификации. Буду ждать, даже специально подписался на вас.
Когда я говорю про затраты работодателя — то имею в виду
1. Использование непроверенных методологий несет дополнительные риски. Их оценки я не увидел
2. Освоение этих технологий стоит денег. Ориентировочно — в районе одного человекомесяца.
3. Пока идет освоение — страдают другие проекты и этот не движется с места
Если руководство было радо экспериментам, то ок. Вы грамотно продали идею повышения квалификации за счет работодателя
У любого РМа есть начальник PMO. С ним всегда можно договориться.
Про нормативы — если критикуете, то дайте свою оценку вовлеченности PMa в проект с командой из двух человек (даже из трех :) ) в тех самых презренных FTE. Пока я вижу высказывания в духе: «Вы все врёте»
Про ярлыки — сразу скажу, вы по всем пунктам дали промах. РМом я был всего пару-тройку лет. И менеджером
Касательно выступлений — не вижу ни одного высказывания со своей стороны, которое я не мог бы подтвердить еще раз основываясь на вашем же тексте.
Недостаток опыта виден скорее с вашей стороны, иначе бы появилось банальное обоснование выбора конкретной методологии для данного проекта
С моей точки зрения вся статья выглядит следующим образом:
У нас есть мелкий ненужный проект.
Ура, мы тут обнаружили новый фреймворк управления проектами!
Попробуем!
Проект вроде сделали
Запилим статью на хабре
1. Использование непроверенных методологий несет дополнительные риски. Их оценки я не увидел
2. Освоение этих технологий стоит денег. Ориентировочно — в районе одного человекомесяца.
3. Пока идет освоение — страдают другие проекты и этот не движется с места
Если руководство было радо экспериментам, то ок. Вы грамотно продали идею повышения квалификации за счет работодателя
У любого РМа есть начальник PMO. С ним всегда можно договориться.
Про нормативы — если критикуете, то дайте свою оценку вовлеченности PMa в проект с командой из двух человек (даже из трех :) ) в тех самых презренных FTE. Пока я вижу высказывания в духе: «Вы все врёте»
Про ярлыки — сразу скажу, вы по всем пунктам дали промах. РМом я был всего пару-тройку лет. И менеджером
Касательно выступлений — не вижу ни одного высказывания со своей стороны, которое я не мог бы подтвердить еще раз основываясь на вашем же тексте.
Недостаток опыта виден скорее с вашей стороны, иначе бы появилось банальное обоснование выбора конкретной методологии для данного проекта
С моей точки зрения вся статья выглядит следующим образом:
У нас есть мелкий ненужный проект.
Ура, мы тут обнаружили новый фреймворк управления проектами!
Попробуем!
Проект вроде сделали
Запилим статью на хабре
Когда я говорю про затраты работодателя — то имею в виду
1. Использование непроверенных методологий несет дополнительные риски. Их оценки я не увидел
2. Освоение этих технологий стоит денег. Ориентировочно — в районе одного человекомесяца.
3. Пока идет освоение — страдают другие проекты и этот не движется с места
С каких пор RUP не проверенная методолгия? начало 200х была известна.
Что значит «дополнительные риски»? Риски есть всегда, вопрос цены рисков, стратегии их обработки или отказа.
Что значит «освоени методологии»? или ты понимашеь что делаешь и зачем или нет. Ресурсам — задачи и сама мотодология им побоку в общем случае.
Не движется с места «куда»? Все работы играли ту или иную роль. Все работы играли на руку подрядчику. Все предварительные работы должны быть проведены или подрядчик просто попадает на штрафы из-за не выполненных условий договора.
Работа РМ — идентифицировать цели проекта, оценить риски, выбрать методолгию управления проектом и адаптировать под цели клиента. Уж после думать про всякие ресурсы/capacity management, communication plan и прочее.
Или вы полагаете, что нужно быть тупо подписать контракт без юридической защиты и без предварительной оценки? смешно.
dmitrybelsky,
Сперва вы были против того, что я назвал проект большим, а по вашим меркам он таковым не является. (Общепринятого стандарта-мерки нет или приведите ссылку на него, чтобы доказать обратное)
Теперь вы против того, что мы проэкспериментировали с новым фреймворком управления проектами на «мелком ненужном проекте», то есть мы должны были взять что-то покрупнее, чтобы словить указанные вами риски и увеличенные соразмерные проекту затраты на освоение на крупном проекте, верно?
Сперва вы были против того, что я назвал проект большим, а по вашим меркам он таковым не является. (Общепринятого стандарта-мерки нет или приведите ссылку на него, чтобы доказать обратное)
Теперь вы против того, что мы проэкспериментировали с новым фреймворком управления проектами на «мелком ненужном проекте», то есть мы должны были взять что-то покрупнее, чтобы словить указанные вами риски и увеличенные соразмерные проекту затраты на освоение на крупном проекте, верно?
Мне нравился RUP всем, кроме какого-то чудовищного обилия бумажек. А если бумажка создалась, кто-то должен поддерживать ее актуальность. Есть ли метод сократить количество производимых документов?
ganqqwerty, вы задали хороший вопрос.
Краткий ответ таков: Не делайте документацию, которая вам не нужна.
Длинный ответ:
У RUP и у Стандарта управления проектами (PMI, PMBoK) предусмотрено множество документов, которые призваны помочь сделать проект/продукт, но это не значит что в первом случае надо обложится всевозможными UML-диаграммами, а во втором — планами на каждый возможный чих.
Пишите только те документы, которые помогают вам решать проблемы во взаимодействии между разными заинтересованными сторонами и участниками команды, экономят команде время на следующих этапах работ и позволят без травм для бизнеса и системы переделать функциональный модуль (подсистему) через Н-лет, когда это понадобится.
Поэтому предлагаю делить документацию на базовую (core) и факультативную (optional). Первая однозначно нужна в любом случае и должна быть всегда актуальной. Вторая делается под конкретную ситуацию и необязательна должна быть актуальной.
Вот моё представление о базовой документации:
Весь список «бумажек» нужный для разработки и доработки:
Здесь ТЗ в его бизнес-части выступает общей основной, и для пользовательской документации, и для проектно-технической документации.
Завязываться на описание просто самой системы и её возможностей — это потом не разобрать, кто и для чего использует систему, и регулярные жалобы Заказчиков на то, что новая реализация функции, которую мы сделали для одного Заказчика, не устраивает другого Заказчика, который пользовался ею и до её изменения.
Пример того, как это работает Каким должно быть ТЗ на Корпоративную ИС?
Честно скажу, что считаю что вам лучше знакомы методы как уменьшить количество производимых документов. Посмотрел ваши статьи про то что вы разрабатываете базы знаний, а производимая документация и есть база знаний.
Краткий ответ таков: Не делайте документацию, которая вам не нужна.
Длинный ответ:
У RUP и у Стандарта управления проектами (PMI, PMBoK) предусмотрено множество документов, которые призваны помочь сделать проект/продукт, но это не значит что в первом случае надо обложится всевозможными UML-диаграммами, а во втором — планами на каждый возможный чих.
Пишите только те документы, которые помогают вам решать проблемы во взаимодействии между разными заинтересованными сторонами и участниками команды, экономят команде время на следующих этапах работ и позволят без травм для бизнеса и системы переделать функциональный модуль (подсистему) через Н-лет, когда это понадобится.
Поэтому предлагаю делить документацию на базовую (core) и факультативную (optional). Первая однозначно нужна в любом случае и должна быть всегда актуальной. Вторая делается под конкретную ситуацию и необязательна должна быть актуальной.
Вот моё представление о базовой документации:
- В основе всего лежит один документ, который описывает текущую реализацию бизнес-процесса в контексте использования информационной системы. В карточке описания бизнес-процесса указывается, на каких функциональных модулях системы он построен.
- Как только бизнес хочет начать работать по другому, мы перепроектируем бизнес-процесс и указываем какие его участки на что меняем. К этому привязываются изменения в функциональных модулях.
- Если другой бизнес-процесс пытается использовать для себя функциональный модуль, то Реестр ТЗ подсказывает какие бизнес-процессы уже на нём сидят.
- В итоге для бизнеса всё сводится к трём документам: Документ версии 1.0, Вносимые изменения, Документ версии 1.1. И такая же картина с технической стороны для функциональных модулей (подсистем).
Весь список «бумажек» нужный для разработки и доработки:
- Реестр ТЗ.
- ТЗ бизнес-часть (содержит описание бизнес-сценария и его системных сценариев использования).
- Дополнение к ТЗ бизнес-часть (содержит указание что на что меняем в бизнес-сценарии и системных сценариях), как правило, после выполнения работ и подготовки обновленной версии ТЗ «выкидывается».
- ТЗ техническая часть (содержит раскладку системных сценариев на сущности системы).
- Дополнение к ТЗ техническая часть.
Здесь ТЗ в его бизнес-части выступает общей основной, и для пользовательской документации, и для проектно-технической документации.
Завязываться на описание просто самой системы и её возможностей — это потом не разобрать, кто и для чего использует систему, и регулярные жалобы Заказчиков на то, что новая реализация функции, которую мы сделали для одного Заказчика, не устраивает другого Заказчика, который пользовался ею и до её изменения.
Пример того, как это работает Каким должно быть ТЗ на Корпоративную ИС?
Честно скажу, что считаю что вам лучше знакомы методы как уменьшить количество производимых документов. Посмотрел ваши статьи про то что вы разрабатываете базы знаний, а производимая документация и есть база знаний.
Вот моё представление о базовой документации:
…
Весь список «бумажек» нужный для разработки и доработки:
А куда вы включаете «критерии приемки», сценарии приемо-сдаточных испытаний?
Lofer бизнес-сценарий и системные сценарии использования это и есть сценарии приемо-сдаточных испытаний.
Критерии приемки:
С Заказчиком и Бизнес-Пользователями мы проверяем, что система выполняет нормальный вариант эксплуатации предусмотренный указанными выше системными сценариями и поддерживает новый бизнес-процесс (бизнес-сценарий).
Обычно я говорю что это на 50% готовые приемочные тесты.
Системные сценарии не описывают, что должно происходить при «ненормальной» эксплуатации, ничего не говорят о тестах эмулирующих эксплуатацию под промышленной нагрузкой, регрессионных тестах.
Поэтому создание полной тестовой документации, включая план тестирования, я считаю факультативной задачей. Если система относится к критически важным для бизнеса или есть экономика которая оправдывает высокое качество и покрытие тестированием, то тогда имеет смысл расширять документацию.
Повторюсь, идея такая — делать документацию там где уже есть проблемы или где это экономически оправдано. Иначе вместо работы мы будем заниматься тем, что раскладывать солому во всех местах где можем подскользнуться.
Критерии приемки:
- это соответствие того, что выдает продукт, тому что записано в качестве выхода для системного сценария использования.
- это отработка всех системных сценариев в симфонии (целостность выполнения бизнес-сценария).
С Заказчиком и Бизнес-Пользователями мы проверяем, что система выполняет нормальный вариант эксплуатации предусмотренный указанными выше системными сценариями и поддерживает новый бизнес-процесс (бизнес-сценарий).
Обычно я говорю что это на 50% готовые приемочные тесты.
Системные сценарии не описывают, что должно происходить при «ненормальной» эксплуатации, ничего не говорят о тестах эмулирующих эксплуатацию под промышленной нагрузкой, регрессионных тестах.
Поэтому создание полной тестовой документации, включая план тестирования, я считаю факультативной задачей. Если система относится к критически важным для бизнеса или есть экономика которая оправдывает высокое качество и покрытие тестированием, то тогда имеет смысл расширять документацию.
Повторюсь, идея такая — делать документацию там где уже есть проблемы или где это экономически оправдано. Иначе вместо работы мы будем заниматься тем, что раскладывать солому во всех местах где можем подскользнуться.
Sign up to leave a comment.
Опыт перехода с Waterfall на методологию RUP для реализации больших ИТ проектов