Сообщение Re[4]: TDD: почему он возник? от 05.03.2018 13:18
Изменено 05.03.2018 13:32 Qulac
Re[4]: TDD: почему он возник?
Здравствуйте, vmpire, Вы писали:
V>Здравствуйте, Qulac, Вы писали:
Q>>TDD это ещё и другой способ взаимодействия с заказчиком. Классический TDD подразумевает постоянное и тесное взаимодействие с заказчиком во время всего периода разработки. В идеале — представитель заказчика есть часть команды.
V>Ага, я про этот "идеал" в каждой второй книжке вижу про аджайл и всё такое. Только вот одна проблема: это не работает. По крайней мере, в аутсорсинге (в продуктовой компании может сраюотать).
V>Не для того заказчик нанимал команду, чтобы с ней плотно работать, а для того, чтобы ему всё сделали
V>А передача знаний ещё и через "представителя", которого назначают от балды — вообще кошмар. Мы вместо этого бизнес-аналитиков используем, гораздо удобнее.
Это верно, работает этот способ скверно. Я вообще сталкивался с тем, что заказчик отказывался общаться со мной до сдачи проекта.
V>Здравствуйте, Qulac, Вы писали:
Q>>TDD это ещё и другой способ взаимодействия с заказчиком. Классический TDD подразумевает постоянное и тесное взаимодействие с заказчиком во время всего периода разработки. В идеале — представитель заказчика есть часть команды.
V>Ага, я про этот "идеал" в каждой второй книжке вижу про аджайл и всё такое. Только вот одна проблема: это не работает. По крайней мере, в аутсорсинге (в продуктовой компании может сраюотать).
V>Не для того заказчик нанимал команду, чтобы с ней плотно работать, а для того, чтобы ему всё сделали
V>А передача знаний ещё и через "представителя", которого назначают от балды — вообще кошмар. Мы вместо этого бизнес-аналитиков используем, гораздо удобнее.
Это верно, работает этот способ скверно. Я вообще сталкивался с тем, что заказчик отказывался общаться со мной до сдачи проекта.
Re[4]: TDD: почему он возник?
Здравствуйте, vmpire, Вы писали:
V>Здравствуйте, Qulac, Вы писали:
Q>>TDD это ещё и другой способ взаимодействия с заказчиком. Классический TDD подразумевает постоянное и тесное взаимодействие с заказчиком во время всего периода разработки. В идеале — представитель заказчика есть часть команды.
V>Ага, я про этот "идеал" в каждой второй книжке вижу про аджайл и всё такое. Только вот одна проблема: это не работает. По крайней мере, в аутсорсинге (в продуктовой компании может сраюотать).
V>Не для того заказчик нанимал команду, чтобы с ней плотно работать, а для того, чтобы ему всё сделали
V>А передача знаний ещё и через "представителя", которого назначают от балды — вообще кошмар. Мы вместо этого бизнес-аналитиков используем, гораздо удобнее.
Это верно, работает этот способ скверно. Ну тем хуже для заказчика. Я вообще сталкивался с тем, что заказчик отказывался общаться со мной до сдачи проекта.
V>Здравствуйте, Qulac, Вы писали:
Q>>TDD это ещё и другой способ взаимодействия с заказчиком. Классический TDD подразумевает постоянное и тесное взаимодействие с заказчиком во время всего периода разработки. В идеале — представитель заказчика есть часть команды.
V>Ага, я про этот "идеал" в каждой второй книжке вижу про аджайл и всё такое. Только вот одна проблема: это не работает. По крайней мере, в аутсорсинге (в продуктовой компании может сраюотать).
V>Не для того заказчик нанимал команду, чтобы с ней плотно работать, а для того, чтобы ему всё сделали
V>А передача знаний ещё и через "представителя", которого назначают от балды — вообще кошмар. Мы вместо этого бизнес-аналитиков используем, гораздо удобнее.
Это верно, работает этот способ скверно. Ну тем хуже для заказчика. Я вообще сталкивался с тем, что заказчик отказывался общаться со мной до сдачи проекта.