История одного провала

[Dehumanizer]

пойду поем

[dtcDev]

приятного

[Matrixcracker]

Лучше б вы придумали сотрудникам имена.

[dtcDev]

Две компании и два сотрудника — не думал, что будет такая беда с тем, чтобы их идентифицировать по буквам

[yruslan]

… назовем его проект 1. С компанией А.

Долго всматривался и думал: «1С, что-ли?»

Статья понравилась, особенно про «осенизм». Весной и осенью у шизофреников обостряется активность, так что очень верно подмечено.

[dtcDev]

Видимо, настройки компилятора.

[evgeny_goldin]

А почему крах? Процесс идет, все как обычно.

[dtcDev]

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

[amlet]

Если тот B был программист и писал бизнес-логику, что мешает не заниматься разбором текстового ТЗ, а «написать» его в виде юнит-тестов?.. Т.е. вы с ним всё обговариваете, потом по общему понимаю совместно разрабатываете api взаимодействия с его бизнес-логикой, после чего лично вы, как пользователь его бизнес-логики пишите тесты (которые конечно же будут падать, потому что под api пока заглушки), которые в будущем будут показывать, насколько будущая бизнес-логика будет удовлетворять такому _ТЗ-набор-тестов_. Тут хоть на brainfuck'е бизнес-логику пиши — одна хрень, взаимодействие только через api.

[dtcDev]

Как бы это помягче сказать… Суперкласс, 40 входных переменных, хранение данных предварительных рассчетов в массиве выходных данных, который под темповые области вручную увеличен в два раза (вместо размерности [x,y,z], которая описывает иерархию, выполнен в виде [x, y, 2z]), да и вообще — хранение данных в ООП языке в стиле процедурного программирования… Боюсь, юнит-тесты вызвали бы гору непонимания и долгие объяснения «как, что и зачем».

[amlet]

я что-то не понял: в описываемом проекте бизнес-логика стала в результате замешана с UI?

[dtcDev]

Именно.
А если быть совсем точным, то изначальный уровень абстракции был попилен в угоду количеству комментариев и переделок и постоянно сокращаемым срокам. В результате — костылестроение

[amlet]

… и ещё большее увеличение сроков…

… просто никто ничего не мерял… да и не будет… ведь так приятно сидеть в неведении и ощущении внутреннего «эффективного» менеджера :)

А вообще я не понял вот это:

> в угоду количеству комментариев

что это значит? какие ещё комментарии? в коде? или что-то другое имелось ввиду?

[dtcDev]

Имелось ввиду комментирование псевдоготового результата. Неоттестированное толком приложение демонстрировалось заказчику, после чего появлялась еще кучка требований и комментариев к программе, способу ее работы и взаимодействию с окружающим миром. Ну а так как у нас результат все же с приставкой псевдо-, то недоработки в том, что показывалось, возникали неизбежно. Как следствие, чтобы сгладить проблему нерабочей программы (которую, попросту, надо было оттестировать корректно, ибо сроки все равно увеличивались в два раза от озвученных мною и в 4 — от спущенных сверху в виде дедлайна), то эти комментарии принимались.

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

[sluge]

одно дело что написано а другое-собственный опыт. вот благодаря таким обломам знания и трансформируются в опыт.
а вообще agile вам в помощь

[dtcDev]

Постоянно использую agile в разработках. Но когда по всем нормативам получается 80 часов, которые под лозунгом «даешь пятилетку в три года» трансформируются в 30 часов, никакая система не поможет. Урезание, и зачастую за счет тестирования и отладки