Я работаю в небольшой команде, в компании среднего размера, большая часть которой не занимается разработкой программного обеспечения. Я - самый новый и наименее опытный разработчик, у меня не было профессионального или академического опыта в области программного обеспечения до начала работы, но я весьма доволен тем, насколько уважаем мой вклад, и благодарен за то, что меня восприняли всерьез на таком раннем этапе моей карьеры.
Тем не менее, я чувствую, что должен делать больше с таким большим количеством эфирного времени. Как команда, у нас, кажется, есть проблемы с выполнением задач. Я хотел бы предложить что-то, чтобы улучшить ситуацию, и я думаю, что меня выслушают, если это будет хорошая идея, но я не знаю, что предложить.
Вещи, которые я могу определить как проблемы, включают:
- Уточнение поставленных задач редко. Это отчасти потому, что управление является узким местом, и у нас нет денег или людей, чтобы посвятить себя разработке подробных требований так, как нам бы хотелось. Это также отчасти потому, что разрабатываемое нами программное обеспечение является следственным, и точный метод неясен, пока не будет продемонстрирован и использован для определения его эффективности.
- Ведущий разработчик очень любит то, что он называет «прототипированием», до такой степени, что он в последнее время начал настаивать на том, что все «прототипировано», что для всех нас похоже на написание плохого кода и передачу его разработчикам моделей для игры. Не ясно, что он ожидает от этого упражнения во многих случаях. «Реальная» реализация страдает из-за того, что он настаивает на том, что хорошая практика отнимает слишком много времени у прототипирования. Я даже не смог распутать эту извращенную логику, и я не уверен, что хочу попробовать.
- Предполагается, что разработчики моделей расскажут нам все о желаемой методологии в точных деталях, и она абсолютно уверена, что то, что они предлагают, теоретически безупречно. Это вряд ли когда-либо правда, но никаких действий не предпринимается, чтобы исправить эту ситуацию. Никто на стороне моделирования не вызывает каких-либо проблем в структурированном виде, на которые, вероятно, будут реагировать, и при этом они не ищут руководства в применении лучших практик. С их пассивностью тоже ничего не делается.
- Я пытался подтолкнуть TDD в команде раньше, но мне было трудно, так как это ново для меня, и хотя те, кто наблюдал за моей работой, были готовы терпеть это, никакого энтузиазма не последовало ни от кого другого. Я не могу оправдать количество времени, которое я провожу, валяя и не заканчивая функции, поэтому идея - на данный момент - была заброшена. Я обеспокоен тем, что его больше не заберут, потому что никто не любит, когда ему говорят, как выполнять свою работу.
- Теперь у нас есть сервер непрерывной интеграции, но он в основном используется только для запуска многочасовых регрессионных тестов. Было оставлено открытым, что он также должен запускать модульные и интеграционные тесты с полным покрытием, но на данный момент их никто не пишет.
- Каждый раз, когда я поднимаю вопрос о качестве с ведущим разработчиком, я получаю ответ: «Функция тестирования A проста, функция B гораздо важнее для пользователя, но слишком трудна для тестирования, поэтому мы не должны тестировать функцию А». Еще раз я не продвинулся в попытке распутать эту логику.
.... уф. Когда я это так формулирую, это выглядит намного хуже, чем я думал. Полагаю, как выясняется, это крик о помощи.
5
Насколько хорошо компания продвигает программное обеспечение, которое клиент любит и любит? Другими словами, получает ли команда хорошие результаты, несмотря на то, что вы не верите, что процесс звездный?
—
Роберт Харви
@ Роберт Харви - Мне сложно судить. Продукты чрезвычайно нишевые, и мы (разработчики) получаем смешанные сообщения. С одной стороны, новые клиенты на прорывных рынках бьют по продукту больше, чем мы изначально предполагали, и, как следствие, обнаруживают неисправности, о которых они не думают, поскольку мы объясняем причину и быстро их устраняем. С другой стороны, некоторые крупные институциональные клиенты не доверяют, и мы начинаем сомневаться в том, что несколько раз вносим поправки в модель. Команда программного обеспечения является одним из немногого преломления даже в компании в настоящее время , так что мы хорошо выглядеть на данный момент .
—
Том W
Я хотел бы получить от клиентов как можно больше отзывов о том, как договориться об основной рабочей «модели», и попытаться немного их закрепить. Это действительно может разочаровать клиентов, когда модель изменится, но если это новое, передовое программное обеспечение, оно идет с территорией.
—
Роберт Харви
Хороший вопрос. Я заметил, что даже с восприимчивой аудиторией, реальные перемены трудны, если только вы не видите, как они работают на практике. Мой совет - сначала попробовать подходы к повышению вашей производительности, а затем продемонстрировать их для команды. С практикой вы можете быстрее освоить TDD, чем писать / отлаживать / повторять.
—
Майк Б