Доброго дня!

Хочется услышать кто и какой материал использует для постановки задачи программисту?
Проанализировав кучу материала я так и не нашел готового шаблона (документа), грамотного составленного с четким и понятным изложением, описывающим как нужно запрограммировать ту или иную задачу, функцию и т.п.

В своей практике постоянно сталкивался с документами ГОСТ:
1) "Описание алгоритма" (который в данный момент и используется как постановка) и
2) "Описание постановки задачи (комплекса задач)".

В ходе общения с прогерами и аналитиками пришел к мнению, что не очень практичны, долго пишутся, не так трактуются, содержат ненужную информацию или не содержат того чего нужно.

Итог: данные документы разрабатываются на этапе ТехПроекта для "ДАЛЬНЕЙШЕЙ ИХ СДАЧИ ЗАКАЗЧИКУ" (чтобы закрыть этап). Отсюда второй итог: эти документы носят по большому счету формальный характер и в дальнейшем абсолютно не применимы.


Многие с кем общался перечисляют общие документы, разрабатываемые по разным методикам: ТЗ, Техпроект, ЮзКейзМодель, ДатаМодель, SRS, Design Specification и т.д. и т.п.
Не спорю, все они нужны и все они обязательны в какой-то мере, но разработчик говорит "Дай мне постановку на разработку, что и как нужно делать" желая видеть некий ЕДИНЫЙ документ, в котором формализована задача, требующая реализации в коде.


Вопрос коллегам: Кто и что использовал в своей практике, чтобы поставить задачу программисту? Есть ли у вас готовый шаблон, документ или что-то типа того?


Пример: Необходимо поставить задачу на разработку экранной формы. Помимо самого снимка экранной формы, требуется расписывать назначения каждого элемента формы и используемые при этом процедуры, классы для отображения, хранения и проверки данных. Помимо этого где-то здесь же нужно описать последовательность действий пользователя этой формы, что будет происходить с ней при каждом действии... здесь же желательны представить последовательность потоков данных (возможно "Диаграмма последовательности", кстати она очень понравилась разработчикам)...

Фух...

Понятна ли проблема? Готов услышать ваши ответы.

Спасибо.

Пример: Необходимо поставить задачу на разработку экранной формы. Помимо самого снимка экранной формы, требуется расписывать назначения каждого элемента формы и используемые при этом процедуры, классы для отображения, хранения и проверки данных. Помимо этого где-то здесь же нужно описать последовательность действий пользователя этой формы, что будет происходить с ней при каждом действии... здесь же желательны представить последовательность потоков данных (возможно "Диаграмма последовательности", кстати она очень понравилась разработчикам)...

А почему нельзя дать разработчику нарисованный макет этой формы и рассказать словами назначение каждого элемента? И на этом же макете в процессе обсуждения пометить, какие проверки обязательно нужно выполнять при вводе данных.

Назначение элемента и выполняемые проверки - это, собственно, требования. А процедуры и классы - это уже вотчина разработчика, разве не так?

Подойти и дать ему скриншот, рассказав на словах ?

Ну вот что мы поимели, когда вся команда разработчиков и аналитиков уволилась с проекта.
Проект был передан новому ПиЭму, которму а) нужно самому вникнуть в суть системы б) довести до проектной команды то, с чем они имеют дело. Ничего не было задокументировано, все делалось до этого именно так, как вы и говорите "показал, рассказал, закодил, уволился".

Новому разрабу нужно поставить постановку на доработку старой экранной формы. Чтобы понять, как она работает куда идем? Лезем в код? Считаю это не правильным. Незадокументировано, значит не сделано!

...
Пример:[/b] Необходимо поставить задачу на разработку экранной формы. Помимо самого снимка экранной формы, требуется расписывать назначения каждого элемента формы и используемые при этом процедуры, классы для отображения, хранения и проверки данных. Помимо этого где-то здесь же нужно описать последовательность действий пользователя этой формы, что будет происходить с ней при каждом действии... здесь же желательны представить последовательность потоков данных (возможно "Диаграмма последовательности", кстати она очень понравилась разработчикам)...

Ну так надо было продвинутому разработчику (архитектору) нарисовать модель на UML, да и отдать ее программистам.

Ну так надо было продвинутому разработчику (архитектору) нарисовать модель на UML, да и отдать ее программистам.

Денис, а кто и как объяснит самому архитектору как это должно выглядеть и работать? Или это такой крутой архитектор, который сам разберется? Думаю ошибаетесь.
Начинается все, как мне кажется,  с бизнес аналитика. Он должен сначала расписать свое видение в каком то виде. (простите за тавтологию), донести до архитектора, а там они уже наверное как то совместными усилиями должны действовать.
Я лично интерфейсы когда-то пытался разрисовывать в MS Visio. Но это очень неудобно и долго.
Мне понравился инструмент GUI Design Studio - быстро накидал, что хочешь видеть в программе и сделал документ Word с описанием и скришотами. Это по крайней мере можно задокументировать и если что - через год два по этому документу легко вспомнить о чем шла речь.

Господа!

А если без привязки к постановке на экранную форму?
Бывают разные виды постановок - форма, отчет, функция, задача и т.п.
Я привел пример для формы, потому как с ней понятно, что должно быть:
1. Графическое представление
2. Используемые массивы данных (объекты таблицы БД)
3. Выходная информация
4. Алгоритм использования (заполнения и работы с ней)
что-то еще....

Ту же модель на UML где писать, какую именно модель? Нужно ли к ней текстовое описание? В какой форме?
Где это все перечислять?

Существует ли некая общая форма или каждый "свободный и вольный писатель"?

Подойти и дать ему скриншот, рассказав на словах ?

Ну вот что мы поимели, когда вся команда разработчиков и аналитиков уволилась с проекта.

Не скриншот, а нарисовать от руки. А оставшееся время посвятить тому, чтобы разработчики и аналитики не уходили с проектов целыми командами. Была ведь какая-то причина для их массового ухода?

Проект был передан новому ПиЭму, которму а) нужно самому вникнуть в суть системы б) довести до проектной команды то, с чем они имеют дело. Ничего не было задокументировано, все делалось до этого именно так, как вы и говорите "показал, рассказал, закодил, уволился".

Новому разрабу нужно поставить постановку на доработку старой экранной формы. Чтобы понять, как она работает куда идем? Лезем в код? Считаю это не правильным. Незадокументировано, значит не сделано!

Да, я тоже пытался руководствоваться таким принципом: что не задокументировано, того не существует. Но это очень дорого, а главное, скучно - всё документировать. Хотя вики-системы, возможность легко сохранять изображения, аудио и видеозаписи теперь здорово помогают: не нужно всё переводить в какой-то формальный вид.

В варианте, который я предложил, эскиз формы с пометками можно отсканировать, картинку положить в вики, а изменения отражать в комментариях. Если нет вики, положите в ту систему, которая есть и реально используется. Если есть какая-то система управления требованиями - просто прекрасно, если её нет - положите хотя бы в репозиторий системы контроля версий (ну а если контроля версий нет, то об управлении требованиями заботиться вообще бессмысленно).

И хороший код, кстати, тоже неплохой документ. Хотя, конечно, не стоит использовать его как главное средство извлечения требований.

Вообще, как я понимаю, вам нужно найти баланс между "всё записывать" и "всё показывать на пальцах". У каждой команды и в каждом проекте этот баланс свой.

Если до сих пор всё было на уровне "показал, рассказал, закодил", то определите сначала критический уровень, с которого нужно начинать документировать постановки задач. С чего именно начинать - зависит от системы, этого никто лучше вас знать не может. Это может быть самая важная часть системы, или та часть, в которой возникает больше всего ошибок - алгоритмы, компоненты, формы, интерфейсы - у каждого своё.

Мы, например, во всех проектах детально и подробно документируем внешние интерфейсы: протоколы обмена данными, состав и структура параметров и т. п. А экранные и печатные формы согласовываем с клиентами именно так, как я сказал: листочек с пометками.

А если без привязки к постановке на экранную форму?
Бывают разные виды постановок - форма, отчет, функция, задача и т.п.
Я привел пример для формы, потому как с ней понятно, что должно быть:
1. Графическое представление
2. Используемые массивы данных (объекты таблицы БД)
3. Выходная информация
4. Алгоритм использования (заполнения и работы с ней)
что-то еще....

Ту же модель на UML где писать, какую именно модель? Нужно ли к ней текстовое описание? В какой форме?
Где это все перечислять?

Существует ли некая общая форма или каждый "свободный и вольный писатель"?

Думаю, что типового решения тут не существует. Каждый (организация разработчик) делает  так, как сложилось в процессе многолетней работы. И думаю, что особо на этом не стоит заморачиваться. Просто соберитесь своей командой -аналитики, архитекторы, программисты и придите к какому то единому мнению. Как должен выглядеть документ, чтобы всем было хорошо.
Главным считаю то, что эти документы должны попадать в некий архив, к которому можно будет в любой момент обратиться и найти этот документ.

Забыл сказать - еще мы приняли за основу обсуждать проблему рисуя на доске, затем фотаем доску и тоже отправляем в хранилище вместе с остальными документами. Иногда бывает просто взглянешь на доску в процессе обсуждения - и сразу обновляется в памяти разговор минувших дней. Ну это я так.... отвлекся немного.

Думаю, что типового решения тут не существует.

Жаль Очень жаль

Жаль Очень жаль

Почему жаль? Вы попробуйте идти не от формы, а от содержания.

Жаль Очень жаль

Нет типовых проблем, потому нет типовых решений. исходите из того, что вам нужно:
1. Опишите сценарий использования, если это новая функциональность.
2. Нарисуйте экранную форму, если это новая форма или изменение старой.
3. Опишите поля на экранной форме. Если надо, со ссылка на БД.
4. Если надо прописать технические моменты - опишите.

Не надо бояться делать не так как "положено" - если это постоянный процесс, то вы постепенно выработаете свой оптимальный подход к нему.

Касательно шаблонов документов, то как раз только что искал какой-нибудь вменяемый шаблон для запроса на изменение, но как-то туго с этим. Самое приличное оказалось вот это - http://www.sapnet.ru/weblog_entry.php?e=11.

Опять же, шаблон может и должен изменяться под свои потребности.

Не спорю, все они нужны и все они обязательны в какой-то мере, но разработчик говорит "Дай мне постановку на разработку, что и как нужно делать" желая видеть некий ЕДИНЫЙ документ, в котором формализована задача, требующая реализации в коде.

Вопрос коллегам: Кто и что использовал в своей практике, чтобы поставить задачу программисту?

Сравните варианты:
1. Программист разрабатывает процедуры миграции данных в DWH-системе.
2. Программист разрабатывает интерфейс высокоинтерактивной игры.
3. Программист разрабатывает модуль управления лифтом.

Понятно, что структура постановки задачи для всех случаев будет отличаться.

Кроме того, не надо путать:
1. Постановку задачи конкретному исполнителю по созданию какого-то элемента продукта («Вася, забей вон ту сваю на 2 метра») и
2. Постановку задачи на проектирование/реализацию, фиксацию проектных решений по продукту («Фундамент здания должен быть выполнен на сваях ГОСТ 21321-69»).

Ну вот что мы поимели, когда вся команда разработчиков и аналитиков уволилась с проекта.
Проект был передан новому ПиЭму, которму …

А при чём тут постановка задачи программисту?

А при чём тут постановка задачи программисту?

как при чем... при том....   известная проблема.
Речь идет о документировании заданий, которые выдаются программистам.
Во-первых, в том случае, когда кто то из команды выбывает, вновь прибывший человек легко сможет войти в курс дела. 
А во-вторых, если напишешь постановку задаче на листочке- этот листочек через неделю 100% потеряется и уже диалога между аналитиком и программистом скорее всего не получится. Программист скажет, а я сделал так, как ты говорил. Поди разберись кто прав, кто виноват.