Как доказать моему заинтересованному лицу и руководителю, что мое программное обеспечение работает?[закрыто]

Question

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

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

Вам необходимо поставлять качественное программное обеспечение в срок и в рамках бюджета

Стоимость:Архитектура - это долгосрочная инвестиция.Людям, которые оплачивают счета, легко отмахнуться от этого, если только нет какой-то ощутимой немедленной выгоды, такой как списание налогов, или если случайно не окажется в наличии излишков денег и времени.Такое редко случается.Чаще всего клиенту нужно, чтобы что-то работало к завтрашнему дню.Часто люди, которые контролируют процесс разработки и управляют им, просто не рассматривают архитектуру как насущную проблему. Если программисты знают, что качество работы незаметно, а менеджеры все равно не хотят за это платить, возникает порочный круг.

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

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

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

Поэтому в основе бизнеса лежит поиск способов держать системы подальше от большого комка грязи.Что система по-прежнему ремонтопригодна.Что система действительно работает и что вы, как программист, можете доказать, что это так.Спрашивает ли ваш менеджер вас, закончили ли вы сегодня свое кодирование, спрашивает ли она вас, можно ли сегодня выпустить релиз с исправлениями A, B и C, или она спрашивает, действительно ли работает программное обеспечение, которое будет выпущено?И вы доказали, что это работает?С помощью чего?

Теперь перейдем к моему вопросу:

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

[Добавлено позже]

Крис Пеббл своим ответом ниже направляет мою команду на правильный путь.Гарантия качества - это определенно то, что мы ищем.Спасибо, Крис.Согласованная с заинтересованными сторонами политика контроля качества - это логический результат того, к чему стремится моя команда.

Следующий вопрос заключается в том, что должно быть в этой политике контроля качества?

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

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

[ добавлено позже ]

Спасибо за все ответы.Речь действительно идет о "доверии".Мы не сможем выпустить релиз, если заинтересованные стороны не доверяют программному обеспечению, которое само активно тестирует наше программное обеспечение, используя веб-сайт, использующий наш веб-сервис.Когда возникают проблемы, первый вопрос наших тестировщиков звучит так:Это проблема уровня обслуживания или проблема уровня презентации?Это побуждает меня разработать политику контроля качества, которая гарантирует, что наше программное обеспечение подходит для тестов, которые они проводят.

Итак, единственный способ, которым я могу (сейчас) представить обеспечение доверия к тестировщикам, - это:- Поговорите с текущей командой тестирования, просмотрите тесты, которые они могут выполнить вручную (из своего тестового скрипта и сценариев), и убедитесь, что у нашей команды эти тесты в виде модульных тестов уже проверены на нашем веб-сервисе.Это было бы хорошей отправной точкой для "выхода из системы", прежде чем мы выпустим релиз, который должна интегрировать presentationlayerteam.Потребуется некоторое усилие, чтобы пояснить, что создание автоматических тестов для всех этих сценариев займет некоторое время.Но это определенно будет полезно для того, чтобы убедиться, что то, что мы создаем, действительно работает.

Answer 1

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

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

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

Answer 2

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

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

Итак, какое же было решение:

• Первым делом отделили руководство от программистов и поставили дружелюбного тимлида.
• Во-вторых, найдите квалифицированную команду контроля качества.В первые несколько недель количество ошибок достигало сотен.
• В-третьих, назначьте 2-3 разработчиков в команду поддержки, там ответственность не в том, чтобы делать какие-то новые задачи, а только исправлять ошибки, работать напрямую с QA.
• В-четвертых, мотивируйте ребят, иногда дело не в деньгах или дополнительном отпуске, иногда доброе слово подойдет.Маленький пример: проработав 3 дня подряд почти по 15 часов в день, руководитель группы сделал замечание менеджеру.Два дня спустя я получил письмо от генерального директора, в котором он поблагодарил меня за мои усилия и предоставил мне 2 дня отпуска.

Скоро мы выпустим 4-й модуль системы, и как член команды поддержки я могу сказать, что в нем нет ошибок как минимум на 95%.Это огромный скачок по сравнению с нашими первыми модулями.

Сегодня у нас мощная команда разработчиков, квалифицированный QA и эксперты по исправлению ошибок.

Извините за длинный рассказ, но именно так наша команда (за 4 месяца) доказала руководителю и клиенту, что мы надежны и нам просто необходимы правильные условия.

Answer 3

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

Это роль тысер Апринятие Тесть:показать, что приемлемый уровень полезности достигнут.

Answer 4

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

К сожалению, совершенно невозможно «доказать», что ваше программное обеспечение работает без ошибок (рекламные ролики Windows XP всегда раздражали меня, объявляя «самую безопасную версию Windows за всю историю», это невозможно доказать при выпуске).Руководство должно настроить и обеспечить соблюдение процесса контроля качества, а также установить показатели того, как на самом деле выглядит готовый продукт и какой уровень ошибок или непредвиденного поведения приемлем в финальной версии.

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

Answer 5

Как однажды сказал Билли Джоэл, "Это всегда было вопросом доверия".

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

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

1. Видимость процесса - убедитесь, что все знают, что вы делаете и как продвигаются дела.Кроме того, убедитесь, что каждый может видеть влияние и изменения, которые происходят в процессе разработки.
2. Укажите на маленькие победы - чтобы укрепить доверие, укажите, когда все пошло именно так, как вы планировали.Попытайтесь найти ситуации, в которых вам приходилось принимать решение, и используйте термин "уменьшил риск" в отношении вашего руководства.
3. Не говорите: "Я же тебе говорил". - допустим, вы сказали руководству, что вам нужно 2 месяца для выполнения какой-либо задачи, а они говорят: "Ну, у вас есть только три недели". Результат вряд ли будет хорошим (при условии, что ваша оценка точна).Проинформируйте руководство о проблеме и задокументируйте все, что вам нужно было сделать, чтобы попытаться уложиться в срок.Когда качество оказывается низким, вы можете профессионально решить проблемы, с которыми столкнулись (и которые записали), вместо того чтобы показывать пальцем и говорить: "Я же вам говорил".

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

Кроме того, я хотел бы обратить внимание вашего босса на то, что отказ вам выступать в качестве профессионального разработчика программного обеспечения вредит вашей карьере.Вы действительно хотите работать где-то, что позволит вам расти профессионально, а не где-то, что превратит вас в хакера.