Information

Founded
Location
Россия
Website
otus.ru
Employees
51–100 employees
Registered
Pull to refresh
Comments 22
В корпоративном управлении есть достаточно жесткие административные ограничения систем контроля
Например члены ревизионной комиссии акционерного общества не могут занимать должности в органах управления обществом,
Аудитор и регистратор только внешние.

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

Это одна из причин плохого качества софта и его применения.

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

Это демагогический аргумент подмены тезиса на заведомо абсурдный, потому что вопрос не ставится как "как написать софт без багов", он ставится, например, как "можем ли мы написать софт со стабильно меньшим числом багов за те же деньги" или "сколько нужно денег и на что конкретно из потратить, чтобы уменьшить число багов до приемлемого (и какое число и степень серьезности приемлемы)".


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


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

Вы правы, но не совсем. Есть пример — был в статье о том, как писался софт для космоса в НАСА. Дорого и медленно. Но без багов.

А не об Марс ли разбился посадочный модуль из-за ошибки в расчётах (не верные единицы использованы были):
https://ru.m.wikipedia.org/wiki/Mars_Climate_Orbiter


Ошибки будут всегда. Нужно стремиться минимизировать от них ущерб.

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

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

Я не понимаю, с чем вы спорите. Да, процессом разработки, как и любым другим процессом, часто руководят идиоты, ставящие взаимоисключающие требования. Но вопрос не в том, как бывает, а в том, как сделать лучше. И сделать лучше, как раз, более всего возможно (технически) именно тогда, когда творится бардак, потому что на фоне бардака почти что угодно — лучше.

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

Очень спорно. Что бы вина всегда однозначно была на разработчике нужно ему ставить максимально детализированную задачу.
Постановка должна быть полной и не иметь разночтений.
Но это бывает только у сферических коней, да и то при условии абсолютного вакуума.
Очевидно, что обычным языком такую постановку не сделать. Значит надо воспользоваться более формализованными средствами — uml, например. Oh wait!..

Представьте себе, что вы разработчик. К вам приходит руководитель и говорит: «срочно нужно вставить в программу новую функцию А.Б.В. Времени в обрез. Проект горит, а также горят другие проекты, с которых мы вас снимаем ради этой функции».

Вы приняли задание, реализовали нужную функцию, но из-за спешки — коряво. Работает, но не очень надежно; чувствуется, что код хорошо бы переписать заново, начисто. Но руководитель доволен, его работа программы устраивает. Он принимает работу и, не оставляя вам времени на приведение кода в порядок, поручает вам следующее задание — такое же срочное.

А потом кто-то из клиентов попадает на ошибку в вашей программе. Подаёт на фирму в суд. Фирма подаёт регрессный иск к вам — ведь вы разработчик. И вы несёте ответственность. Хорошие перспективы?
Как вариант, надо воткнуть большой и развёрнутый TODO, объясняющий почему функция А.Б.В. реализована именно так, и как её нужно реализовать в будущем, в код, и оповестить всех остальных насчёт этого.

Ну что вы гиперболизируете? Следуя вашей логике, на того, кто отвечает за качество и кто бы это ни был, компания должна подавать в суд. Если отдел QA отвечает за качество, то компания на него должна подавать в суд? Сейчас же этого ни в одной компании не происходит. Ответственность действительно должен нести разработчик, но естественно не материальную, как вы описали. И такие ситуации, когда сроки горят, опытные разработчики сразу менеджера ставят в известность, что при такой постановке качество может пострадать. Грамотный менеджер либо поменяет сроки, либо возьмёт риски на себя. А с неграмотными лучше не работать

А потом кто-то из клиентов попадает на ошибку в вашей программе. Подаёт на фирму в суд.
Бесполезно. Практически в любом EULA написано примерно следующее: «Компания не несёт ответственности за убытки, причиненные использованием настоящей программы».
Проще говоря, если производственное качество, заключается в том, чтобы что-то работало, то продуктовое качество — это обеспечение того, чтобы оно работало должным образом.

Производственное качество — это качество процесса разработки.
Продуктовое качество — качество конечного продукта.

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

А если в двух словах — идейная ответственность за качество лежит в первую очередь на заказчике, который обеспечивает ресурсами (деньгами) свою идею.
А техническая — ответственность за качество программного обеспечения лежит на техлиде/архитекторе, качество разработки — на менеджере.
идейная ответственность за качество лежит в первую очередь на заказчике, который обеспечивает ресурсами (деньгами) свою идею.
Еще бы донести эту замечательную мысль до стейкхолдеров. :-) Но мысль as agile as it could get. Супер, снимаю шляпу, прекрасная формулировка!
Я понимаю что вопрос/комментарий не к переводу, а к первоисточнику, но меня сильно удивила цифра про «исследование, подтвердившее увеличение длительности проекта на 15-30% при использовании TDD». Оказалось, что это хороший пример ситуации, когда категорически не следует верить цитирующим, какими бы регалиями они не обладали, а искать первоисточник.

Первоисточник нашелся, это исследование Realizing quality improvement through test driven development: results and experiences of four industrial teams by Nachiappan Nagappan & E. Michael Maximilien & Thirumalesh Bhat & Laurie Williams, опубликованное Microsoft вот тут
www.microsoft.com/en-us/research/wp-content/uploads/2009/10/Realizing-Quality-Improvement-Through-Test-Driven-Development-Results-and-Experiences-of-Four-Industrial-Teams-nagappan_tdd.pdf

Интересно, что аннотации на самом сайте Microsoft это не совсем корректное «цитирование» про 15-30% повторяется почти слово в слово, но в работе мы видим нечто совершенно другое:

Прямо в абстракте: по субъективным ощущениям, время изначального написания кода увеличилось на 15-30%

Далее (стр 298), следом за таблицей 2, показывающей KPI команд после внедрения TDD, в статье говориться следующее, опять-таки категорически не совпадающее с «цитированием» в обсуждаемом тексте:
По субъективным оценкам менеджмента(sic!), время разработки выросло на 15-30%. Однако, это изменение будет компенсировано снижением эксплутационных расходов благодаря выросшему качеству. Этот эффект подтвержден практическими наблюдениями команд IBM и Microsoft.

К сожалению, далее, из некорректного цитирования исследования делаются выводы о «компромиссе между скоростью и качеством». В случае TDD этого «компромисса» просто нет, посколько вся «экономия» моментально съедается отладкой и интеграцией.

Компромисс между ценой/скоростью и качеством существует в совершенно другом измерении, но он не о «допустимом количестве багов». Он, скорее, о том что объем реализации требований во всем диапазоне FURPS+ сильно зависит от имеющегося времени и средств. Но есть принципиальная разница между требованиями или ожиданиями которыми пожертвовали для сокращения бюджета или сжатия сроков, и некачественным кодом. А работоспособность продукта, как и свежесть рыбы в известной цитате из Мастера и Маргариты, бывает только одна.

Особенно странно слышать это в контексте Agile, где, «только работающий продукт является измерением прогресса», и «постоянное стремление к техническому совершенству», и, в конце-концов, definition of done как ключевой элемент обеспечения прозрачности создаваемых артефактов.
Смотрю в статю от MS и очень слабо верится, что TDD снизило количество багов до 9% от дефектов другой сравномой команды в сравнимом проекте. Скорее всего сравнивают апельсины с яблоками.
Мои личные наблюдениям со статьей совпадают. У меня выборка не то что бы по которой можно двойное слепое провести, но пара-тройка десятков разных команд есть. Каждый раз внедренное TDD действительно резко сокращает и время на отладку, и количество дефектов, пробравшихся в production. Даже там где был вполне себе отстроенный классический QA.

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

Ну или еще бывает — «мы перешли на TDD, тестеры теперь не нужны, экономия, все ж программисты сделают». Ну да, их же учили стратегию тестирования строить, и времени у них на это вагон прям… Короче, главное не нарваться на реализацию которая описывается известной поговоркой про отправление духовных потребностей человеком с ограниченными умственными способностями. :-) Увы, среди эффективного менеджмента таких хватает, когда с MBAсами сталкиваешься.

На ком лежит ответственность?


На кого положили, на том и лежит. Всë остальное — шаманство и отклонение от договорëнностей/подразумеваний.

Кто взял отвественность — тот её и несёт. А остальном — рыночек порешает.
Only those users with full accounts are able to leave comments. Log in, please.