Форум Сообщества Аналитиков
Дисциплины => Проектирование => Тема начата: Pavel_T от 09 Июня 2010, 13:00:05
-
Доброго дня!
Хочется услышать кто и какой материал использует для постановки задачи программисту?
Проанализировав кучу материала я так и не нашел готового шаблона (документа), грамотного составленного с четким и понятным изложением, описывающим как нужно запрограммировать ту или иную задачу, функцию и т.п.
В своей практике постоянно сталкивался с документами ГОСТ:
1) "Описание алгоритма" (который в данный момент и используется как постановка) и
2) "Описание постановки задачи (комплекса задач)".
В ходе общения с прогерами и аналитиками пришел к мнению, что не очень практичны, долго пишутся, не так трактуются, содержат ненужную информацию или не содержат того чего нужно.
Итог: данные документы разрабатываются на этапе ТехПроекта для "ДАЛЬНЕЙШЕЙ ИХ СДАЧИ ЗАКАЗЧИКУ" (чтобы закрыть этап). Отсюда второй итог: эти документы носят по большому счету формальный характер и в дальнейшем абсолютно не применимы.
Многие с кем общался перечисляют общие документы, разрабатываемые по разным методикам: ТЗ, Техпроект, ЮзКейзМодель, ДатаМодель, SRS, Design Specification и т.д. и т.п.
Не спорю, все они нужны и все они обязательны в какой-то мере, но разработчик говорит "Дай мне постановку на разработку, что и как нужно делать" желая видеть некий ЕДИНЫЙ документ, в котором формализована задача, требующая реализации в коде.
Вопрос коллегам: Кто и что использовал в своей практике, чтобы поставить задачу программисту? Есть ли у вас готовый шаблон, документ или что-то типа того?
Пример: Необходимо поставить задачу на разработку экранной формы. Помимо самого снимка экранной формы, требуется расписывать назначения каждого элемента формы и используемые при этом процедуры, классы для отображения, хранения и проверки данных. Помимо этого где-то здесь же нужно описать последовательность действий пользователя этой формы, что будет происходить с ней при каждом действии... здесь же желательны представить последовательность потоков данных (возможно "Диаграмма последовательности", кстати она очень понравилась разработчикам)...
Фух... :(
Понятна ли проблема? Готов услышать ваши ответы.
Спасибо.
-
Пример: Необходимо поставить задачу на разработку экранной формы. Помимо самого снимка экранной формы, требуется расписывать назначения каждого элемента формы и используемые при этом процедуры, классы для отображения, хранения и проверки данных. Помимо этого где-то здесь же нужно описать последовательность действий пользователя этой формы, что будет происходить с ней при каждом действии... здесь же желательны представить последовательность потоков данных (возможно "Диаграмма последовательности", кстати она очень понравилась разработчикам)...
А почему нельзя дать разработчику нарисованный макет этой формы и рассказать словами назначение каждого элемента? И на этом же макете в процессе обсуждения пометить, какие проверки обязательно нужно выполнять при вводе данных.
Назначение элемента и выполняемые проверки - это, собственно, требования. А процедуры и классы - это уже вотчина разработчика, разве не так?
-
Подойти и дать ему скриншот, рассказав на словах ?
Ну вот что мы поимели, когда вся команда разработчиков и аналитиков уволилась с проекта.
Проект был передан новому ПиЭму, которму а) нужно самому вникнуть в суть системы б) довести до проектной команды то, с чем они имеют дело. Ничего не было задокументировано, все делалось до этого именно так, как вы и говорите "показал, рассказал, закодил, уволился".
Новому разрабу нужно поставить постановку на доработку старой экранной формы. Чтобы понять, как она работает куда идем? Лезем в код? Считаю это не правильным. Незадокументировано, значит не сделано!
-
...
Пример:[/b] Необходимо поставить задачу на разработку экранной формы. Помимо самого снимка экранной формы, требуется расписывать назначения каждого элемента формы и используемые при этом процедуры, классы для отображения, хранения и проверки данных. Помимо этого где-то здесь же нужно описать последовательность действий пользователя этой формы, что будет происходить с ней при каждом действии... здесь же желательны представить последовательность потоков данных (возможно "Диаграмма последовательности", кстати она очень понравилась разработчикам)...
Ну так надо было продвинутому разработчику (архитектору) нарисовать модель на UML, да и отдать ее программистам.
-
Ну так надо было продвинутому разработчику (архитектору) нарисовать модель на UML, да и отдать ее программистам.
Денис, а кто и как объяснит самому архитектору как это должно выглядеть и работать? :D Или это такой крутой архитектор, который сам разберется? Думаю ошибаетесь.
Начинается все, как мне кажется, с бизнес аналитика. Он должен сначала расписать свое видение в каком то виде. (простите за тавтологию), донести до архитектора, а там они уже наверное как то совместными усилиями должны действовать.
Я лично интерфейсы когда-то пытался разрисовывать в 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% потеряется и уже диалога между аналитиком и программистом скорее всего не получится. Программист скажет, а я сделал так, как ты говорил. Поди разберись кто прав, кто виноват.
-
как при чем... при том.... :) известная проблема.
Речь идет о документировании заданий, которые выдаются программистам.
Во-первых, в том случае, когда кто то из команды выбывает, вновь прибывший человек легко сможет войти в курс дела.
А во-вторых, если напишешь постановку задаче на листочке- этот листочек через неделю 100% потеряется и уже диалога между аналитиком и программистом скорее всего не получится. Программист скажет, а я сделал так, как ты говорил. Поди разберись кто прав, кто виноват.
Спасибо. Именно так! :(
-
Сравните варианты:
1. Программист разрабатывает процедуры миграции данных в DWH-системе.
2. Программист разрабатывает интерфейс высокоинтерактивной игры.
3. Программист разрабатывает модуль управления лифтом.
Понятно, что структура постановки задачи для всех случаев будет отличаться.
Кроме того, не надо путать:
1. Постановку задачи конкретному исполнителю по созданию какого-то элемента продукта («Вася, забей вон ту сваю на 2 метра») и
2. Постановку задачи на проектирование/реализацию, фиксацию проектных решений по продукту («Фундамент здания должен быть выполнен на сваях ГОСТ 21321-69»).
Простите, не понял Вас :(
-
Проблема — это разница между существующим и желаемым с точки зрения конкретного агента.
В первоначальном посте ярко выраженной разницы не показано.
Можно лишь было догадываться, что проблема либо в:
1. Аналитик: У меня нет шаблона для постановки задачи, хочу шаблон (Чтобы не забывать важные вещи? Чтобы каждый раз было одинаково? Непонятно).
2. Программист: Сейчас задачи ставятся по-разному. Хочу, чтобы задачи ставились единообразно (Чтобы было проще принимать задачу в работу?).
В ходе дискуссии выясняется следующая проблема:
3. ПМ: Хочу, чтобы в случае замены специалиста эта замена обходилась по времени дешевле, чем сейчас.
1 и 2 действительно могут относиться к проработке и унификации ФОРМАТА постановки задачи и решаются шаблонизацией.
3 скорее всего действительно относится к СРЕДЕ ХРАНЕНИЯ и РАСПРОСТРАНЕНИЯ постановок задач и решается выбором инструмента (например, таск-трекера) и методикой работы с ним.
-
Проблема — это разница между существующим и желаемым с точки зрения конкретного агента.
В первоначальном посте ярко выраженной разницы не показано.
Можно лишь было догадываться, что проблема либо в:
1. Аналитик: У меня нет шаблона для постановки задачи, хочу шаблон (Чтобы не забывать важные вещи? Чтобы каждый раз было одинаково? Непонятно).
2. Программист: Сейчас задачи ставятся по-разному. Хочу, чтобы задачи ставились единообразно (Чтобы было проще принимать задачу в работу?).
В ходе дискуссии выясняется следующая проблема:
3. ПМ: Хочу, чтобы в случае замены специалиста эта замена обходилась по времени дешевле, чем сейчас.
1 и 2 действительно могут относиться к проработке и унификации ФОРМАТА постановки задачи и решаются шаблонизацией.
3 скорее всего действительно относится к СРЕДЕ ХРАНЕНИЯ и РАСПРОСТРАНЕНИЯ постановок задач и решается выбором инструмента (например, таск-трекера) и методикой работы с ним.
Сложно не согласиться. Так и есть ) Это вы типа подвели итог и тему можно закрывать? :)
-
3 скорее всего действительно относится к СРЕДЕ ХРАНЕНИЯ и РАСПРОСТРАНЕНИЯ постановок задач и решается выбором инструмента (например, таск-трекера) и методикой работы с ним.
Никогда ни с чем подобным дел не имел :(
Посоветуйте пожалуйста продукт (один) желательно бесплатный... чтобы можно было попробовать, показать, рассказать и работать.
-
Никогда ни с чем подобным дел не имел :(
Посоветуйте пожалуйста продукт (один) желательно бесплатный... чтобы можно было попробовать, показать, рассказать и работать.
советую: Redmine. Здесь можете взять готовый инсталятор http://bitnami.org/stack/redmine . Установка на 1-2-3 и через 20 минут у вас уже готовый сервер в связке с wiki, subversion и остальными прибамбасами.
-
советую: Redmine. Здесь можете взять готовый инсталятор http://bitnami.org/stack/redmine . Установка на 1-2-3 и через 20 минут у вас уже готовый сервер в связке с wiki, subversion и остальными прибамбасами.
А где бы посмотреть вводный видеокурс? Ну или скриншоты, как с этим работать...
-
А где бы посмотреть вводный видеокурс? Ну или скриншоты, как с этим работать...
молодой человек ну если честно, то это уже наглостью называется. Гугл вам поможет- он всем помогает ;). На сайте разработчика Redmine кое что посмотреть можно, но лучше установить и потыкать кнопки самому. Там все очень просто. Даже на русском языке.
-
молодой человек ну если честно, то это уже наглостью называется. Гугл вам поможет- он всем помогает ;). На сайте разработчика Redmine кое что посмотреть можно, но лучше установить и потыкать кнопки самому. Там все очень просто. Даже на русском языке.
Не наглею :( Предварительно порылся в гугле, с первого захода ничего толком не нашел (кое-что на сайте)
Спасибо! Буду разбираться...
PS. Я так понял что Вы ей пользуетеся? Можете показать скриншот задачи на постановку разработчику? Как оно выглядит в этой системе? Наглость конечно, с моей стороны, но очень хочется... естественно, если не секретный проект. :)
-
Можете показать скриншот задачи на постановку разработчику? Как оно выглядит в этой системе?
http://www.redmine.org/projects/redmine/issues вот тут точно никаких секретов нет.
-
Пример: Необходимо поставить задачу на разработку экранной формы. Помимо самого снимка экранной формы, требуется расписывать назначения каждого элемента формы и используемые при этом процедуры, классы для отображения, хранения и проверки данных. Помимо этого где-то здесь же нужно описать последовательность действий пользователя этой формы, что будет происходить с ней при каждом действии... здесь же желательны представить последовательность потоков данных (возможно "Диаграмма последовательности"
Это называется обратное проектирование.
Постановка задачи - это другое. Задача ставится для того, чтобы разработчик реализовал алгоритмы, которые потом будут оформлены необходимым пользовательским интерфейсом.
-
Это называется обратное проектирование.
Постановка задачи - это другое. Задача ставится для того, чтобы разработчик реализовал алгоритмы, которые потом будут оформлены необходимым пользовательским интерфейсом.
"Обратное проектирование" - это неправильно? Или это просто - подход, метод?
И... кто далее ставит задачу на пользовательский интерфейс?
-
Самое интересное заключается в том, что не вполне понятно что именно понимается под "постановкой задачи". Интерпретировать это термин можно как угодно, в зависимости от контекста. Кроме этого - создать документ, описывающий детально что должен сделать разработчик - довольно трудоемкая задача. Да и второй вопрос напрашивается - в организации работают кодеры, которым действительно нужно четко и детально все расписать, либо таки разработчики - т.е. более квалифицированные специалисты, которые могут решать частично формализованные задачи?
Как вариант можно попробовать работать с user stories - техника из Agile методологий. Возможно используя их вы сможете в какой-то степени решить проблему отсутствия документации.
-
Как вариант можно попробовать работать с user stories - техника из Agile методологий. Возможно используя их вы сможете в какой-то степени решить проблему отсутствия документации.
Солидарен с вами. Юзер стори полезная составляющая.
-
Самое интересное заключается в том, что не вполне понятно что именно понимается под "постановкой задачи". Интерпретировать это термин можно как угодно, в зависимости от контекста.
Вот сижу и думаю... неужели это я один такой остался, вымирающий мамонт, кто понимает под постановкой задачи конкретно и четко изложенный алгоритм действий для разработчика :(
-
Алгоритм действий для разработчика это должно быть:
Открой редактор кода
Напиши #include <stdio.h>
Напиши void main() {
…
-
Алгоритм действий для разработчика это должно быть:
Денис, написал в личку...
-
Вот сижу и думаю... неужели это я один такой остался, вымирающий мамонт, кто понимает под постановкой задачи конкретно и четко изложенный алгоритм действий для разработчика :(
На мамонта вы не похожи. Скорее на желторотого птенца :)
-
Вот сижу и думаю... неужели это я один такой остался, вымирающий мамонт, кто понимает под постановкой задачи конкретно и четко изложенный алгоритм действий для разработчика :(
Если уже есть чёткий алгоритм действий, то зачем нужен разработчик? :)
-
Если уже есть чёткий алгоритм действий, то зачем нужен разработчик? :)
Ну на это у нас прогеры аргумент такой выдают: "Вы кто, системные аналитики или бизнес? Вот и пишите конкретно что программировать, какие данные в какие поля таблиц складывать"... :(
-
Ну на это у нас прогеры аргумент такой выдают: "Вы кто, системные аналитики или бизнес? Вот и пишите конкретно что программировать, какие данные в какие поля таблиц складывать"... :(
По поводу базы данных считаю что ваши программисты правы - они не должны думать о том как спроектировать базу. Они должны иметь готовое решение откуда взять, с чем сложить и куда положить.
Проектировать базу должен именно аналитик - так только он знает каким образом будут использоваться данные, которые лежат в базе.
-
По поводу базы данных считаю что ваши программисты правы - они не должны думать о том как спроектировать базу. Они должны иметь готовое решение откуда взять, с чем сложить и куда положить.
Проектировать базу должен именно аналитик - так только он знает каким образом будут использоваться данные, которые лежат в базе.
Отсюда подробнее пожалуйста. Как это выглядит в постановке теперь?
-
Проектировать базу должен именно аналитик - так только он знает каким образом будут использоваться данные, которые лежат в базе.
Проектировать БД должен проектировщик, аналитик может представить возможную структуру данных и типы значений. А проектировать БД будет проектировщик.
Более того, это созвучно и с тем, что если известен алгоритм - зачем разработчик.
-
При создании нового сайта особое внимание следует уделять сбору материалов перед этапом проектирования. Как вы думаете, по какому техническому заданию работа будет вестись быстрее: по сухому описанию функционала каждого раздела, либо по такому же описанию, но наполненному конкретными примерами? Когда дизайнеру не нужно придумывать рыбный текст и искать картинки на Яндексе, а можно просто сделать копи-пэйст из ТЗ? Когда верстальщик будет иметь примерное представление об объёмах планируемых к публикации текстов потому что они у него перед глазами? Когда программист, работая над полями в базе данных, будет иметь перед глазами актуальный элемент каталога со всеми его параметрами?
— А вы что, не можете спроектировать сайт без этих материалов? Я же вам сказал, что я хочу на нём видеть, и какие задачи он должен выполнять, — это произносится с неподдельным удивлением на лице. А ещё с лёгким амбре неуверенности в компетенции исполнителя.
— Конечно, можем, — отвечает проектировщик, пожав плечами.
С этого момента время на создание сайта увеличивается в два, два с половиной раза. Причина этому проста. Проектировщик лишь предполагает, какой контент будет ставиться на сайт. Ключевое слово — предполагает.
— Приведите пять примеров товаров из вашего каталога;
— Напишите тестовую новость для вашего будущего сайта;
— Предоставьте, пожалуйста, актуальную контактную информацию вашей компании.
Я выбрал три очень простых и очевидных вещи. Сайт можно спроектировать и без этих материалов. Каждый из трёх вышеперечисленных пунктиков можно заменить кипами вопросов, раскрывающих тему сисек.
— Сколько категорий товаров будет в вашем каталоге?
— Каждый товар будет сопровождаться одним или несколькими изображениями?
— У вас есть своя студия, чтобы сфотографировать шесть тысяч наименований товаров с трёх сторон?
— У различных групп товаров есть повторяющиеся характеристики?
— Как часто вы планируете писать новости?
— Кто будет этим заниматься?
— Будут ли новости с других сайтов с указанием источников?
— Готовы ли вы искать тематические картинки, иллюстрирующие каждую новость?
— Сколько офисов в вашей компании?
— Сколько есть отделов и какие?
— У каждого отдела свой телефон?
— Добавочные номера?
— Кто будет проверять почту?
И так далее, и тому подобное. И хорошо, если заказчик действительно готов выложить круглую сумму на разработку и «всецело положиться на профессионалов». В действительности же в связи с ограниченными бюджетами он старается сэкономить на чём угодно, а «профессионалами» называет вас в таком контексте:
— Вы же профессионалы. Зачем вам нужна вся эта информация для разработки сайта?
И получается, что к моменту сдачи проекта начинаются бесконечные вереницы корректировок, внесений правок, затем исправлений ошибок в связи с внесениями правок. После этого поднимается техническое задание и становится видно, что оно не совпадает с тем, что имеется на выходе. К этому моменту уже давно истрачены все возможные человекочасы. Текст на главной странице слишком громоздкий и то, что на дизайне умещалось без полосы прокрутки, теперь разбросано на три страницы вниз. В разделе с контактной информацией оказался лишь адрес электронной почты, одинокий и несчастный, а в каталоге вместо шести тысяч наименований товаров есть лишь несколько десятков, фильтрация по которым выдаёт нам в среднем по одному результату на страницу.
— А вы что, не можете спроектировать сайт без этих материалов? Я же вам сказал, что я хочу на нём видеть, и какие задачи он должен выполнять, — это произносится с неподдельным удивлением на лице. А ещё с лёгким амбре неуверенности в компетенции исполнителя.
— Конечно, можем, — вновь отвечает проектировщик.
-
Реакция против вариантов использования
Как только вышеизложенная модель стала общепринятой, люди тут же, как и следовало ожидать, взбунтовались против нее. Для формалистов она была недостаточно формальной, и они продолжали поиски абсолютно формального способа описания варианта использования. В то же время, она была слишком формальной для тех, кто предпочитал видеть в вариантах использования некие неформальные описания, не обладающие предопределенной структурой и не похожие на описания требований к системе. Эти последние в дальнейшем пошли в трех направлениях: списки функциональных возможностей системы, карточки с рассказами пользователей и варианты задач (task cases).
Отдельный вариант использования может включать в себя задачи сразу для нескольких программистов. Задачи для каждого конкретного программиста в нем не выделяются. Поэтому некоторые программисты требуют списки функциональных возможностей системы, которые можно было бы принимать за индивидуальный план работы. Несмотря на то, что создание и поддержание таких списков значительно увеличивают объем работы, к ним прибегают довольно часто.
Авторы Экстремального Программирования (ХР) остались верны идее неформальных сценариев, у которых нет никакой заданной структуры. Кент Бек (Kent Beck) создал термин "рассказ пользователя" (user story). Именно им и стали называть такие неформальные требования к системе. Рассказ пользователя состоит из нескольких фраз, записанных на маленькой бумажной карточке. В них пользователь объясняет, что именно он хочет от системы. В ХР рассказ пользователя представляет собой не требование к системе, а некое напоминание о будущем обсуждении этой функциональности с заказчиком. Таким образом, на карточке достаточно записать ровно столько информации, чтобы и заказчики, и программисты поняли, что именно им нужно будет обсудить в дальнейшем.
Ларри Константайн (Larry Constantine) рассматривает описание сценариев с точки зрения проектирования пользовательского интерфейса. Он обнаружил, что для этого ему совершенно не нужно описывать внутреннее поведение системы или ее взаимодействие с второстепенными действующими лицами. Для проектирования интерфейсов вполне достаточно текста, записанного в две колонки. В первой пишут то, что пользователь пытается сделать, во второй – как реагирует на его действия система. Такая простейшая структура позволяет создать интерфейс, отвечающий задачам пользователя. Чтобы избежать путаницы, Константайн переименовал "вариант использования" (use case) в "вариант задачи" (task case), так как варианты использования традиционно представляют собой спецификацию системы
Источник... (http://www.rsdn.ru/article/Methodologies/usecases.xml#EMG)
Что скажете? Господа? Кто использовал?
-
Кто использовал task case по Константайну?
-
Кто использовал task case по Константайну?
Я использую это постоянно, когда пишу test cases.
Идея описать интерфейсное взаимодействие нормальна и очевидна. Однако, зачастую при описании ТРЕБОВАНИЙ мы еще не знаем, что конкретно следует делать пользователю: жмакать кнопку, кликать ссылку, подмигивать левым глазом, говорить голосом, делать странные движения телом, а может просто вставить некий предмет в некое устройство.
Если же старательно избегать конкретного действия с интерфейсом, то мы "вырождаемся" в обычный сценарий использования.
-
Павел,
ИМХО у Вас не хватает еще одного звена - архитектора или проектировщика, который уже будет делать дизайн для кодировщиков. Выделите такую роль, дайте таким людям побольше з\п и статус и будет вам счастье.
-
Не скриншот, а нарисовать от руки....
Забыл сказать - еще мы приняли за основу обсуждать проблему рисуя на доске, затем фотаем доску и тоже отправляем в хранилище вместе с остальными документами. Иногда бывает просто взглянешь на доску в процессе обсуждения - и сразу обновляется в памяти разговор минувших дней.
Все эти упрощенные методы создания одноразовых документов - рисование мелом на доске с фотографированием, рисование от руки на листочке в стиле курица лапой и т.д. безусловно хороши в небольших по числу участников и длительности проектах. Но в хотя-бы сколько-нибудь масштабных и длительных проектах так работать невозможно: а как вносить и помечать изменения, как исправлять ошибки, как рецензировать, как создавать новые версии? А если ведется удаленная разработка?
Приходится вести настоящую документацию в электронном виде, дешевле обойдется.
... А оставшееся время посвятить тому, чтобы разработчики и аналитики не уходили с проектов целыми командами. ;) Была ведь какая-то причина для их массового ухода?
...
Опять же, время жизни большой системы может составлять несколько лет, а то и десяток-другой лет. За это время в коллективе неизбежно произойдут изменения. Да даже и старые люди через несколько месяцев не будут помнить что там в деталях происходит.
Поэтому делайте скидку на масштаб. Что позволено быку недопустимо для Юпитера:))
-
Поэтому делайте скидку на масштаб. Что позволено быку недопустимо для Юпитера:))
Что вы предлагаете?
-
Все эти упрощенные методы создания одноразовых документов - рисование мелом на доске с фотографированием, рисование от руки на листочке в стиле курица лапой и т.д. безусловно хороши в небольших по числу участников и длительности проектах. Но в хотя-бы сколько-нибудь масштабных и длительных проектах так работать невозможно: а как вносить и помечать изменения, как исправлять ошибки, как рецензировать, как создавать новые версии? А если ведется удаленная разработка?
Приходится вести настоящую документацию в электронном виде, дешевле обойдется.
Рисование мелом на доске (лучше - цветным маркером) вполне работает и на больших проектах (несколько лет разработки). И оно становится настоящей документацией, если сфотографировать и выложить в систему ведения дока. А если что изменилось - нарисовать новую и опять сфотографировать, с простой схемой это легче, особенно если она появляется в обсуждении, а не имеет персонального авторства. Естественно, часть артефактов должна быть не в таком виде, например, диаграмма классов системы предпочтительна электронная - чтобы поддерживать актуальность. А вот эскиз формы - зачем он? Когда форму сделают - на нее всегда можно посмотреть живьем. Если оценивать количественно, то большинство артефактов постановки может быть легким, а меньшинство, хотя и самое существенное - сделано в полноценном виде.
-
Рисование мелом на доске (лучше - цветным маркером) вполне работает и на больших проектах (несколько лет разработки). И оно становится настоящей документацией, если сфотографировать и выложить в систему ведения дока. А если что изменилось - нарисовать новую и опять сфотографировать, с простой схемой это легче, особенно если она появляется в обсуждении, а не имеет персонального авторства. Естественно, часть артефактов должна быть не в таком виде, например, диаграмма классов системы предпочтительна электронная - чтобы поддерживать актуальность. А вот эскиз формы - зачем он? Когда форму сделают - на нее всегда можно посмотреть живьем. Если оценивать количественно, то большинство артефактов постановки может быть легким, а меньшинство, хотя и самое существенное - сделано в полноценном виде.
Метод фотографирования нарисованного мелом очень хорош при адекватном применении, обратного я и не утверждал. Но не универсален и не серебрянная пуля. Есть своеи плюсы, но и минусов хватает.
Критичен не общий размер и длительность проекта сами по себе (тут меня поймали на слове), а:
- количество и частота изменений - начиная с некоторого предела задолбаешся перерисовывать
- число участников обсуждения архитектуры конкретного модуля (малокритично впрочем - могут потом фотографии посмотреть)
И, к тому же, не всем подходит - лично мне проще набросать диаграмки в case чем нарисовать что-то аккуратно от руки - разьве только что-то для себе, чтобы никто не видел:))
То что артефакты постановки должны быть максимально легкими в минимально достаточном количестве и качестве - согласен. Волпрос только в том, что входит в этот минимальный набор в каждом конкретном случае.
Что касается необходимости проектирования внешнего вида интерфейсных форм вообще - то это отдельный дискуссионный вопрос.
Иногда можно обойтись - достаточно определить состав полей, источники данных, их свойства и поведение, а морду форм программист сам нарисует.
В других случаях, наоборот, надо согласовывать дизайн форм с заказчиком - тогда это даже не проектирование форм, а определение требований к ним, и выполняется на этапе анализа требований.
Хроошее компромисное решение - нарисовать прототипы форм в том же интсрументе, в котором ведется разработка, но без функциональности, назвать это прототипом и всем показывать. Но - это, как правило, не могут сделать аналитики, они могут только увидеть результат и раскритиковать.
А еще бывают извращенцы, которые прототипы форм рисуют в ворде псевдографикой (вот сейчас наверняка найдется кто-нибудь, кто кинет в меня помидором, и раскажет, как это удобно:)))
-
Алгоритм действий для разработчика это должно быть:
Алгоритм действий для разработчика это должно быть:
Цитировать:
Открой редактор кода
Напиши #include <stdio.h>
Напиши void main() {
…
Нет, для этого существует старый добрый псевдокод:))
Кстати, кроме смеха, эффективный, хотя и очень трудоемкий метод, программисты любят.
Стоит использовать, например, для документирования критичных ХП и триггеров в базе данных.
Что попроще - просто русский структурированный естественный язык в стиле описания сценариев (см. ход процесса use case и другие).
-
В таком варианте - полностью согласен. Мне, кстати, тоже проще накидать диаграммы в visio, чем от руки - когда один делаю, а вот при коллективном обсуждении и проработке - наоборот, на доске проще. Так что всякий инструмент хорош к месту. А что касается форм - то я имел ввиду сложные формы, где надо располагать области и описывать взаимодействие. Тут, кстати. мне лично мне не хватает средства моделирования в котором можно было бы прикинуть форму с характерным наполнением модельными данными под разными разрешениями и размерами шрифтов, а надо бывает... Наверное, действительно можно в конечном инструменте, но слишком напоминает "модель паровоза в натуральную величину"...
-
Ну на это у нас прогеры аргумент такой выдают: "Вы кто, системные аналитики или бизнес? Вот и пишите конкретно что программировать, какие данные в какие поля таблиц складывать"... :(
Говорят ПОЧТИ правильно - не обязаны прогеры разбираться в хитросплетениях финансовых алгоритмов, у них от своих забот голова пухнет. Вот только адресовать свой вопрос они должны не аналитикам, а проектировщикам. У аналитиков своих забот хватает, про поля таблиц они могут ничего не знать.
Для этого нужен специальный человек, который на первый взгляд, вообще не понятно в чем разбирается: он хуже знает бизнес, чем аналитик, и хуже программирование, чем программист. Зато может выступать переводчиком с аналитического на программерский:))
-
2 Странник
Конечно, программеры любят псевдокод. Им тогда ничего делать не надо, переписал его на языке - и все. Только... Тогда их работа - уровня тупой секретарской (есть квалифицированная секретарская, не путать), записал слова начальника - набил в файле. Нужны ли сейчас такие программеры? И согласны ли они получать как секретари?
А специальный человек для перевода с аналитического на программерский - это зло. Программеры - они же не тупые таджики со стройки, они все с высшим образованием. И самооценка у них всех приличная. Так что пусть напрягут свои мозги и въедут. Именно они в бизнес-язык, а не наоборот - потому что бизнес в IT-язык въезжать не будет, он для того и нанимает програмеров, чтобы те решили его проблемы. А так - при каждом переводе информация теряется, и на выходе получается вовсе не то, что нужно, процесс наблюдался неоднократно.
-
2 maksiq
Вообще-то моя реплика про псевдокод была ироничным ответом на конкретную фразу:
Алгоритм действий для разработчика это должно быть:
Цитировать:
Открой редактор кода.....и т.д.
и содержала в себе большую долю шутки (смайлики там были :) )
Но и серьезный остаток тоже там есть.
Любые тяжелые методы анализа и проектирования стоит применять выборочно, только тогда когда в них есть обоснованная необходимость. Это относится кстати говоря и к графическим нотациям - тома диаграмм бизнес-процессов производят конечно впечатление на неискушенных клиентов и начальников, но отношение практической пользы для разработки к трудозатратам у них весьма сомнительное (IMHO конечно, может кому и помогает).
Расписывать сколько-нибудь подробно все подряд в системе - это совершенно бездарное занятие (среди всего прочего - программисты быстрее кодируют, чем проектировщик пишет :D). Но критические и сложные для понимания процедуры документировать может быть в некоторых случаях целесообразно. IMHO стоит подробно документировать серверные процедуры, реализующие бизнес-логику и ограничения (разделение логики по слоям - другой вопрос). Не увлекаясь при этом подробностями - только логику упрощенно, без деталей реализации - что откуда берется и куда кладется. Перегнать потом в PL/SQL или TSQL, оптимизировать и отладить - задача простая, но не тупо тривиальная. Нотация будет конечно не вполне классический псевдокод (как в учебниках инфоматики) - скорее русский естественный структурированный язык:).
По второму пункту - нашт программисты много чего умеют. В некоторых (вполне успешных) проектах и аналитика нет - программисты сами выпытывают требования у клиента. Но все же разделение труда придумано не зря - не может один человек одинаково хорошо все уметь
-
Проектировать базу должен именно аналитик - так только он знает каким образом будут использоваться данные, которые лежат в базе.
Какой аналитик? Системный или бизнес?
Что касается бизнес-аналитика, соглашусь с постом Эдуарда:
Проектировать БД должен проектировщик, аналитик может представить возможную структуру данных и типы значений. А проектировать БД будет проектировщик.
-
Смотри: http://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%B1%D0%B0%D0%B7_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
Уровень аналитика - Концептуальное (инфологическое) проектирование
Уровень проектировщика (дата бейс архитектора) - Логическое (даталогическое) проектирование
Уровень администратора БД - Физическое проектирование
-
Тут, кстати. мне лично мне не хватает средства моделирования в котором можно было бы прикинуть форму с характерным наполнением модельными данными под разными разрешениями и размерами шрифтов, а надо бывает...
Rational Requirements Composer не пробовали? есть там работа с раскадровками в том числе возможности моделирования экрана
http://www.ibm.com/developerworks/ru/library/r-1118_zhuo/index.html
-
LDV, спасибо, но судя по описанию - это не то, что мне нужно. Там раскадровки преимущественно для web, у нас формы на MS с качественным гридом (и это надо смотреть). Ну и линейка Rational - она дорогая.
-
А специальный человек для перевода с аналитического на программерский - это зло. Программеры - они же не тупые таджики со стройки, они все с высшим образованием. И самооценка у них всех приличная. Так что пусть напрягут свои мозги и въедут. Именно они в бизнес-язык, а не наоборот - потому что бизнес в IT-язык въезжать не будет, он для того и нанимает програмеров, чтобы те решили его проблемы. А так - при каждом переводе информация теряется, и на выходе получается вовсе не то, что нужно, процесс наблюдался неоднократно.
Верно! Именно так, как говорите и должно быть, никак иначе!
Программист, на то он и программист, чтобы программировать, а также записывать все то, что он делает.
Я, аналитик. В задачи входит описать ТО, что нужно получить от системы
Программист - видит описание - создает классы, формирует код, все это фиксирует в программе
-
Считаю некорректным винить программиста в непонимании (с точки зрения аналитика) требований и последующей их неверной реализации. На мой взгляд, в ряде случаев, это не непонимание, а интерпретация программистом того документа, который предоставил ему аналитик. А интерпретация неверная не потому, что программист "тупой" и не желает понимать, а потому, что документ, созданный аналитиком, не описывает в достаточной степени однозначно разрабатываемую систему, давая, таким образом, большую свободу действий и свободу мысли. Однако, я ни в коем случае не хочу обвинить аналитика. Проблема не в том, что он не может написать однозначный документ, а в том, что ТЕКСТОВЫЙ документ в принципе не способен и не достаточен для однозначного описания системы. Думаю, что именно в этом и кроется корень зла.
В своей практике для преодоления "трудностей перевода" использую интерактивные прототипы, которые позволяют описывать как функциональность, так и внешний вид разрабатываемой системы, значительно уменьшая вероятность неверной интерпретации ТЗ. Занимается прототипированием именно аналитик или менеджер проекта - человек, который намного ближе к непосредственному заказчику, чем программист, и получающий наиболее достоверную информацию "из первых рук". Для решения этой задачи сейчас существует несколько хороших и очень хороших инструментов, позволяющих создавать полностью интерактивные прототипы без программирования вообще.
-
Я, аналитик. В задачи входит описать ТО, что нужно получить от системы
Программист - видит описание - создает классы, формирует код, все это фиксирует в программе
В этой схеме, на мой взгляд, отсутствует роль специалиста, который скажет КАК должна работать система. А это очень необходимо, потому что:
- ТО, что нужно получить от системы можно реализовать множеством различных способов;
- далеко не каждый из этих способов них удовлетворит заказчика.
Поэтому необходим ктото, во-первых поймет КАК должна быть реализована система, чтобы удовлетворить ожидания заказчика, а во-вторых согласует с заказчиком это (путем демонстрации прототипа, просто на словах или рисованием на бумажке - не важно) и возмет на себя ответственность за то, что выбранный способ реализации - верный (т.е. удовлетворяет заказчика).
Эти все функции, как мне кажется, возложены на роли архитектора и дизайнера UI. Хотя, конечно, часто, роли архитектора и дизайнера UI совмещают с ролью аналитика или программиста...
Коллеги, я прав или ошибаюсь?
-
Уровень аналитика - Концептуальное (инфологическое) проектирование
Прочитала: "мифологическое" проектирование :)
необходим ктото, во-первых поймет КАК должна быть реализована система, чтобы удовлетворить ожидания заказчика, а во-вторых согласует с заказчиком это (путем демонстрации прототипа, просто на словах или рисованием на бумажке - не важно) и возмет на себя ответственность за то, что выбранный способ реализации - верный (т.е. удовлетворяет заказчика).
Заказчику не нужно знать как система реализована.
Ему нужно выполнение его задач. Чем меньше заказчик знает о внутреннем устройстве системы, тем крепче он спит и счастливее выглядит.
К сожалению, в силу нечеткости границы между анализом и проектированием, трудно полностью исключить детали реализации из того, что согласовывается с заказчиком.
Это сильно тормозит процесс.
В идеале, умный заказчик должен подобрать грамотного исполнителя, которому он полностью доверяет, договориться с ним о бюджете, высказать свои требования и дать полную свободу.
Если заказчик мудро сделал выбор, а исполнитель компетентный, то результат удовлетворит обоих.
Но до таких бюджетов наши исполнители еще не доросли (в массе своей). Поэтому и делать пытаются то, что не умеют, и доверия нет между заказчиком и исполнителем - одно зависит от другого, так по кругу и ходим :).
-
Думаю, что здесь исходно фигурирует нечеткая формулировка. Разумеется, заказчику обычно не нужно знать как устроены внутренности системы, но при этом ему, безусловно нужно знать, как работать с системой, как с ее помощью решить свои (и/или поставленные перед автоматизацией) задачи. Поэтому я согласен с наличием такой роли, более того я сам частенько ее играл.
Насчет совмещения ролей могу сказать, что оно имеет право на жизнь, но должны быть достаточные основания для такого совмещения (в первую очередь компетентность), и отсутствие соответствующего персонала не должно быть оправданием - значит нужно как-то иначе, может быть даже коллегиально, тот же интерфейс разрабатывать, чтобы избежать волюнтаризма конкретного программиста.
Действительно, с программистом иногда возникает некая неоднозначность, в наибольшей степени она проявляется из-за традиционного нечеткого определения ролей: аналитик, проектировщик, постановщик и т.п. Там где четко определены зоны ответственности, например: кто отвечает за внешнее поведение системы, кто за интерфейс, кто за проектирование компонентов, объектов системы, другие технические особенности системы и проч. - очевидны и взаимодействия между участниками и такого рода неоднозначность не возникает.
-
Доброго времени суток) Прочитав ветку, пришел к выводу, что требуемое решение не было найдено. А ведь тема то поднята правильно, я лично, как аналитик/архитектор ежедневно сталкиваюсь с проблемой написания руководства программисту. И УВЕРЕН, что у многих аналогичные проблемы. Фраза "Дай мне детальную постановку" становится гимном программистов. А что значит детальная постановка? На взгляд программистов - 95% от описания всей задачи. Здесь немного остановлюсь: даже не столько интересуют различные схемы (юзкейсы и т.д.), прототипы (хотя очень действенно), а просто описание ВСЕГО, вплоть до запросов и условий ЕСЛИ/ТО/ИНАЧЕ. Запросы используются для описания различных математических формул, соседствующих с использованием БД, поэтому используется описание - вплоть до "возьми первую запись из выборки" (ДРУГОГО ВАРИАНТА Я НИГДЕ НАЙТИ НЕ МОГУ). Один раз решил написать прямо запросом, а не русским текстом - потом пришлось сопоставлять то, что программист счел неэффективным. Второе - ЕСЛИ/ТО/ИНАЧЕ: тоже задействованы различные математические модели, которые НИКТО НЕ ЗНАЕТ КАК ОПИСАТЬ в виде привязки мат. модель-БД. Вот и отстается писать детальный документ. ИМХО - проще (и уже сам предлагаю руководству) писать самому код, и абсолютно без разницы какой-то выигрышь во времени (если он еще будет после многочасовых споров на тему "Ты не написал в постановке...а ты сам понять то не можешь?") и теория о том, что "Невозможно все знать" (хотя все задачи под мое ИМХО ставить скорее всего нельзя). Основано на реальных событиях и средней сложности проектах
Коллеги, прошу прокомментировать и дать разумный совет, если я что-то непраавильно вижу
-
действительно, разумно перед руководством поставить вопрос стоимости разработки в части затрат на зарплату участникам. только делать это надо до начала проекта/работ. очевидно, что обычно руководство заинтересовано получить результат раньше и дешевле (если, разумеется, результат вообще нужен). зачем за работу платить тому, кто без вороха бумаг не может результата дать. тут наверное и правда проще самому накодить.
однако хотел бы предупредить о том, что это верно лишь до определенного масштаба проекта: "вчера" еще можно было самому накодить, а "сегодня" уже даже при круглосуточном кодинге ничего не успеваешь.
поэтому нужно сто раз подумать прежде чем переходить на "сокращенную" схему - будет невозможно обосновать возврат к разделению труда (начиная с некоторого масштаба это более эффективно, хотя и более геморройно).
а вообще правильный ответ, по-моему: постановка процесса разработки и построение разработки на основе компонентов (надеюсь, вам как архитектору не нужно объяснять о необходимости правильной компонентной архитектуры)
-
окей, зайду с другой стороны - вот везде в интернете уйма материала по распределению ролей в команде, зонах ответственности, различные методологии со своими нотациями...но как доходит до кодирования программы, почему то все становится непонятным - нет ни одного внятного примера документа на кодирование (без разницы сколько ролей: 5 или 2 - программист все равно всегда присутствует в команде) без разницы по какой методологии. Исходя из этого у меня просьба, если у кого-то есть возможность пояснить этот момент конкретным документом буду очень признателен, да и многим формучанам я думаю будет полезно это узнать. Спасибо
-
Для начала ответьте для себя, что такое "кодирование программы", что для этого нужно, что будет результатом и т.п. в Ваших конкретных условиях.
Конкретный документ извне получить вряд ли получится - очень уж много разных типов программ существует: от системного ПО (грубо говоря, драйверов и антивирусов) до прикладного (базы данных, сайты и еще уйма всего).
В каждом случае есть свои особенности. В каждой группе разработки - конкретные люди со своими навыками и тараканами в голове. Поэтому Ваши документы будут зависеть преимущественно от Ваших конкретных условий.
-
Фраза "Дай мне детальную постановку" становится гимном программистов...
просто описание ВСЕГО, вплоть до запросов и условий ЕСЛИ/ТО/ИНАЧЕ. Запросы используются для описания различных математических формул, соседствующих с использованием БД, поэтому используется описание - вплоть до "возьми первую запись из выборки" (ДРУГОГО ВАРИАНТА Я НИГДЕ НАЙТИ НЕ МОГУ). Один раз решил написать прямо запросом, а не русским текстом
Это не программист.
Лет 30 назад была профессия связанная с пробивкой перфокарт. Сидели тетки и переводили написанные алгоритмы в язык дырок на листе картона. То, что вы описываете - примерно из этой же области. Кодер - видимо будет подходящим названием.
-
А какой документ нужен? В каждой компании свои правила. Кому то действительно нужен почти код, кто -то оскорбляется, видя запрос. Везде люди строят свою коммуникацию.
-
Коллеги, прошу прокомментировать и дать разумный совет, если я что-то непраавильно вижу
Мой опыт (7 лет в анализе, 4 компании разной крупности и профиля, больше 20 проектов, ТЗ не считала) говорит о том, что, когда человек не хочет что-то делать, он найдет этому любые оправдания - в т.ч. и нечеткость поставленной задачи. А программисты - они люди :) сначала, а потом уже - программисты.
Поэтому, когда меня начинают динамить, я задаю себе простой вопрос - почему этот человек не хочет сейчас делать эту задачу? Если причина лежит в психологической плоскости, а так бывает в 80% случаев, я работаю в этой плоскости. Если причина в технической плоскости, выясняем, чего не хватает для решения этой задачи, и даем ему это.
Необходимо понимать, что подобные разговоры связаны не с фактической невозможностью решения той или иной задачи, а со страхом получить в бубен после того, как задача будет выполнена - если она выполнена как-то не так. Я обычно объясняю людям, что мы все идиоты примерно в равной степени, поэтому бить друг друга в бубен мы не будем - мы готовы к любым результатам, главное не стоять на месте. Но т.к. адаптивность у всех разная, а программисты не самая адаптивная категория людей, то не всем удается работать в ситуации неопределенности без сильных потерь эффективности.
Исходя из этого у меня просьба, если у кого-то есть возможность пояснить этот момент конкретным документом буду очень признателен
Вот видите - и вам тоже трудно.
А вы возьмите на себя ответственность, напишите такой документ хотя бы для своей компании, добейтесь его соблюдения - и вам станет легко :)
-
надо наверно было сразу написать)):разговор веду про прикладное ПО, не коробочное решение.
Абсолютно согласен, что в каждой компании своя история развития и, исходя из этого, свои схемы. Тогда задам вопрос так: как вы думаете, какая должна быть ОПТИМАЛЬНАЯ детализация при работе для "все что до программирования"/программирование программы (желательно с примерами)? (как то сложно написал :))
По поводу опыта работы: 2 года в аналитике и прекрасно понимаю, что психологическая ответственность периодически ставит перед командой ряд заслонок. Однако лично я в работе всю ответственность забираю на себя (естественно, если пишу задание на кодирование с ужасающей детализацией), поэтому вопросов к программисту в 99% случаев никаких.
По описанию документа - есть такая задумка, поэтому я и вытаюсь взять добрый совет/пример у своих более опытных коллег (у всех вас).
-
...Однако лично я в работе всю ответственность забираю на себя (естественно, если пишу задание на кодирование с ужасающей детализацией), поэтому вопросов к программисту в 99% случаев никаких...
а кому вопросы, если не угадал, либо прошло изменение требований?
-
а кому вопросы, если не угадал, либо прошло изменение требований?
если прошло изменение требований или не угадал - вопросы все ко мне (особенно если где-то прошла ошибка - там ест-но то время, которое затраченное на ошибочную версию ложится, скажем так, "на мою совесть" ).
Чтобы ошибиться в коде по задаче - программисту нужно постараться (иногда получается - все люди), но в остальном все мое.
И еще одна мысль вслух, я думаю многие меня поддержат - описывая детальную постановку я лично делаю то же кодирование, только на естественном языке. Остается только перевести информацию в код. Здесь, на мой взгляд, вообще никакого выигрыша во времени - быстрее сесть и сразу закодировать и не делать двойную работу.
Напишите пожалуйста примеры из своей практики реализации прикладного ПО с разделением по ролям.
-
Тогда задам вопрос так: как вы думаете, какая должна быть ОПТИМАЛЬНАЯ детализация при работе для "все что до программирования"/программирование программы (желательно с примерами)? (как то сложно написал :))
По поводу опыта работы: 2 года в аналитике и прекрасно понимаю, что психологическая ответственность периодически ставит перед командой ряд заслонок. Однако лично я в работе всю ответственность забираю на себя (естественно, если пишу задание на кодирование с ужасающей детализацией), поэтому вопросов к программисту в 99% случаев никаких
Еще раз: оптимальная стратегия - адаптивная, нет никаких священных писаний, которыми надо руководствоваться - каждый работает, исходя из собственного опыта и здравого смысла. А главное - зачем эти священные писания?... Вы же сами себя таким образом загоняете в выдуманные границы.
Что такое адаптивная стратегия - взять и спросить конкретного исполнителя - слушай, Вася, а какая степень детализации тебе нужна для решения этой задачи? А вот этой? А вон той?
Удивительное дело, но, хоть мы все и идиоты, но почти всегда способны ответить на такой вопрос :) Поэтому не надо стесняться их задавать. И делать ужасающую детализацию, если у вас ее не требуют, тоже не надо.
-
Из моего опыта: детализация не нужна. Аналитик описывает требования, но не реализацию.
-
взять и спросить конкретного исполнителя - слушай, Вася, а какая степень детализации тебе нужна для решения этой задачи? А вот этой? А вон той?
Ну да, мы так обычно и делаем. Т.е. писать имеет смысл только то, что кто-то хочет прочитать.
Плюс к тому, целесообразно фикисировать письменно все принятые решения, если их суть не документируется самим кодом, или если эти решения надо довести до людей, которые не читают код.
-
Я тоже так думала еще 5 лет назад :)
А теперь думаю - эххх, молодешшшшь!! ;D
Хотя, все зависит от контекста - какая компания, какие проекты, какие заказчики..