Как вы реагируете на аргумент «Нет времени на тестирование / разработку чистого кода из-за крайнего срока»?

Question

Хорошо, я думаю, что этот вопрос не в том месте, и я отправлюсь на https://softwareengineering.stackexchange.com/, чтобы прочитать / спросить об этом. Спасибо всем за ваши ответы до этого момента. :)

---

извинения ;) Извините, если этот вопрос немного субъективен, но я не могу придумать лучшего названия. Я исправлю это, если вы знаете что-то лучше.

В моей организации много шума по поводу всего этого автоматического тестирования и непрерывной интеграции , но я постоянно слышу один аргумент:

Как мне разработать хороший, чистый, простой в обслуживании код и написать модульные тесты, если срок уже установлен, и это только половина моей оценки?

Я сам разработчик, поэтому я могу это понять. Но я всегда стараюсь отвечать, что не только разработчики нуждаются в смене парадигмы, но и менеджмент.

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

Заключение

Можете ли вы дать мне некоторую помощь, это может быть хороший URL-адрес, чтобы прочитать об этом конфликте развития / управления, книга или, возможно, личное понимание? Вы пережили такой большой технологический сдвиг в компании Waterfall, которая сейчас занимается разработкой Lean? Или вы знаете этот аргумент и имеете на него умный ответ?

И, пожалуйста, помогите мне переименовать или переместить этот вопрос. : -)

Обновление

Спасибо за все ответы уже! :) Я думаю, что должен пояснить, что моя точка зрения не была «1036 * сделать это в два раза быстрее » от руководства. Речь идет о негативной точке зрения, которая приходит с этим заявлением от разработчика.

Могу ли я что-нибудь сделать, чтобы помочь людям понять, что это не стандарт по умолчанию при разработке программного обеспечения? Что премьер-министр не препятствует написанию хорошего кода, и, возможно, обеим сторонам нужно немного больше узнать о плюсах / минусах основ чистого кода, хорошем освещении и множестве автоматизированных тестов?

Answer 1

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

Это похоже на хруст перед выпуском.Вы берете на себя некоторый долг, а затем скоро возвращаете его.Если вы продолжаете взимать плату и никогда не расплачиваетесь с этим долгом, он начинает усугубляться.Эта новая функция, которую вы хотите сделать более трудной, потому что основа, на которой вы строите, несостоятельна.Долги, которые вы накопили, мешают вам действовать быстро.Если вы превысили свой лимит, даже типичные мелкие покупки не пройдут.

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

Answer 2

Это может звучать пораженчески, чтобы сказать это, но я работал в нескольких магазинах, у которых была эта проблема, и они никогда не менялись - или, точнее, я обнаружил, что невозможно изменить систему изнутри.

Проблема заключается в том, что с точки зрения руководства, которое настаивает на таком типе разработки, пока продукт выпускается примерно в срок и покупатели его покупают, цель достигнута. Другими словами, Пока вы зарабатываете деньги, качество не имеет значения .

Теперь вы, я и опытный менеджмент понимаете долгосрочную стоимость технического долга. Может оказаться возможным объяснить рациональному руководителю стоимость технического долга, сложное сокращение прибыли на инвестиции в программистское время (безусловно, самая дорогая часть программного проекта) и тот факт, что чистый, хорошо спроектированный, хорошо Протестированная база кода означает, что новые функции могут быть реализованы быстрее и что больше времени можно потратить на новые функции вместо исправления ошибок, что приведет к долгосрочному улучшению среднего времени между выпусками.

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

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

Answer 3

Что вы имеете в виду ваши "оценки сократить наполовину"? Вы имеете в виду, что вы даете оценку, а руководство говорит: «Нет, сделайте это в два раза быстрее»? Это недопустимо.

Кто-то должен оттолкнуться от управления. (Я говорю «кто-то», потому что я не знаю вашу иерархию.) Нет такого понятия, как бесплатный обед. Если они хотят этого раньше, то они должны пойти на тяжелые, болезненные компромиссы. Они должны устанавливать приоритеты и отбрасывать функции с более низким приоритетом.

Если они скажут: «Нет. Нам все это нужно сейчас. Сделайте это раньше или иначе», держитесь за линию. Они могут быть удивлены и расстроены, но вы заслужите их уважение. Изменения наступят, когда они начнут слушать.

Не должно быть конфликта между управлением и развитием. Конфликт между руководством и время . Это не твоя вина, нужно время, чтобы что-то делать. Их работа заключается в том, чтобы принимать трудные решения вовремя выпустить продукты, не перегружая разработчиков, пока они не уйдут в изнеможении. Просто сказать: «Неправильно, делай это в два раза быстрее» - это не менеджмент. Это фантазия.

---

В действительности ваше руководство, вероятно, будет продолжать оставаться глупым. Если это так, вы можете попытаться сыграть в их игру: придумайте надежную оценку, которую, по вашему мнению, очень безопасно с помощью автоматизированного тестирования, а затем удвойте ее . Жалуйтесь громко, когда они сокращают часы наполовину, затем вздыхают в отставке. Позвольте им чувствовать, что они делают свою работу. Миссия выполнена!

Answer 4

Как правило, если вы улучшите свои методы программирования и качество кода, вы почти наверняка ускорите свою разработку, поскольку сэкономите больше времени на отладке, чем на написании модульных тестов и попытках сделать все правильно с самого начала. Очень немногие магазины в состоянии тратить больше времени на качество кода, чем оно экономит.

Другая опасность состоит в том, что руководство вмешивается в процесс, а не просто обслуживает невозможные сроки. Если они ожидают, что вы наберете ковбойский код, чтобы уложиться в срок, вы действительно не сможете использовать передовой опыт.

Answer 5

Может показаться очевидным, но мой ответ на этот вопрос таков:

Написание модульных тестов до того, как код позволит вам разработать хороший, чистый и простой в обслуживании код

У меня была проблема с моим руководством, которое было обеспокоено тем, что разработчики не смогут выполнить свои задачи вовремя, если им потребуется написать модульные тесты - это общая проблема при попытке внедрить TDD в компании Waterfall.,Поэтому я сделал это заявление, и мы должны были доказать это, написав тесты перед кодом и не пропустив крайний срок :) На самом деле, когда вы к нему привыкнете, это позволит написать еще больше кода.

Answer 6

Хороший премьер-министр оценивает , а не . Когда-либо! Хороший руководитель получит оценку от человека, который будет выполнять работу. Они не изменят это. Они могут попытаться убедить работника изменить его, но, поскольку работник выполняет работу, они должны контролировать смету.

Если у вас есть премьер-министр, который сокращает вашу оценку вдвое, убедитесь, что ваша оценка была в письменном виде, а затем используйте это, чтобы объяснить ему (извините за гендерную предвзятость, у английского действительно нет хорошего нейтрального местоимения) и, надеюсь, его босс сказал, что причина, по которой ваша работа кажется только наполовину законченной, в том, что он искажал ваши оценки.

Тактически отметьте, что, если они не будут серьезно относиться к вашим оценкам, они должны оставить вас в покое и просто вытащить любое старое число из их derrière. Это будет иметь тот же эффект, что и пропущенные сроки и недовольные клиенты, но при этом вы не будете тратить время на предоставление номеров, которые в любом случае просто будут игнорироваться.

В любом случае, холодная война между плохими менеджерами ПО и умными разработчиками, естественно, приведет к ситуации, когда вы должны сначала удвоить свои оценки, чтобы вдвое уменьшить эффект: -)