Size: a a a

Аналитики Москвы

2020 February 28

AB

Anton Bukreev in Аналитики Москвы
Anna
Ну это же больше к договоренностям относится? Мы вам это, вы нам то. Записали. Разрабатывается то сильно больше
Не всегда это прям так работает. Иногда приходиться синхронизировать требования между разными бизнесовыми командами в рамках параллельной  разработки нескольких сервисов. Необходимо явно фиксировать какое требование приехало из какого сервиса с каким весом и на что влияет. Иначе потом при конфликте интересов придется очень долго выяснять что да как. При работе с госами например нет шансов переложить данную работу на заказчика (Спойлер: не работайте с госами по возможности).   на текущем проекте овер9000 тысяч таких ситуаций было
источник

АЭ

Алексей Эпов in Аналитики Москвы
Daria Kaftan
Человек написал код. Потом его дорабатывали без него другие разрабы
А если при этом дело было за три дня до релиза, доработку по багам впихнули тому, кого сумели найти свободным и он, не спав трое суток, все кардинально поменял — вообще сказка.😀
источник

ИГ

Ирина Гертовская in Аналитики Москвы
Алексей Эпов
А если при этом дело было за три дня до релиза, доработку по багам впихнули тому, кого сумели найти свободным и он, не спав трое суток, все кардинально поменял — вообще сказка.😀
Что есть типичной ситуацией на больших проектах )
источник

A

Anna in Аналитики Москвы
Алексей Эпов
Даже при учете несменяемости разработчиков, что выглядит фантастикой, через год или два они уже не вспомнят какие были требования и, даже разобравшись в коде, будут долго думать почему они это сделали, что именно хотели получить на самом деле, а что являлось компромиссным решением, это не говоря о тестировщиках, которые тихо начнут сходить с ума уже через полгода.
Почему? Они же постоянно в контексте того что сервис делает. И должны его знать
источник

A

Anna in Аналитики Москвы
Daria Kaftan
Человек написал код. Потом его дорабатывали без него другие разрабы
Ну так они же должны общаться, код ревью делать
источник

A

Anna in Аналитики Москвы
Anton Bukreev
Не всегда это прям так работает. Иногда приходиться синхронизировать требования между разными бизнесовыми командами в рамках параллельной  разработки нескольких сервисов. Необходимо явно фиксировать какое требование приехало из какого сервиса с каким весом и на что влияет. Иначе потом при конфликте интересов придется очень долго выяснять что да как. При работе с госами например нет шансов переложить данную работу на заказчика (Спойлер: не работайте с госами по возможности).   на текущем проекте овер9000 тысяч таких ситуаций было
Ну тут всегда надо чтобы кто-то сверху сказал "делайте хорошо" и помогал пробивать стены. Иначе в таком подходе будет только боль
источник

A

Anna in Аналитики Москвы
Алексей Эпов
А если при этом дело было за три дня до релиза, доработку по багам впихнули тому, кого сумели найти свободным и он, не спав трое суток, все кардинально поменял — вообще сказка.😀
Тесты? Код ревью?
источник

A

Anna in Аналитики Москвы
Кажется вы говорите в целом о том "ну можно, только будут делать люди хреново все равно и тогда нельзя"
источник

A

Anna in Аналитики Москвы
Ну так надо делать хорошо
источник

A

Anna in Аналитики Москвы
Я поменяю первоначальный поинт свой на "можно ли обойтись без трассировки требований и при каких условиях"
источник

АЭ

Алексей Эпов in Аналитики Москвы
Anna
Тесты? Код ревью?
Смешно. На больших проектах можно только код ревью всем вместе около года заниматься.
источник

A

Anna in Аналитики Москвы
Алексей Эпов
Смешно. На больших проектах можно только код ревью всем вместе около года заниматься.
Я не понимаю что смешного. На больших проектах не делают код ревью?
источник

АЭ

Алексей Эпов in Аналитики Москвы
Делают. На ту часть кода, которая в работе в текущий момент.
источник

A

Anna in Аналитики Москвы
Вообще все это не работает, если нет стандартов разработки.
источник

ИГ

Ирина Гертовская in Аналитики Москвы
Алексей Эпов
Делают. На ту часть кода, которая в работе в текущий момент.
Если успевают. Правда, это не всегда успевают.
источник

A

Anna in Аналитики Москвы
Ирина Гертовская
Если успевают. Правда, это не всегда успевают.
ну значит процесс плохой.
источник

АЭ

Алексей Эпов in Аналитики Москвы
Ирина Гертовская
Если успевают. Правда, это не всегда успевают.
Когда мэйнтейнеры у каждого модуля есть им приходится все текущие изменения ревьювить, но только текущие.
источник

АЭ

Алексей Эпов in Аналитики Москвы
Anna
ну значит процесс плохой.
Идеальный процесс эта такая вещь, о которой все знают но никто не видел.
источник

A

Anna in Аналитики Москвы
Алексей Эпов
Идеальный процесс эта такая вещь, о которой все знают но никто не видел.
ну есть что-то к чему надо стремиться. И улучшать по мере движения. Итеративно
источник

ИГ

Ирина Гертовская in Аналитики Москвы
Anna
ну значит процесс плохой.
Процесс может быть и не плохой. Но не всегда выполнятся. Это раз. Но опять же, надеятся на код как источник описания требований - ну я бы такой процесс не считала хорошим.
источник