Форум Сообщества Аналитиков

×


Постановка задачи программисту(Прочитано 119132 раз)
Re: Постановка задачи программисту Ответ #30 : 12 Июня 2010, 00:40:10
Алгоритм действий для разработчика это должно быть:
Цитировать
Открой редактор кода
Напиши #include <stdio.h>
Напиши void main() {



Re: Постановка задачи программисту Ответ #31 : 12 Июня 2010, 11:15:57
Алгоритм действий для разработчика это должно быть:

Денис, написал в личку...



Re: Постановка задачи программисту Ответ #32 : 12 Июня 2010, 16:47:01
Вот сижу и думаю... неужели это я один такой остался, вымирающий мамонт, кто понимает под постановкой задачи конкретно и четко изложенный алгоритм действий для разработчика :(

На мамонта вы не похожи. Скорее на желторотого птенца  :)



Re: Постановка задачи программисту Ответ #33 : 12 Июня 2010, 18:32:52
Вот сижу и думаю... неужели это я один такой остался, вымирающий мамонт, кто понимает под постановкой задачи конкретно и четко изложенный алгоритм действий для разработчика :(

Если уже есть чёткий алгоритм действий, то зачем нужен разработчик? :)
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Постановка задачи программисту Ответ #34 : 12 Июня 2010, 19:36:56
Если уже есть чёткий алгоритм действий, то зачем нужен разработчик? :)

Ну на это у нас прогеры аргумент такой выдают: "Вы кто, системные аналитики или бизнес? Вот и пишите конкретно что программировать, какие данные в какие поля таблиц складывать"... :(




Re: Постановка задачи программисту Ответ #35 : 12 Июня 2010, 20:35:54
Ну на это у нас прогеры аргумент такой выдают: "Вы кто, системные аналитики или бизнес? Вот и пишите конкретно что программировать, какие данные в какие поля таблиц складывать"... :(
По поводу базы данных считаю что ваши программисты правы - они не должны думать о том как спроектировать базу. Они должны иметь готовое решение откуда взять, с чем сложить и куда положить.
Проектировать базу должен именно аналитик - так только он знает каким образом будут использоваться данные, которые лежат  в базе. 



Re: Постановка задачи программисту Ответ #36 : 12 Июня 2010, 20:37:32
По поводу базы данных считаю что ваши программисты правы - они не должны думать о том как спроектировать базу. Они должны иметь готовое решение откуда взять, с чем сложить и куда положить.
Проектировать базу должен именно аналитик - так только он знает каким образом будут использоваться данные, которые лежат  в базе. 

Отсюда подробнее пожалуйста. Как это выглядит в постановке теперь?



Re: Постановка задачи программисту Ответ #37 : 13 Июня 2010, 00:07:06
Проектировать базу должен именно аналитик - так только он знает каким образом будут использоваться данные, которые лежат  в базе. 
Проектировать БД должен проектировщик, аналитик может представить возможную структуру данных и типы значений. А проектировать БД будет проектировщик.

Более того, это созвучно и с тем, что если известен алгоритм - зачем разработчик.



Re: Постановка задачи программисту Ответ #38 : 16 Июня 2010, 10:50:24
При создании нового сайта особое внимание следует уделять сбору материалов перед этапом проектирования. Как вы думаете, по какому техническому заданию работа будет вестись быстрее: по сухому описанию функционала каждого раздела, либо по такому же описанию, но наполненному конкретными примерами? Когда дизайнеру не нужно придумывать рыбный текст и искать картинки на Яндексе, а можно просто сделать копи-пэйст из ТЗ? Когда верстальщик будет иметь примерное представление об объёмах планируемых к публикации текстов потому что они у него перед глазами? Когда программист, работая над полями в базе данных, будет иметь перед глазами актуальный элемент каталога со всеми его параметрами?

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

С этого момента время на создание сайта увеличивается в два, два с половиной раза. Причина этому проста. Проектировщик лишь предполагает, какой контент будет ставиться на сайт. Ключевое слово — предполагает.
— Приведите пять примеров товаров из вашего каталога;
— Напишите тестовую новость для вашего будущего сайта;
— Предоставьте, пожалуйста, актуальную контактную информацию вашей компании.
Я выбрал три очень простых и очевидных вещи. Сайт можно спроектировать и без этих материалов. Каждый из трёх вышеперечисленных пунктиков можно заменить кипами вопросов, раскрывающих тему сисек.
— Сколько категорий товаров будет в вашем каталоге?
— Каждый товар будет сопровождаться одним или несколькими изображениями?
— У вас есть своя студия, чтобы сфотографировать шесть тысяч наименований товаров с трёх сторон?
— У различных групп товаров есть повторяющиеся характеристики?
— Как часто вы планируете писать новости?
— Кто будет этим заниматься?
— Будут ли новости с других сайтов с указанием источников?
— Готовы ли вы искать тематические картинки, иллюстрирующие каждую новость?
— Сколько офисов в вашей компании?
— Сколько есть отделов и какие?
— У каждого отдела свой телефон?
— Добавочные номера?
— Кто будет проверять почту?
И так далее, и тому подобное. И хорошо, если заказчик действительно готов выложить круглую сумму на разработку и «всецело положиться на профессионалов». В действительности же в связи с ограниченными бюджетами он старается сэкономить на чём угодно, а «профессионалами» называет вас в таком контексте:
— Вы же профессионалы. Зачем вам нужна вся эта информация для разработки сайта?
И получается, что к моменту сдачи проекта начинаются бесконечные вереницы корректировок, внесений правок, затем исправлений ошибок в связи с внесениями правок. После этого поднимается техническое задание и становится видно, что оно не совпадает с тем, что имеется на выходе. К этому моменту уже давно истрачены все возможные человекочасы. Текст на главной странице слишком громоздкий и то, что на дизайне умещалось без полосы прокрутки, теперь разбросано на три страницы вниз. В разделе с контактной информацией оказался лишь адрес электронной почты, одинокий и несчастный, а в каталоге вместо шести тысяч наименований товаров есть лишь несколько десятков, фильтрация по которым выдаёт нам в среднем по одному результату на страницу.

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



Re: Постановка задачи программисту Ответ #39 : 16 Июля 2010, 15:23:27
Цитировать
Реакция против вариантов использования

Как только вышеизложенная модель стала общепринятой, люди тут же, как и следовало ожидать, взбунтовались против нее. Для формалистов она была недостаточно формальной, и они продолжали поиски абсолютно формального способа описания варианта использования. В то же время, она была слишком формальной для тех, кто предпочитал видеть в вариантах использования некие неформальные описания, не обладающие предопределенной структурой и не похожие на описания требований к системе. Эти последние в дальнейшем пошли в трех направлениях: списки функциональных возможностей системы, карточки с рассказами пользователей и варианты задач (task cases).

Отдельный вариант использования может включать в себя задачи сразу для нескольких программистов. Задачи для каждого конкретного программиста в нем не выделяются. Поэтому некоторые программисты требуют списки функциональных возможностей системы, которые можно было бы принимать за индивидуальный план работы. Несмотря на то, что создание и поддержание таких списков значительно увеличивают объем работы, к ним прибегают довольно часто.

Авторы Экстремального Программирования (ХР) остались верны идее неформальных сценариев, у которых нет никакой заданной структуры. Кент Бек (Kent Beck) создал термин "рассказ пользователя" (user story). Именно им и стали называть такие неформальные требования к системе. Рассказ пользователя состоит из нескольких фраз, записанных на маленькой бумажной карточке. В них пользователь объясняет, что именно он хочет от системы. В ХР рассказ пользователя представляет собой не требование к системе, а некое напоминание о будущем обсуждении этой функциональности с заказчиком. Таким образом, на карточке достаточно записать ровно столько информации, чтобы и заказчики, и программисты поняли, что именно им нужно будет обсудить в дальнейшем.

Ларри Константайн (Larry Constantine) рассматривает описание сценариев с точки зрения проектирования пользовательского интерфейса. Он обнаружил, что для этого ему совершенно не нужно описывать внутреннее поведение системы или ее взаимодействие с второстепенными действующими лицами. Для проектирования интерфейсов вполне достаточно текста, записанного в две колонки. В первой пишут то, что пользователь пытается сделать, во второй – как реагирует на его действия система. Такая простейшая структура позволяет создать интерфейс, отвечающий задачам пользователя. Чтобы избежать путаницы, Константайн переименовал "вариант использования" (use case) в "вариант задачи" (task case), так как варианты использования традиционно представляют собой спецификацию системы

Источник...

Что скажете? Господа? Кто использовал?



Re: Постановка задачи программисту Ответ #40 : 16 Июля 2010, 15:27:08
Кто использовал task case по Константайну?



Re: Постановка задачи программисту Ответ #41 : 16 Июля 2010, 18:55:00
Кто использовал task case по Константайну?
Я использую это постоянно, когда пишу test cases.

Идея описать интерфейсное взаимодействие нормальна и очевидна. Однако, зачастую при описании ТРЕБОВАНИЙ мы еще не знаем, что конкретно следует делать пользователю: жмакать кнопку, кликать ссылку, подмигивать левым глазом, говорить голосом, делать странные движения телом, а может просто вставить некий предмет в некое устройство.

Если же старательно избегать конкретного действия с интерфейсом, то мы "вырождаемся"  в обычный сценарий использования.



Re: Постановка задачи программисту Ответ #42 : 19 Июля 2010, 12:12:16
Павел,

ИМХО у Вас не хватает еще одного звена - архитектора или проектировщика, который уже будет делать дизайн для кодировщиков. Выделите такую роль, дайте таким людям побольше з\п и статус и будет вам счастье.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Постановка задачи программисту Ответ #43 : 08 Октября 2010, 05:18:45
Не скриншот, а нарисовать от руки....
Забыл сказать - еще мы приняли за основу обсуждать проблему рисуя на доске, затем фотаем доску и тоже отправляем в хранилище вместе с остальными документами. Иногда бывает просто взглянешь на доску в процессе обсуждения - и сразу обновляется в памяти разговор минувших дней.
 


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


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

Опять же, время жизни большой системы может составлять несколько лет, а то и десяток-другой лет. За это время в коллективе неизбежно произойдут изменения. Да даже и старые люди через несколько месяцев не будут помнить что там в деталях происходит.

Поэтому делайте скидку на масштаб. Что позволено быку недопустимо для Юпитера:))



Re: Постановка задачи программисту Ответ #44 : 08 Октября 2010, 09:59:09

Поэтому делайте скидку на масштаб. Что позволено быку недопустимо для Юпитера:))

Что вы предлагаете?




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19