D>Ну так, может, потому и книг нет, что бред? И никто не говорит, что практикует waterfall, просто потому, что не модно и не солидно сейчас это говорить.
У нас водопад. Полет нормальный. Проекты сдаются успешно и во время.
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, dshe, Вы писали:
D>>Ну так, может, потому и книг нет, что бред? И никто не говорит, что практикует waterfall, просто потому, что не модно и не солидно сейчас это говорить.
V>У нас водопад. Полет нормальный. Проекты сдаются успешно и во время.
ПК>>In the previous section we stated that the best process for a project is the smallest process that project could afford.
G>Процесс — это не есть неотвратимое зло, которое надо минимизировать <...> процесс направлен на достижение вполне конкретных целей <...>
Все зависит от того, что понимать под "the smallest process that project could afford". Как я понимаю, это как раз и значит, "smallest process", при котором заданные цели достигаются. В этом случае, таки да, "больший" процесс является злом, т.к. приводит к большим издержкам.
It may be necessary to produce something other than software in order to eventually produce the software that is our goal. It may also be necessary to produce some artifact that acts to support the software that is our goal. However, such intermediate artifacts are not the goal of the process. They are, at best, a means to an end. They also represent a cost. A good process will decrease the demand for such intermediate artifacts to the barest possible minimum.
Собственно, минимизация издержек -- и есть самая суть agile, при определенной трактовке, разделяемой не всеми. (При этой трактовке) в этом они очень родственны с lean product development / lean manufacturing, родившимися из TPS (Toyota Production System).
G>Лучший процесс для проекта такой, который позволет не просто достичь поставленных целей, о которых у них вообще ни слова, но сделать это оптимальным способом. Т.е. дешевле и эффективнее.
Ага, мне кажется, об этом и идет речь.
The goal of a software process is the production of software. Software that works, software that is on time, software that is within budget, software that can be maintained, software that can be reused. If this goal is met while preserving the rights of the developers and customers, then the process is a success.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
DM>>А что мешает быть ближе к заказчику? На пьянки ходить вместе, жить жизнью заказчика... G>Вот, как говорится, что бы ни делать, лишь бы не работать. G>1. Ходить на пьянки с заказчиком не лучший способ управления требованиями. G>2. "Близость к заказчику" тоже вам ничего не гарантирует. "Наши студенты становятся ближе к знаниям — ведь здание общежития находится всего в 50 метраж от университетской библиотеки". G>3. У заказчика своя жизнь, у вас своя. Я предпочитаю жить своей жизнью, и управлять требованиями.
Пример не очень подходит. Отвечу просто — а может у них цели разные?
DM>>Не только программировать их бизнес, но знать и быть в их бизнесе? G>Знание и понимание их бизнеса — слишком широко берете. Вам заказчики платят не за это. Они платят вам за то, что вы делаете ровно то, что им нужно — даже если они сами не могут это сформулировать, а не за совместные пьянки, и на за разговоры по душам. Более того, они были бы благодарны вам за то, что вы не заставляете их это формулировать. Именно поэтому вам и платят — потому что у заказчика в частности нет специалистов по составлению ТЗ и анализу требований.
Вот поэтому получается то, что получается.
Уверяю — заказчик не быдла, он хочет успеха. Только вопрос — хотите ли его вы?
Мне вот не понятен одно, а зачем ТЗ ? (не путить с визион-документом в 2-3 странички, а подробное, верифицированное, ревьюированное и всякие бузззвордс слова).
D>>Ну так, может, потому и книг нет, что бред? И никто не говорит, что практикует waterfall, просто потому, что не модно и не солидно сейчас это говорить. V>У нас водопад. Полет нормальный. Проекты сдаются успешно и во время.
Дык, так у нас тоже водопад
Ты давай детали выкладывай
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, prVovik, Вы писали:
V>>Здравствуйте, dshe, Вы писали:
D>>>Ну так, может, потому и книг нет, что бред? И никто не говорит, что практикует waterfall, просто потому, что не модно и не солидно сейчас это говорить.
V>>У нас водопад. Полет нормальный. Проекты сдаются успешно и во время.
G>Можешь описать свой процесс разработки?
Процесс очень формальный, с кучей участников, activity и документов. Весь описывать не буду (я все и сам не знаю ), напишу только в очень общих чертах.
Приходит человек из бизнеса, приносит в IT BRD (business requirements document). В этом документе он пишет свои идеи, мысли и т.д.
В девелоперской команде сидит бизнес-аналитик. Он изучает этот BRD и много общается с бизнесом, пытаясь понять, что у него на уме, какие проблемы и т.д.
Потом аналитик пишет SRS. SRS согласовывается с бизнесом и разработчиками. Программисты подключаются к проекту на этапе согласования SRS и могут инициировать изменение SRSa в соответствии с технической целесообразностью. Проходят множество митингов с участием представителей бизнеса, бинес-аналитика, девелопмент лидеров, программистов и, возможно, архитектора (если проект крупный и затрагивает много работающих систем). Весь этот базар заканчивается принятием и утверждением SRS. Замечу, что потом SRS в принцепе меняться может на любом этапе (хотя это сильно не приветствуется и означает, что на соответствующей фазе что-то профакали).
Затем программисты начинают программировать в ворде и писать TDS — technical design specification. Выглядт это так, как будто они пишут программу, но в качестве языка программирования используется обычный человеческий язык. На выходе получаем документ, в котором на нужном уровне детализации описано что и как будет сделано по проекту. В процессе этой деятельности дополнительно уточняется SRS. На основе TDS составляется project plan.
Итак, имеем три основных проектных документа:
1. BRD — что хотел заказчик.
2. SRS — как желаения заказчика были интерпретированы.
3. TDS — как надо реализовать интерпретацию желаний заказчика.
Любому новому человеку, подключающемуся к проекту дают именно три этих документа, прочитав которые он "врубается" в проект.
Далее начинается фаза разработки и программисты начинают писать код. Тут формальностей минимум и в разных командах эта фаза проходит по-разному. Выход из этой фазы опеределен конкретной датой явно и заранее.
Потом начинается SIT — system integration test, где к проекту подключаются тестеры. На данном этапе помимо тестирования, обкатывается стандартный процесс деплоймента проекта, пишется документация по деплойменту и саппорту.
Затем UAT — users acceptable test, где с системой играется заказчик.
В конце-концов проект выкатывается на продакшен и начинается фаза стабилизации.
Никто не утверждает, что описанный мной процесс является идеальным и подходит на все случаи жизни. Но для тех проектов, которые мы выполняем и в тех условиях, с теми заказчиками — он работает очень хорошо. Хотя, изначально я был настроен весьма скептически, так как читал много книг-ужасов про водопад
Здравствуйте, denis miller, Вы писали:
DM>Мне вот не понятен одно, а зачем ТЗ ?
ТЗ нужен программистам, чтобы они знали, что должны сделать.
ТЗ нужен заказчику, чтобы он заранее знал, что получит в конце разработки.
ТЗ нужен для того, чтобы сторонний человек мог разобраться в деталях функционирования готового проекта.
DM>>Мне вот не понятен одно, а зачем ТЗ ? V>ТЗ нужен программистам, чтобы они знали, что должны сделать. V>ТЗ нужен заказчику, чтобы он заранее знал, что получит в конце разработки. V>ТЗ нужен для того, чтобы сторонний человек мог разобраться в деталях функционирования готового проекта.
V>Итак, имеем три основных проектных документа: V>1. BRD — что хотел заказчик. V>2. SRS — как желаения заказчика были интерпретированы. V>3. TDS — как надо реализовать интерпретацию желаний заказчика.
Это оличный подход. Строго формализованный и т.п. Но это не водопад
Но это к слову.
Здравствуйте, denis miller, Вы писали:
DM>То есть цель ТЗ — узнать что делать?
У ТЗ нет целей. ТЗ выполняет множество разных функций. И одна из функций, которую выполняет ТЗ в период составления TDS и в период написания кода — это разъяснить программисту, что он должен сделать. До этих периодов и после них SRS выполняет другие важные функции.
Здравствуйте, denis miller, Вы писали:
V>>Итак, имеем три основных проектных документа: V>>1. BRD — что хотел заказчик. V>>2. SRS — как желаения заказчика были интерпретированы. V>>3. TDS — как надо реализовать интерпретацию желаний заказчика.
DM>Это оличный подход. Строго формализованный и т.п. Но это не водопад
Почему?
DM>Только зачем это делать?
Чтобы работать успешно и эффективно
Ты, видимо, намекаешь, что agile всегда работает эффективнее водопада. Это не так. Есть случаи, когда эффективнее гибкие процессы, а есть когда эффективнее водопад. Мое мнение, что если можно на некотором проекте применить водопад, то именно его и надо использовать. Если же водопад по разным причинам на данном проекте забуксует, то тогда agile.
Здравствуйте, denis miller, Вы писали:
DM>Пример не очень подходит. Отвечу просто — а может у них цели разные?
У кого "у них"? У вас с заказчиком? Разумеется они разные. И что?
DM>>>Не только программировать их бизнес, но знать и быть в их бизнесе? G>>Знание и понимание их бизнеса — слишком широко берете. Вам заказчики платят не за это. Они платят вам за то, что вы делаете ровно то, что им нужно — даже если они сами не могут это сформулировать, а не за совместные пьянки, и на за разговоры по душам. Более того, они были бы благодарны вам за то, что вы не заставляете их это формулировать. Именно поэтому вам и платят — потому что у заказчика в частности нет специалистов по составлению ТЗ и анализу требований. DM>Вот поэтому получается то, что получается.
У всех получается по разному. У нас проблем с заказной разработкой не было, после того как мы начали анализ проводить. Куда-то все изчезли почему-то сразу.
DM>Уверяю — заказчик не быдла, он хочет успеха. Только вопрос — хотите ли его вы?
Я не считаю заказчика "быдлой". Я вам говорю о том, что для заказчика глупость держать у себя профессионала в штате, обученного составлять ТЗ и грамотно ставить задачу. Он нужен один раз, при выполнении вашего заказа. Поэтому, его должны предоставить вы. Ну, можно конечно сетовать на несправедливость жизни и плохие методологии — как вариант.
DM>Мне вот не понятен одно, а зачем ТЗ ? (не путить с визион-документом в 2-3 странички, а подробное, верифицированное, ревьюированное и всякие бузззвордс слова).
Странный вопрос. Зачем заключают письменные договора для фиксации сделок и договоренностей? Чтобы избежать разного толкования условий сделки вами и заказчиком. ТЗ — приложение к вашему договору с заказчиком, защищает вас от изменений ключевых требований, защищает вас и заказчика от проблем на приемке, фиксирует единое понимание scope-а работ и требования к результату, фиксирует количество и сроки этапов работ.
Оплата происходит по окончании каждого этапа, по подписании акта сдачи-приемки работ. Приложением к ТЗ идет план-график, где указана стоимость этапов, описывает результаты каждого этапа, и указывает, какая работа проводится на каждом этапе.
Здравствуйте, fuurin, Вы писали:
V>> Но для тех проектов, которые мы выполняем и в тех условиях, с теми заказчиками — он работает очень хорошо.
F>Круто. А какая отрасль (я так понял, что вы специализируетесь на чём-то),
Да отрасль то самая обычная — я описал работу IT отдела одной ооочень крупной международной компании.
Основная специфика в том, что команды очень распределены. Стандартная ситуация, когда проект разрабатывает одна команда, после окончания разработки делает хендовер другой команде (которая будет заниматься новыми фичами и фиксом багов), а саппорт на продакшене осуществляет третья. Причем все три команды находятся в разных странах, а иногда и континентах. В таких условиях проект без актуальной и полной документации — это мертворожденный проект, он просто никому не нужен.
F>какой длительности проекты,
Проекты есть разные, длинные и не очень. Лично я работаю а тех, что не очень. Это порядка двух человеко-лет работы программистов.
F>как долго применяете эту схему?
G>Есть два вида разработки ПО — разработка (коробочного) продукта, и разработка на заказ под нужды внешнего заказчика.
Гм, как мне кажется, есть еще один вид разработки ПО — когда заказ дается на разработку, а на самом деле имеется в виду НИИКР. Т.е., по сути, заказчик приходит и ставит цель. Не факт, что вообще выполнимую. И хочет для реализации этой цели получить готовый продукт (а не постановку для его создания).
Возможно, взятие таких заказов есть большой прокол того менеджера, который согласился (и уж тем более который согласился на fixed cost), но для начальника разработки это не облегчает задачу.
(Разные слова про оторванность development и sales во многих компаниях опустим).
Так как задача чисто НИРовская, то ее осмысленно делать чередой развивающихся прототипов, что сейчас проще описать в терминах agile (как более популярных). Да и драйва чуть больше.
P.S. С внутренними продуктами тоже все забавно — у меня были случаи, когда внутренние заказчики (т.е. будущие пользователи системы) сначала выдвигали одни требования, даже подписывались под ними, потом меняли на полностью противоположные — и так раза три.
Впрочем, это, разумеется, тоже при разработке продукта, для всех участников "нового", т.е. исследовательских работ.
Гм, а часто ли встречаются задачи, которые не являются исследовательскими?
Здравствуйте, Дельгядо Филипп, Вы писали:
G>>Есть два вида разработки ПО — разработка (коробочного) продукта, и разработка на заказ под нужды внешнего заказчика.
ДФ>Гм, как мне кажется, есть еще один вид разработки ПО — когда заказ дается на разработку, а на самом деле имеется в виду НИИКР. Т.е., по сути, заказчик приходит и ставит цель. Не факт, что вообще выполнимую. И хочет для реализации этой цели получить готовый продукт (а не постановку для его создания).
Ок, берем стандартный ГОСТосвский классификатор. НИР, НИОКР, ОКР.
Сложные госзаказы заказы бьются на серию проектов. Часто выдают НИР на разработку технических требований, результат которого — ТЗ. НИР управляется совсем не так, как ОКР — там другие правила. Во время НИР вы можете делать прототипы и вообще — все, что сочтете необходимо для разработки ТЗ, однако, результатом и целью работ является именно скорейшее создание корректного ТЗ, т.е. получение знания, а не получение каких-либо продуктов. Грубо говоря, такой НИР впрямую соответствует фазе Inception в RUP.
Можно завести НИОКР — если кроме знания требуется концептуальный прототип, доказывающий и демонстрирующий возможности. К нему требования — он должен именно доказывать и демонстрировать, а не быть продуктом промышленного качества, что опять-таки накладывает серьезный отпечаток на процесс разработки — требованиями управлять надо, а во на качестве и функицональной полноте надо экономить. Хотя, формулировка НИОКР чрезвычайно гибка — таким образом можно обозвать и ОКР (где требуется промышленное качество и полная функциональность) с большой долей исследовательских работ. Однако, такой большой НИОКР желательно бить на более мелкие НИР и ОКР — просто потому, что так правильно делать — эффективные методы управления исследованиями и разработкой кардиналоно различаются. Например, продолжительность и трудозатраты на НИР сложно оценить, нет методик — их надо просто ограничивать по общему времени, сделать акцент на целеполагание, и вести итеративно. А вот разработку по известному функционалу (ОКР) довольно просто оценить и запланировать — так надо этим пользоваться, почему нет?
ДФ>Возможно, взятие таких заказов есть большой прокол того менеджера, который согласился (и уж тем более который согласился на fixed cost), но для начальника разработки это не облегчает задачу.
Отнюдь, почему же то прокол. Просто надо отдавать себе отчет, чем НИР от ОКР отличается и применять разные подходы для них. НИР в рамках госзаказов, разумеется, делается только по fixed cost. И это правильно. НИР который нельзя планировать и который рискован по сравнению с ОКР — может не принести результатов, надо обязательно ограничивать по времени и бюджету — это элементарное управление рисками. Надо отдавать себе отчет, какой суммой вы готовы рискнуть — любой менеджер вам это скажет сразу, что если до такой суммы — то нормально, а вот больше такой — это уже извините, мы себе позволить на "фундаментальную науку" не можем. НИР, который занимает неограниченную сумму, в бизнесе не нужен.
ДФ>(Разные слова про оторванность development и sales во многих компаниях опустим). ДФ>Так как задача чисто НИРовская, то ее осмысленно делать чередой развивающихся прототипов, что сейчас проще описать в терминах agile (как более популярных). Да и драйва чуть больше.
Я понимаю, что инженерам хочется думать о своей работе как о чем-то высоком, но "чисто НИРовских" задач в бизнесе практически не бывает — их мало. Подавляющее большинство занимается комбинированием существующих технологий (что хайтеком строго говоря не является), а не их изобретением. Обыкновенно (если компания не технический стартап, и ее инвестор — не венчурный фонд), бюджет делится в пропорции 80% на мйнстрим (ОКР), не более 20% (обычно существенно меньше — не все вообще могут себе позволить бюджеты на НИР — это большой риск) на перспективные направления и инновации (НИР). При этом, менеджмент заинтересован одновременно в увеличении эффективности НИР и сокращении затрат на них — что ведет к акценту на целеполагание и запрету на полномасштабную разработку в рамках НИР.
Описывая всю разработку в терминах agile вы по сути обманиваете менеджмент. Вы стираете границу между НИР и ОКР, убиваете на крупном уровне управление рисками, и подводите свою организацию под значительные риски.
ДФ>P.S. С внутренними продуктами тоже все забавно — у меня были случаи, когда внутренние заказчики (т.е. будущие пользователи системы) сначала выдвигали одни требования, даже подписывались под ними, потом меняли на полностью противоположные — и так раза три.
Симптом отсутствия управления требованиями . Внутренний заказчик не является специалистом ни в сборе и формулировке требований, ни в их анализе. Вы же предполагаете, что полные и непротиворечивые требования должны появиться как-то сами собой. Естественно, этого не происходит.
ДФ>Впрочем, это, разумеется, тоже при разработке продукта, для всех участников "нового", т.е. исследовательских работ. ДФ>Гм, а часто ли встречаются задачи, которые не являются исследовательскими?
Их в нашем деле подавляющее большинство. Не надо путать технологию и науку. Если не знать технологию сбора кубика-рубика — то его сборка тоже бешеный креатив. Если каждый раз изобретать все заново — то жизнь ваша будет увлекательна, конечно. Но вы проиграете.
G>Здравствуйте, Gaperton, Вы писали:
ДФ>>Гм, а часто ли встречаются задачи, которые не являются исследовательскими? G>Их в нашем деле подавляющее большинство. Не надо путать технологию и науку. Если не знать технологию сбора кубика-рубика — то его сборка тоже бешеный креатив. Если каждый раз изобретать все заново — то жизнь ваша будет увлекательна, конечно. Но вы проиграете.
Похоже, я что-то не уловил в терминологии. По моему опыту (специфическому), зачастую заказчик (внешний или внутренний — не важно), заказывая "автоматизацию" или "новую систему управления корпоративным порталом" предполагает решение вполне конкретных целей (улучшение управляемости, увеличение потока пользователей, снижения складских запасов и т.п.).
И первая стадия проекта, по идее, должна быть "исследовательской" — на ней нужно понять, как именно заказчик может выполнить свои цели и какие технические средства ему могут помочь.
Логично в этом случае, как и рекомендуют ГОСТы, сделать сначала НИР, результатом которого будет ТЗ
(правда, не понятно, кто будет этот результат принимать — специалистов такого класса у заказчика скорее всего нет).
Но это, в общем, идеальный случай разумных отношений с заказчиком.
Но, опять-таки, часто встречаются случаи, когда один менеджер продал другому "систему автоматизации, которая решит все ваши проблемы", а даже цели автоматизации в договоре не прописаны — вот тут и начинается вполне обычное веселье — как впихнуть и исследование и собственно разработку в один проект. При этом, по традиции, сроки сжатые.
Вот в этом случае мне представляется разумным начинать с итеративной разработке прототипов (как в НИР и предполагается), держа в голове перерастание этих прототипов в промышленную систему. И в качестве "процесса" для такой разработке подходят некоторые идеи agile (малые команды, тесная коммуникация с заказчиком, ранняя интеграция, постоянное тестирование, приоритезирование и т.п.).
Но, конечно, с проектированием (предварительным) и управлением требованиями (по мере их появления и если вообще это удается делать — я провалил (или вытянул очень большими усилиями) не один проект, прежде чем не осознал важность управления требованиями.
P.S. А что, бывают проекты, в которых выработка ТЗ формально вынесена в отдельный проект, а оценка общего результат происходит по результатам формирования ТЗ? Т.е. в идеале такие есть — но я о них не слышал.
G>Например, продолжительность и трудозатраты на НИР сложно оценить, нет методик — их надо просто ограничивать по общему времени, сделать акцент на целеполагание, и вести итеративно. А вот разработку по известному функционалу (ОКР) довольно просто оценить и запланировать — так надо этим пользоваться, почему нет?
G>Отнюдь, почему же то прокол. Просто надо отдавать себе отчет, чем НИР от ОКР отличается и применять разные подходы для них. НИР в рамках госзаказов, разумеется, делается только по fixed cost. И это правильно. НИР который нельзя планировать и который рискован по сравнению с ОКР — может не принести результатов, надо обязательно ограничивать по времени и бюджету — это элементарное управление рисками.
А если договор с fixed-price на НИР+ОКР вместе? Т.е. одна общая сумма и на то, и на другое. Или есть методики, которые позволяют корректно разделить общие затраты на стадии и определить, когда нужно прекращать НИР?
G>Я понимаю, что инженерам хочется думать о своей работе как о чем-то высоком, но "чисто НИРовских" задач в бизнесе практически не бывает — их мало.
Задача исследовательская не с технической точки зрения (там как раз все обычно очевидно), а с точки зрения удовлетворения потребностей новым способом.
G>Описывая всю разработку в терминах agile вы по сути обманываете менеджмент. Вы стираете границу между НИР и ОКР, убиваете на крупном уровне управление рисками, и подводите свою организацию под значительные риски.
Угу. Я по сути вкладываю консалтинг, сбор требований, выработку ТЗ внутрь проекта. Раз уж не удалось сделать их вне проектных условий.
G>Симптом отсутствия управления требованиями . Внутренний заказчик не является специалистом ни в сборе и формулировке требований, ни в их анализе. Вы же предполагаете, что полные и непротиворечивые требования должны появиться как-то сами собой. Естественно, этого не происходит.
Ну, на получение разумных требований от заказчика я уже давно не рассчитываю. Но что при описании предметной области специалист может ошибиться трижды (увы, проверить по другим источникам это было невозможно, очень узкая специализация) — этого я не предполагал. Но управления требованиями — да, не было. Впрочем, в таких задачах оно бы и не помогло.
Здравствуйте, Дельгядо Филипп, Вы писали:
G>>Здравствуйте, Gaperton, Вы писали:
ДФ>>>Гм, а часто ли встречаются задачи, которые не являются исследовательскими? G>>Их в нашем деле подавляющее большинство. Не надо путать технологию и науку. Если не знать технологию сбора кубика-рубика — то его сборка тоже бешеный креатив. Если каждый раз изобретать все заново — то жизнь ваша будет увлекательна, конечно. Но вы проиграете.
ДФ>Похоже, я что-то не уловил в терминологии. По моему опыту (специфическому), зачастую заказчик (внешний или внутренний — не важно), заказывая "автоматизацию" или "новую систему управления корпоративным порталом" предполагает решение вполне конкретных целей (улучшение управляемости, увеличение потока пользователей, снижения складских запасов и т.п.). ДФ>И первая стадия проекта, по идее, должна быть "исследовательской" — на ней нужно понять, как именно заказчик может выполнить свои цели и какие технические средства ему могут помочь.
Ну да.
ДФ>Логично в этом случае, как и рекомендуют ГОСТы, сделать сначала НИР, результатом которого будет ТЗ ДФ>(правда, не понятно, кто будет этот результат принимать — специалистов такого класса у заказчика скорее всего нет). ДФ>Но это, в общем, идеальный случай разумных отношений с заказчиком.
Заказчик, разумеется, такой НИР (который, в общем, на самом деле не НИР — это простое обследование) не оплатит. По крайней мере, сразу. Однако это не повод не заслать к нему аналитиков — вы потом затраты на обследование можете включить в общий счет работ первого этапа.
ДФ>Но, опять-таки, часто встречаются случаи, когда один менеджер продал другому "систему автоматизации, которая решит все ваши проблемы", а даже цели автоматизации в договоре не прописаны — вот тут и начинается вполне обычное веселье — как впихнуть и исследование и собственно разработку в один проект. При этом, по традиции, сроки сжатые.
В этом случае тем более надо проводить обследование за свой счет. Чтобы понять, какой фронт работ предстоит.
ДФ>Вот в этом случае мне представляется разумным начинать с итеративной разработке прототипов (как в НИР и предполагается), держа в голове перерастание этих прототипов в промышленную систему. И в качестве "процесса" для такой разработке подходят некоторые идеи agile (малые команды, тесная коммуникация с заказчиком, ранняя интеграция, постоянное тестирование, приоритезирование и т.п.).
Объясните мне, с каким "заказчиком" вы собираетесь коммуницировать с случае корпоративной ИС где 15 ролей пользователей, и менеджмент не знает деталей и нюансов работы исполнителей? А директор вообще не имеет представления о деталях фактических бизнес-процессов (ему по должности не положено в такие детали вникать)?
Суть обследования, которое надо провести перед началом разработки (если конечно переделывать ничего не хочется, что видимо и есть источник нескончаемого фана при agile разработке), и состоит в этом "общении" с заказчиком, выявлении фактических ролей, выявление фактического документооборота и бизнес-операций. О которых никто кроме непосредственных исполнителей точной и достоверной информацией не обладает. Не надо с менеджментом общаться для анализа бизнес-процессов — категорически нет. А то будете по двадцать пять раз "спринты" крутить. С исполнителями надо говорить.
В ходе обследования вы собираете заполненные формы всех документов, и беседуете с двумя исполнителями для каждой роли. С каждым их них — по часу, максимум два. Это необходимо для того, чтобы костяк системы выстроить, по которой вы любой наперед заданный отчет менеджменту сделаете.
ДФ>Но, конечно, с проектированием (предварительным) и управлением требованиями (по мере их появления и если вообще это удается делать — я провалил (или вытянул очень большими усилиями) не один проект, прежде чем не осознал важность управления требованиями.
Если вы не проводили обследования — то как именно вы требованиями управляли? Собирали то их как?
ДФ>P.S. А что, бывают проекты, в которых выработка ТЗ формально вынесена в отдельный проект, а оценка общего результат происходит по результатам формирования ТЗ? Т.е. в идеале такие есть — но я о них не слышал.
Бывают при гособоронзаказе. Цитирую мануал по составлению ТЗ на военные НИР для изделий электронной техники:
2. Цели и задачи НИР
В разделе приводят задачи, на решение которых направлена НИР, и предполагаемые пути реализации ее результатов (постановка прикладных НИР, ОКР, и т.д.)
...
3. Требования к выполнению НИР
...
В конце раздела указывают, чем должна заканчиваться работа (разработкой рекомендаций и предложений по реализации результатов НИР, проекта ТЗ на ОКР, нормативно-технических документов)
G>>Например, продолжительность и трудозатраты на НИР сложно оценить, нет методик — их надо просто ограничивать по общему времени, сделать акцент на целеполагание, и вести итеративно. А вот разработку по известному функционалу (ОКР) довольно просто оценить и запланировать — так надо этим пользоваться, почему нет?
G>>Отнюдь, почему же то прокол. Просто надо отдавать себе отчет, чем НИР от ОКР отличается и применять разные подходы для них. НИР в рамках госзаказов, разумеется, делается только по fixed cost. И это правильно. НИР который нельзя планировать и который рискован по сравнению с ОКР — может не принести результатов, надо обязательно ограничивать по времени и бюджету — это элементарное управление рисками.
ДФ>А если договор с fixed-price на НИР+ОКР вместе? Т.е. одна общая сумма и на то, и на другое. Или есть методики, которые позволяют корректно разделить общие затраты на стадии и определить, когда нужно прекращать НИР?
Следуйте циклу РУП. Он гласит, что стадии у вас как минимум четыре.
1. Завершается, когда вы на 90% имеете общее представление (во всей команде и вместе с заказчиком) о том, что надо делать. Я так понял — это и есть цель вашей НИР?
2. Завершается, когда вы на 90% имеете общее представление о том, как это надо делать. Это уже при знакомых технологиях и инструментах — обыкновенно хардкорный ОКР.
3. Завершается, когда вы даете первую полнофункицональную версию для тестирования. Тут никаким НИР уже давно не пахнет тем более.
4. Завершается, когда вы даете рабочую версию.
На первую фазу выделите для начала некоторое разумное время, скажем, неделя. В конце недели подведите итоги, и решите, вы вышли из фазы, или нет. Если нет — поставьте себе конкретные цели на следующую неделю, и повторяйте. Заранее ограничьте deadline, к которому вы должны уложиться с первой фазой, чтобы хоть как-то уложиться в общие сроки. Поставьте себе цель номер 1 — первым делом очертить хотя бы scope работ, чтобы как можно быстрее оценить масштаб работы.
G>>Я понимаю, что инженерам хочется думать о своей работе как о чем-то высоком, но "чисто НИРовских" задач в бизнесе практически не бывает — их мало. ДФ>Задача исследовательская не с технической точки зрения (там как раз все обычно очевидно), а с точки зрения удовлетворения потребностей новым способом.
Понятно.
G>>Описывая всю разработку в терминах agile вы по сути обманываете менеджмент. Вы стираете границу между НИР и ОКР, убиваете на крупном уровне управление рисками, и подводите свою организацию под значительные риски.
ДФ>Угу. Я по сути вкладываю консалтинг, сбор требований, выработку ТЗ внутрь проекта. Раз уж не удалось сделать их вне проектных условий.
Это вполне нормально на мой взгляд. Сами так делали.
G>>Симптом отсутствия управления требованиями . Внутренний заказчик не является специалистом ни в сборе и формулировке требований, ни в их анализе. Вы же предполагаете, что полные и непротиворечивые требования должны появиться как-то сами собой. Естественно, этого не происходит.
ДФ>Ну, на получение разумных требований от заказчика я уже давно не рассчитываю. Но что при описании предметной области специалист может ошибиться трижды (увы, проверить по другим источникам это было невозможно, очень узкая специализация) — этого я не предполагал. Но управления требованиями — да, не было. Впрочем, в таких задачах оно бы и не помогло.
Есть книга такая — SADT называется. Так вот, там кроме самой нотации SADT(IDEF0) описывается в деталях, как должен вести себя аналитик на интервью, чтобы заказчику было непросто всякий балшыт на уши аналитику вешать. Очень рекомендую, мне в свое время эта книга сильно помогла.
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Собственно, минимизация издержек -- и есть самая суть agile, при определенной трактовке, разделяемой не всеми. (При этой трактовке) в этом они очень родственны с lean product development / lean manufacturing, родившимися из TPS (Toyota Production System).
Это декларируемые цели. Так сказать кто угодно может. Каким образом они доказывают, что они на самом деле минимизируют издержки? Это совершенно не очевидно. Скажем, из описания PSP/TSP совершенно очевидно, каким образом производится оптимизация процесса разработки для минимизации издержек, и за счет чего. Сам процесс позволяет объективным образом измерять собственную эффективность, да и посылки там понятны. Сама суть PSP/TSP — оптимизация процесса разработки, даже не сам процесс.
А в случае agile — почему издержки минимизируются? С какой стати мне нужно верить каким-то дядькам на слово, что если я не напишу дизайн-документ, то у меня разработка пойдет быстрее, если я видел на практике кучу контрпримеров? Если я своими глазами видел факты, доказывающие обратное — например, статистики по цене исправления дефектов, и корелляции стоимости исправления дефектов со временем между их внесением и обнаружением и фазой внесения?
Здравствуйте, Gaperton, Вы писали:
G>Заказчик, разумеется, такой НИР (который, в общем, на самом деле не НИР — это простое обследование) не оплатит. По крайней мере, сразу. Однако это не повод не заслать к нему аналитиков — вы потом затраты на обследование можете включить в общий счет работ первого этапа.
Э, про обследование существующих бизнес-процессов я тут не говорю, это само собой разумеется (хотя и не всегда удавалось их провести — но я тогда был маленький и неопытный, не умел заставить показать пользователей системы).
У меня значительная часть проектов была связана с тем, что существующие процессы не устраивают заказчика, и вместе с автоматизацией меняются и алгоритмы работы. Т.е. нужно автоматизировать не то, что есть, а то, что должно быть.
И собственно НИР — это построение картинки того, что должно быть. Включая, возможно, всякие навороты.
Ну,например, у заказчика высокие остатки на складах, долгая доставка, много затрат человекочасов на планирование логистики и низкое качество планирования.
Требуется (т.е. уже продано) решение, которое за счет некого алгоритма планирования решит указанные проблемы (т.е. автоматическое построение планов отгрузки, например, на основании информации из астрала). Алгоритмов готовых у заказчика нет, есть общие идеи, применимость которых нужно проверять.
Но проект — fixed-price.
Вот в этом случае, на мой взгляд, постоянное общение с заказчиком (с реальными будущими пользователями), регулярные билды, которые смотрят те же пользователи с реальными данными — необходимы.
ДФ>>Вот в этом случае мне представляется разумным начинать с итеративной разработке прототипов (как в НИР и предполагается), держа в голове перерастание этих прототипов в промышленную систему. И в качестве "процесса" для такой разработке подходят некоторые идеи agile (малые команды, тесная коммуникация с заказчиком, ранняя интеграция, постоянное тестирование, приоритезирование и т.п.).
G>Объясните мне, с каким "заказчиком" вы собираетесь коммуницировать с случае корпоративной ИС где 15 ролей пользователей, и менеджмент не знает деталей и нюансов работы исполнителей? А директор вообще не имеет представления о деталях фактических бизнес-процессов (ему по должности не положено в такие детали вникать)?
Есть два варианта. Или с "ответственным за проект" с той стороны — а уж он достанет нужных людей с нужных уровней.
Или со всеми 15ью ролями пользователей. В первый вариант я верю значительно меньше.
G>Суть обследования, которое надо провести перед началом разработки (если конечно переделывать ничего не хочется, что видимо и есть источник нескончаемого фана при agile разработке), и состоит в этом "общении" с заказчиком, выявлении фактических ролей, выявление фактического документооборота и бизнес-операций. О которых никто кроме непосредственных исполнителей точной и достоверной информацией не обладает. Не надо с менеджментом общаться для анализа бизнес-процессов — категорически нет. А то будете по двадцать пять раз "спринты" крутить. С исполнителями надо говорить.
Да кто бы спорил. Но этого достаточно, только если нужно автоматизировать имеющиеся бизнес-процессы. А если создаются новые процессы (и новые роли, и новые ответственности и т.п.) — то один раз поговорить при сборе требований — мало, нужно это делать регулярно, по мере развития проекта.
G>В ходе обследования вы собираете заполненные формы всех документов, и беседуете с двумя исполнителями для каждой роли. С каждым их них — по часу, максимум два. Это необходимо для того, чтобы костяк системы выстроить, по которой вы любой наперед заданный отчет менеджменту сделаете.
Ну, далеко не у каждой роли есть хотя бы по два исполнителя. Впрочем, в таких случаях я пытался поговорить про роль и с исполнителем и с его контрагентами/менеджером/подчиненными — для полноты картины.
Формы документов (с комментариями) — тоже разумеется. Хотя этого тоже мало, Excel формы, бывают, переделывают по два раза в месяц, нужно актуальные данные постоянно дособирать.
ДФ>>Но, конечно, с проектированием (предварительным) и управлением требованиями (по мере их появления и если вообще это удается делать — я провалил (или вытянул очень большими усилиями) не один проект, прежде чем не осознал важность управления требованиями.
G>Если вы не проводили обследования — то как именно вы требованиями управляли? Собирали то их как?
Проводил, конечно. И все формы были. 2х часов на роль, конечно, мало, в сумме где-то часов по 8 уходило, не считая последующих уточняющих вопросов.
Иногда — и гораздо больше.
ДФ>>P.S. А что, бывают проекты, в которых выработка ТЗ формально вынесена в отдельный проект, а оценка общего результат происходит по результатам формирования ТЗ? Т.е. в идеале такие есть — но я о них не слышал. G>Бывают при гособоронзаказе. Цитирую мануал по составлению ТЗ на военные НИР для изделий электронной техники:
Бывают, да. Хотя когда пришлось участвовать в одном из проектов ГАС "Выборы" (он, насколько я помню, делался по военным нормам), ТЗ писался одновременно с приемкой.
ДФ>>А если договор с fixed-price на НИР+ОКР вместе? Т.е. одна общая сумма и на то, и на другое. Или есть методики, которые позволяют корректно разделить общие затраты на стадии и определить, когда нужно прекращать НИР?
G>Следуйте циклу РУП. Он гласит, что стадии у вас как минимум четыре. G>1. Завершается, когда вы на 90% имеете общее представление (во всей команде и вместе с заказчиком) о том, что надо делать. Я так понял — это и есть цель вашей НИР? G>На первую фазу выделите для начала некоторое разумное время, скажем, неделя.
За это время можно только предметную область обрисовать (да и то далеко не всякую). Если ставить целью НИР постановку на 90% (причем только концептуальную, без пользовательских интерфейсов, без данных, только роли, сущности, существенные алгоритмы) и при постоянном контакте со всеми заинтересованными ролями — то для нормального проекта на 10 человеколет нужно не меньше месяца. Если повезет.
Обычно, впрочем, не везет и на часть вопросов по алгоритмам или нужным процессам следует ответ "сделайте, там посмотрим, подходит или нет".
Т.е. нужно делать прототип, причем, увы, заказчики очень плохо (как выяснилось) умеют понимать такую вещь как неполнофункциональный прототип. И заставить их оценить эффективность алгоритма или решения без всех рюшечек иногда просто нельзя.
Вот эта стадия и выливается в первую, вторую и третью одновременно.
G>4. Завершается, когда вы даете рабочую версию.
А вот от предыдущей до этой может пройти несколько подходов, иногда (если не постараться) с изрядным рефакторингом.
А уже если заказчик требует конкретных интерфейсных решений (которые, опять таки, на стадии 1 всяко не получить) — то и больше.
G>Есть книга такая — SADT называется. Так вот, там кроме самой нотации SADT(IDEF0) описывается в деталях, как должен вести себя аналитик на интервью, чтобы заказчику было непросто всякий балшыт на уши аналитику вешать. Очень рекомендую, мне в свое время эта книга сильно помогла.
Спасибо, почитаю. Но тут даже не вешанье на уши, просто специалист за полгода очень сильно поменял свое профессиональное мнение о некоторых вещах.
При том, что встречи с заказчиком (нижним уровнем реальных пользователей) проходили раз в месяц сессиями по два дня (заказчик в другой стране, чаще никак), с четкой фиксацией всех результатов, согласованием правильности понимания, отслеживанием взаимовлияния появлявшихся требований и т.п.
Но если бы мы сразу делали процесс более итеративным — этих проблем было бы меньше.
Если сформулировать мою позицию:
чем точнее заказчик знает, что он хочет — тем более длинные итерации может себе позволить исполнитель. Но каждая итерация, конечно, включает в себя все 4 стадии.
то, что называют agile технологиями — методики, позволяющие довести размер стадии до двух недель-месяца. Они нужны в тех случаях, когда заказчик почти совсем не представляет, что же он хочет получить.
. Внутренний заказчик не является специалистом ни в сборе и формулировке требований, ни в их анализе. Вы же предполагаете, что полные и непротиворечивые требования должны появиться как-то сами собой. Естественно, этого не происходит.