Привет, коллеги!
Мне приходится как проектировать и разрабатывать продукт,
так и выдавать задания на разработку другим программистам.

Известны средства моделирования на UML, но наступает момент,
когда нужно программисту выдать текстовое задание — текст и конкретные пояснения.
В идеале хочется написать текст и не пояснять словами.

Пробовал создавать несколько файликов в Word, но уже самому с ними становится плохо работать.
Удобнее с одним фалом.
Вот у меня вопрос к опытным руководителям.

Есть ли некие программы или надстройки для Word, позволяющие вести текстовое описание как единое целое,
но с легкостью выбирать нужные части и формироватьиз них задания на разработку?

Я спрашиваю не про технологию RUP или XP. Меня интересуют средства
ведения документации и поддержки формирования заданий на разработку для данных RUP и XP
Спасибо!

Б>Пробовал создавать несколько файликов в Word, но уже самому с ними становится плохо работать.

У нас фирма маленькая, но может процесс пригодится.


Под каждую задачу пишется пусть небольшое, но отдельное ТЗ. Очень часто это ТЗ пишет тот же, кто потом и выполняет.

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

То есть, сам руководитель занимается общим планом, в своём общем документе. А написание ТЗ делегируется кому-то. И проблем с отдельным документом нет, и все ключевые точки задокументированы, и исполнитель действительно правильно понимает, что должен делать.

масса средств есть. RUP и XP — касаются самого проектираония.
задачи раздавать — это планирование. один из способов — сетевое планирование. Реализовано в ms project. outlook усть — вперед. чтобы совсем удобно было — заведите сайт группы (проекта). можно на sharepoint сделать. при этом это дело с ms project инетгрируется. А если еще и starteam использовать для руления исходниками, то его можно тоже прикрутить к ms project.
как именно планирование делать — это тож отдельная наука.
по канонм UP на проработку дается прецедент. Но опять же — разработка вещь коллегиальная. Чтобы написать документ, отдать а потом через месяц поинетресоваться как дела — тоже неверно.

Здравствуйте, noetic, Вы писали:

N>задачи раздавать — это планирование.
Я не про сам процесс раздачи, а про процесс формирования и проектирования отдельного задания.
Как и в какой момент я его выдам — это дело техники (напечатаю и раздам на собрании, например)

Можно пререфразировать вопрос!!!!
Из чего должно состоять задание программисту на разработку и как вести учет и обработку этой кипы заданий?
Как это лучше автоматизировать? Как лучше управлять заданиями?

Может есть специализированные пакеты программ?

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, noetic, Вы писали:

N>>задачи раздавать — это планирование.
А>Я не про сам процесс раздачи, а про процесс формирования и проектирования отдельного задания.
А>Как и в какой момент я его выдам — это дело техники (напечатаю и раздам на собрании, например)

А>Можно пререфразировать вопрос!!!!
А>Из чего должно состоять задание программисту на разработку и как вести учет и обработку этой кипы заданий?
А>Как это лучше автоматизировать? Как лучше управлять заданиями?

А>Может есть специализированные пакеты программ?
Почитайте ГОСТ 34.ХХХ и ГОСТ 19.ХХХ, там все написано.

Здравствуйте, Бусел, Вы писали:

Б>В идеале хочется написать текст и не пояснять словами.

Это как?

А>Почитайте ГОСТ 34.ХХХ и ГОСТ 19.ХХХ, там все написано.
Люди, я не про теорию задания спрашиваю!!!

Поыторюсь

А>>Как вести учет и обработку этой кипы заданий?
А>>Как это лучше автоматизировать?
А>>Интересуют специализированные пакеты программ

Здравствуйте, Бусел, Вы писали:

Б>В идеале хочется написать текст и не пояснять словами.

Так не бывает

Б>>В идеале хочется написать текст и не пояснять словами.
_J_>Так не бывает

А кто спорит? В идеале же!!!!

Но перед глазами у программиста будет текст и схемки, а не голые слова, которые он поймет как хочет.
А вопросы у программеров всегда найдутся!
Только вот чем меньше вопросов задет программист и правильно выполняет задание, тем выше уровень программиста!!!
Это аксиома

Здравствуйте, Аноним, Вы писали:

Б>>>В идеале хочется написать текст и не пояснять словами.
_J_>>Так не бывает

А>А кто спорит? В идеале же!!!!

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

Причем чем больше текста и схемок тем больше вопросов

А>Только вот чем меньше вопросов задет программист и правильно выполняет задание, тем выше уровень программиста!!!
А>Это аксиома

Что значит "правильно"?
Программисты — не телепаты. Если в описании чего-то не хватает и программист, никого не спрашивая, делает все по своему разумению, очень большая вероятность того что он сделает не так как надо.
Другое дело — уметь правильно и главное кратко сформулировать вопрос.
То же самое относится к тексту и схемкам. Кратко и четко. В крайнем случае делать выноску для пространного обьяснения какого-то момента. А если надо делать UI то хороший рисунок-скриншот с небольшими комментариями расскажет больше чем несколько страниц текста.

Здравствуйте, _Jane_, Вы писали:

_J_>Причем чем больше текста и схемок тем больше вопросов

Интересно ты рассуждаешь. Если вообще ничего не написать, то программер не будет задавать вопросов?
Думаю, что просто не будет работать


А>>Только вот чем меньше вопросов задет программист и правильно выполняет задание, тем выше уровень программиста!!!
А>>Это аксиома

_J_>Что значит "правильно"?

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

А инициатива программерская тоже признак крутезны, так как программист должен додумать некие ньюансы.

Здравствуйте, Аноним, Вы писали:

А>Интересно ты рассуждаешь. Если вообще ничего не написать, то программер не будет задавать вопросов?
А>Думаю, что просто не будет работать

Когда много текста он обычно читается по диагонали соответственно жди вопросов. Это человеческий фактор. Описание должно быть достаточно кратким.

А>А инициатива программерская тоже признак крутезны, так как программист должен додумать некие ньюансы.

Иногда лучше уточнить чем потом переделывать.

Здравствуйте, _Jane_, Вы писали:

_J_>Здравствуйте, Аноним, Вы писали:

А>>Интересно ты рассуждаешь. Если вообще ничего не написать, то программер не будет задавать вопросов?
А>>Думаю, что просто не будет работать

_J_>Когда много текста он обычно читается по диагонали соответственно жди вопросов. Это человеческий фактор. Описание должно быть достаточно кратким.

А>>А инициатива программерская тоже признак крутезны, так как программист должен додумать некие ньюансы.

_J_>Иногда лучше уточнить чем потом переделывать.

Дьявол кроется в деталях!

Здравствуйте, arinat, Вы писали:

A>Дьявол кроется в деталях!

Не дьявол а клиент
Которому зачастую какая то мелочь очень важна. Например удобный шорткат, приятный цвет, может быть какой то особенный таб ордер, итд. В спецификации тяжко все все мелочи учесть.

Привет, это Бусел! Пишу не под ником, так как хочу получать собственные сообщения на e-mail.

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

Считаем, что утвержденное заказчиком ТЗ уже есть.
Планы тестирования, User Giude и Help не рассматриваем.

Здравствуйте, Аноним, Вы писали:

А>Из каких частей состоит ваша текстовая документация на уже конкретную разработку?

Работаем в основном с добавлением новых кусков в уже существующие приложения.
Текстовый документ обычно Word т.к. удобно вставлять картинки, таблицы. Один для всех.
Пишется уже после того как архитекторы чего-то там спроектируют.
Приблизительно части:

1) общая идея — что зачем и почему.
2) на какие куски/программы это повлияет
3) новые настройки (не код)
4) что заимплементить для общего пользования (классы, модули)
5) в каких кусках/приложениях и как использовать (4). Вот тут как раз могут быть примеры. Или. Если совсем новая програмулина — ее полное описание. Но это редко бывает.
6) кто какой кусок делает (группы. Внутри группы уже сами договариваются кто что делает)
7) скриншотики
7) как тестировать

Это для больших, очень больших задач.
Для тех что помельче — описания попроще. Могут сводится просто к 1-2 страницам свободного текста. Иногда use cases в текстовом виде.

А>Считаем, что утвержденное заказчиком ТЗ уже есть.
А>Планы тестирования, User Giude и Help не рассматриваем.

Здравствуйте, _Jane_, Вы писали:

_J_>Пишется уже после того как архитекторы чего-то там спроектируют.
Кто именно его пишет? (должность)

_J_>Приблизительно части:
...
_J_>7) скриншотики
Кто рисует их и в чем? (должность и средство)

Здравствуйте, Бусел, Вы писали:

Ой не помню точно как называется. Тот кто собрав требования клиентов решает как все будет выглядеть и работать. Менеджер двумя уровнями выше.
Хм, в чем... Visual + Print Screen + mspaint, обычно...

2mihailik
Спасибо за ответ.

Здравствуйте, Бусел, Вы писали:

Б>Привет, коллеги!
Б>Мне приходится как проектировать и разрабатывать продукт,
Б>так и выдавать задания на разработку другим программистам.

Б>Известны средства моделирования на UML, но наступает момент,
Б>когда нужно программисту выдать текстовое задание — текст и конкретные пояснения.
Б>В идеале хочется написать текст и не пояснять словами.

Б>Пробовал создавать несколько файликов в Word, но уже самому с ними становится плохо работать.
Б>Удобнее с одним фалом.
Б>Вот у меня вопрос к опытным руководителям.

Б>Есть ли некие программы или надстройки для Word, позволяющие вести текстовое описание как единое целое,
Б>но с легкостью выбирать нужные части и формироватьиз них задания на разработку?

Б>Я спрашиваю не про технологию RUP или XP. Меня интересуют средства
Б>ведения документации и поддержки формирования заданий на разработку для данных RUP и XP
Б>Спасибо!