В теме 6 ответов, и 4 участника, последнее обновление сделано пользователем 
Анастасия 11 г, 7 мес. назад.
-
Сообщения
-
Я знаю, что на этом форуме есть не только аналитики. И у некоторых есть опыт работы в команде без аналитиков как таковых.
Собственно интересно узнать, как это: какие есть трудности (и есть ли они вообще) и как происходит работа с требованиями в таких условиях.
Особенно здорово, если кто-то успел поработать и с аналитиками, и без них, и может сравнить.Если команда небольшая (до 5 человек) и внятная + сроки позволяют, то как таковые выделенные аналитики не обязательны (хотя и напряг с "взаимодействием с пользователями и согласованием документации" возникает).
Т.е. каждый член команды совмещает в том числе и функции аналитика.
Если группа аналитики "никакая", то лучше без них
Если аналитики внятные — тогда вообще счастьеЕсли команда небольшая (до 5 человек) и внятная + сроки позволяют, то как таковые выделенные аналитики не обязательны (хотя и напряг с "взаимодействием с пользователями и согласованием документации" возникает).
Т.е. каждый член команды совмещает в том числе и функции аналитика.
Если группа аналитики "никакая", то лучше без них
Если аналитики внятные — тогда вообще счастьеТут не поспоришь, что если кто-то не выполняет своих обязанностей, то нафиг он такой красивый нужен. Это я к вашим последним двум строчкам (:
Вы вот оперируете такими терминами как "никакой" и "внятный". Мм.. а можно как-нибудь раскрыть их? Вот поднималась тема про то, как вычислить, нужны ли аналитики ("Задачка на про аналитика."). А вы, могли бы чуть более подробно рассказать, как оно "с", как оно "без", каковы критерии когда можно работать так, а можно эдак и т.д.?Попробую. Пока без формул
По поводу "никакой" и "внятный".
Если группа аналитики не в состоянии описать границы проекта за 15% от сроков длительности проекта — то это, если считать, что сроки проекта обоснованы, — "никакая группа". Аналогично, если документ аналитика не удается согласовать за 3-4 итерации обсуждения с разработчиками и заказчиком. Аналогично, если при реализации результаты аналитики выбрасываются и разработчики заново занимаются постановкой задачи.Соответственно, внятной аналитика является:
1. Если документация подготовлена в заданные сроки (как-минимум, комплект ТУ, ЧТЗ за 2-3 недели до начала реализации).
2. Если документация согласуется в срок до 1-2 недель с количеством итераций до 4-х.
3. Если не требуется выезд разработчика на объект, чтобы "перевести с башкирского", что же означаете тот или иной термин в документации.
4. Если софт, созданный по документации не выглядит для заказчика чем-то неожиданным.По поводу "гнать таких надо" — согласен, но есть "НО" в виде "политических решений" и "особых, неприкасаемых людей".
PS. Сроки брались из реальных проектов по внедрению MES систем на заводах в России.
PPS. 0-условие внятной аналитики — группа аналитики должна четко представлять систему, под которую она эту аналитику делает.По "моим" проектам.
1. Выделенная аналитика была "не нужна" (точнее, не было жизненной необходимости, критически влияющей на ход и сроки проекта) когда вся группа разработки (3 человека) сидела непосредственно на объекте и допиливала софт до вменяемого состояния. При этом "аналитика" понадобилась, чтобы задокументировать результат и загнать заказчика в нужные рамки "постфактум" (когда проект был завершён).
2. Выделенная аналитика особо не нужна, когда требуется сделать нечто небольших размеров (до 1ч/мес) с возможностью непосредственно опытному разработчику предметно пообщаться с заказчиком непосредственно на объекте.
3. Выделенная аналитика жизненно необходима в условиях конвейерной разработки (проекты для группы разработки идут одни за одним или внахлест), для ситуации, когда невозможно (причины — в том числе и "политические") работать общаясь непосредственно с пользователями, когда присутствует формальный подход к ведению проекта (очень, кстати, стимулирующая вещь).
4. Существование выделенной аналитики даже не обсуждается при фиксации того, что сделано при переходе на сопровождение (окончательная фиксация интерфейсов в виде ТУ).Вот как-бы так
А как происходит документирование требований? Возникает ли в нем необходимость, когда участников проекта меньше 5 и все оперативно обмениваются знаниями устно?А как происходит документирование требований? Возникает ли в нем необходимость, когда участников проекта меньше 5 и все оперативно обмениваются знаниями устно?
Зависит от проекта и от взаимодействия с заказчиком. Вообще в идеале, если "все дружат" и нагрузка позволяет одному человеку отрабатывать понятные ему требования в течение 1-2 недель, достаточно неформального общения "протоколов совещаний", "служебных записок", "логов из аськи", "багов в мантисе".
В более сложных случаях обычно хватает "протоколов" и "служебок" + (для описания интерфейсов, поведений) — ТУ и регламентов.
В совсем тяжелых случаях — полномасштабной документацииЯ работаю тестировщиком. Пришла на проект два месяца назад, к тому времени проекту исполнилось уже 5 месяцев. Было очень сложно влиться в него, так как никакой документации нет — никаких тебе даже минимальных требований к системе. Никаких аналитиков, которые бы с чувством, с толком, с расстановкой объяснили бы все… требования составляет непосредственно сам заказчик, честно сказать доволи непостоянный человек. И требования меняются на раз. Работать очень тяжело. Так как бывало и такое, что мы неделю трудились над новым функционалом, а в итоге все это не нужно и приходилось все сносить и делать заново. Вот такая вот история.
Вы должны авторизироваться для ответа в этой теме.
