6911
правок
Изменения
Новая страница: «Как говорил на одном из докладов Максим Дорофеев: "ИТ - единственная область, где с костыл…»
Как говорил на одном из докладов Максим Дорофеев: "ИТ - единственная область, где с костылями быстрее, чем без них". А кроме костылей есть еще много других способов сделать быстрее. Например, опустить документацию, не делать тесты, не реализовывать побочные ветви процесса, которые сейчас все равно не понадобятся. В результате вполне работающий софт может появиться гораздо быстрее, особенно у опытного разработчика. Проблемы вскрываются потом, когда этот код надо сопровождать, дорабатывать, рефакторить. Вот тут-то выясняется, что никто не знает, как этот код работает и как он должен работать, является ли какое-либо поведение фичей или багом. Даже сам автор. Даже если он доступен, через полгода-год работы на другом проекте подробности вытесняются из памяти.
Для работы с этим в отрасли придумано такая конструкция, как '''технический долг'''. И когда встрече по [[Блог:Максима Цепкова/2015-11-13: Agile для государства - какое нужно регулирование|Agile для госпроектов]] в обсуждении в группах зашла речь об этих проблемах я бегло рассказал об этой практике. На уровне беглого рассказа это приняли, но потом некоторые участники у меня просили литературу, где бы это было описано подробнее. В литературе я не силен, поэтому переадресовал вопрос Алексею Пименову, но оказалось, что он тоже не знает хороших книг и смог вспомнить только доклад Антона Бевзюка на AgileDays-14 [http://msk14.agiledays.ru/members/profile/270/ Эй, программистик, за тобой должок!]
Я, в свою очередь, бегло посмотрел инет и тоже не нашел хороших материалов. В основном идут достаточно наивные рассуждения о том, что, дескать, глупые менеджеры не понимают высокие принципы технической эстетики, и потому надо переходить на их язык. Объяснить, что любой проект надо делать по-хорошему, а если он по каким-то соображениям делается не столь качественно, то, значит, это сделано не полностью, а с недоделками, эти недоделки, являются техническим долгом, их надо записывать и устранять. К сожалению, такие рассуждения плохо убеждают менеджеров,как и любые апелляции к чувству прекрасного. Особенно если безобразия и недостатки скрыты внутри, а снаружи все хорошо - софт-то работает.
Поэтому я и пишу данный пост.
Для работы с этим в отрасли придумано такая конструкция, как '''технический долг'''. И когда встрече по [[Блог:Максима Цепкова/2015-11-13: Agile для государства - какое нужно регулирование|Agile для госпроектов]] в обсуждении в группах зашла речь об этих проблемах я бегло рассказал об этой практике. На уровне беглого рассказа это приняли, но потом некоторые участники у меня просили литературу, где бы это было описано подробнее. В литературе я не силен, поэтому переадресовал вопрос Алексею Пименову, но оказалось, что он тоже не знает хороших книг и смог вспомнить только доклад Антона Бевзюка на AgileDays-14 [http://msk14.agiledays.ru/members/profile/270/ Эй, программистик, за тобой должок!]
Я, в свою очередь, бегло посмотрел инет и тоже не нашел хороших материалов. В основном идут достаточно наивные рассуждения о том, что, дескать, глупые менеджеры не понимают высокие принципы технической эстетики, и потому надо переходить на их язык. Объяснить, что любой проект надо делать по-хорошему, а если он по каким-то соображениям делается не столь качественно, то, значит, это сделано не полностью, а с недоделками, эти недоделки, являются техническим долгом, их надо записывать и устранять. К сожалению, такие рассуждения плохо убеждают менеджеров,как и любые апелляции к чувству прекрасного. Особенно если безобразия и недостатки скрыты внутри, а снаружи все хорошо - софт-то работает.
Поэтому я и пишу данный пост.