MonochromatiqueСкажем - группой 10 программистов.

Считаем что:
1. Что количество программистов адекватно задаче. (+/-)
2. Что пользовательские истории зафиксированы.

Чего хочется:

Предсказуемость разработки.

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

Что имеем:

Первоначальное описание решения - является неким упражнением для писательского таланта. Ценность теряет ОЧЕНЬ быстро, потому что разработка очень быстро идет в сторону.

Зачастую из-за:

1. Пользователи говорят одно, думают другое, а нужно третье.
2. Архитектор перемудрил и решил сделать космолет, который должен рыть бассейны в условиях сверхгравитации и нехватки естественных осадков.
3. Программист неправильно понял, что нужно сделать - и убил три дня на неприменимую ерунду.
4. Программист решил написать свой мега-фреймворк, на который убил 95% времени, результата не достигнув.



Вопросы:

1. Каким образом получить исчерпывающее описание проекта, которое не придется выбрасывать в мусорку через месяц?

2. Каким образом технически запретить уходить в сторону? Штуки типа WWF? Быстрые прототипы? Лично я склоняюсь к прототипам.

Теперь к коду.

Следующая проблема - в системах типа 1С - любой программист имеет доступ к любой части кода. Сам себе архитектор. Когда их 10 человек - уследить за всеми нереально и трешовый код/решения потихоньку берут верх.

В .NET/JAVA я представляю что можно сделать - закрыть сборку с моделями и создать нужные интерфейсы, которые потом последовательно реализовывать, но что делать в той же 1С??
В 1С один кодер намутит треш, другой нагородит зауми, пытаясь сделать универсальную приладу, которая нужна всем (никому).


Иными словами - какой процесс обеспечит:

1. Разумное количество слоев управления разработкой (истории, требования,UI ,код )
2. Качество артефактов каждого слоя. Оно должно быть таким, чтобы с каждым низлежащим слоем мог работать специалист, не вовлеченный в этот проект прежде.
3. Каждый артефакт должен быть валидным и не противоречивым! Код понятно - он хотя бы должен работать, а как быть с описанием какого-то процесса?? Как убедиться, что процесс выдает ровно тот результат, который сможет принять на входе следующий процесс? Нужны четкие тиски, но какие тиски у Вордовского документа? Бумага всё стерпит.

Нужно качество превратить в количество.

Читаю истории, в которых над проектами трудятся люди из разных стран и часовых поясов - как их координировать?

Тогда как собственные сотрудники без стояния за спиной сразу же стремятся расползтись в стороны.

Как это может выглядеть? 1С case

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

Принято решение переписать всё нафиг на современных технологиях.

(Тут всё начинается).

Бесконечные совещания, на которых пользователи разных рангов рассказывают о своих фантазиях. Всё, что снилось - всё вываливают. Объяснения куцые, пальцы показывают замысловатые фигуры.

Составляется описание нового решения, страниц так на сто. Несмотря на картинки - его никто не читает, и также никто возражений не имеет.

Начинается разработка. По грубой оценке - к оценке привлекаются n-программистов.
Начинается разработка.
Появляются первые результаты.
Первые показы.
Пользователи в недоумении - нужно же было по другому.
Начинаются переделки/доработки, причем каждый программист делает это "втихую", потому как так сказала Лена-менеджер.

Ну и в итоге разработка приобретает хаотичный характер.

Не думаю, что в случае технологий вида JAVA/.NET картина принципиально другая.
Единственно - больше времени нужно потратить на проектирование интерфейсов, но и программист-кодер в сторону не уйдёт.

Что НЕ хотелось бы тут обсуждать:
1. UI
2. UX
3. Назначенным со стороны клиента менеджерам - плевать на внедрение.
4. Назначенные со стороны клиента менеджеры - некомпетентны.У нас к примеру разработка ведётся в группах (артелях).
Последние сами решают какие задачи им взять из роадмапа, сами их анализируют, оценивают, готовят прототипы, проводят UX тестирование, обкладывают метриками, тестируют.

iscrafmskyANAУ нас к примеру разработка ведётся в группах (артелях).
Последние сами решают какие задачи им взять из роадмапа, сами их анализируют, оценивают, готовят прототипы, проводят UX тестирование, обкладывают метриками, тестируют.
так делается, но не при создании новой системыНу не знаю. Мы успешно выпускаем новые фичи.

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

Принято решение переписать всё нафиг на современных технологиях.
Бизнес-процессы выстроены, надо их улучшить.