Управление техническим долгом - Концепция Continuous Inspection

Публикация № 622617

Разработка - Практика программирования

92
Сегодня я вам хочу рассказать про тему «Управление техническим долгом» – что это такое, как с этим бороться и почему с этим надо бороться.

Для кого эта статья?

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

  • Так как источником технического долга у нас являются разработчики, то им это будет полезно в первую очередь.
  • Также руководителям проектов или руководителям продуктов будет полезно вынести из статьи какие-то темы, которые можно воспринять, как руководство к действию.
  • А в случае, если той концепцией, про которую я сегодня расскажу, станут пользоваться заказчики, они получат эффективный инструмент мониторинга и контроля над разработкой программного обеспечения для себя.

Что такое Технический долг?

Есть такое каноническое определение, что технический долг – это работа, оставленная «на потом».

  • Это может быть какая-нибудь плохо спроектированная архитектура, слабоструктурированный или слишком запутанный код. На момент, когда мы его написали, мы понимаем, что это такое, но остается ощущение, что что-то здесь не так и что-то надо исправить.
  • Условно, с точки зрения разработчика, количество технического долга при просмотре некачественного кода можно охарактеризовать, как количество воскликов «Что же здесь происходит?» в час.
  • Очень часто, когда разработчики разбираются в сложном и запутанном коде, они долго не могут понять, что делает этот код, и тратят свое время на повторное укладывание в голове происходящего. Тем самым, тратят свои (и заказчика) деньги. Примерно посчитав, сколько времени тратит разработчик на каждый такой случай, мы можем определить общий объем технического долга в часах и перевести его в деньги, например, умножив на часовую ставку программиста.

Зачем управлять техническим долгом?

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

Игра «в долгую»

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

  • Синяя команда (с синим графиком) не следит за своим техническим долгом, не считает его, и в короткой перспективе может быстро реализовывать новую функциональность и быстрее приносить пользу бизнесу (так называемый Time to Market).
  • А оранжевая команда с самого начала своей работы пытается следить за тем, насколько качественно она разрабатывает, устраняя утечки своего технического долга параллельно с выпуском новой функциональности.

В долгосрочной перспективе наступает такой момент, когда:

  • Команда, которая не следила за качеством, попадает в ситуацию снижения производительности из-за накопившихся в процессе разработки ошибок – время у нас идет, а количество новой, полезной функциональности не увеличивается.
  • Оранжевая же команда, изначально следившая за своим качеством разработки, планомерно, в том же самом темпе, в котором и начинала, продолжает наращивать функциональность.

Семь смертных грехов разработчика

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

Первый смертный грех, который могут допускать разработчики, это – ошибки и потенциальные ошибки.

  • Например, это могут быть ошибки проектирования, заключающиеся к неправильной реализации той функциональности, которую от нас хочет бизнес.
  • Либо это могут быть какие-то ошибки в коде, которые приводят к «страшным красным надписям» при работе заказчика.
  • Либо в коде могут оставаться какие-то потенциальные ошибки – непротестированные участки, которые на данный момент времени из-за текущих настроек системы не вызываются, но в будущем, при изменении бизнес-процессов этот код начнет выполняться, и пользователи уже потом будут получать эти «красные надписи».

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

Самый распространенный вариант уязвимости в коде 1С – это выполнение строки кода, заданной в качестве параметра экспортной процедуры, которую можно вызвать из любого места системы (чаще всего даже подключившись через COM). Например:

		
	

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

Второй смертный грех – это нарушение стандартов разработки.

  • К сожалению, мало кто из разработчиков знает, а еще меньше применяет стандарты разработки, рекомендованные компанией 1С. Они опубликованы на ИТС – там довольно большой раздел, в котором описано, как правильно писать код, причем не только с эстетической точки зрения, но и для того, чтобы его потом было проще поддерживать и дорабатывать.
  • Помимо общепринятых стандартов, поставляемых вендором, у команды разработки могут быть свои внутренние стандарты кодирования. Если они у вас есть, то им тоже нужно следовать. Иначе, когда ваши партнеры по команде будут разбирать ваш код, им будет менее комфортно с ним работать, и они опять-таки, будут тратить на это больше времени.

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

Третий смертный грех – это дублирование кода.

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

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

Четвертый грех – это недостаток тестирования.

  • Если вы не пишете автоматические тесты или не прогоняете ручные по какому-то заранее сформированному комплекту проверок, это приводит к тому, что вы не понимаете, насколько ваша система надежна и насколько безопасно вы можете изменять те или иные участки кода. Потому что опять-таки, программисты – люди не идеальные и при доработке функциональности они могут внести новые ошибки, сломав, таким образом, что-то, что работало раньше. Это приведет к регрессии системы.

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

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

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

Показатель здесь – это сложность системы. Его тоже можно посчитать.

Помимо сложности кода у нас еще есть сложность самой архитектуры.

Если вы используете какое-то многомодульное приложение (а 1С – это, условно говоря, трехкомпонентная система, состоящая из: визуальной части; серверной части, за которую отвечает сервер приложения; и непосредственно СУБД), и у вас в коде смешана работа с разными компонентами, то модифицировать все это потом будет опять-таки сложнее.

Показатель здесь тот же самый, это – сложность.

И седьмой смертный грех – это недостаток или излишнее количество комментариев.

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

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

Зачем нужны показатели качества кода?

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

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

Какие есть подходы к управлению техническим долгом?

Я назову четыре. Я думаю, с первыми тремя из них вы более-менее знакомы.

  • Первый подход – это контроль качества внешними аудиторами. Вы можете разрабатывать конфигурацию, потом собрать этот cf-ник, отдать его в какую-то внешнюю компанию с громким названием (обычно, с фамилиями) – они будут долго и упорно смотреть на ваш код, а потом сформируют вам огромный отчет по поводу недостатков вашей конфигурации. Этот подход имеет право на жизнь, но он имеет минусы, о которых я расскажу чуть позже.
  • Второй подход – это визуальная проверка кода разработчиками (или code-review). Обычно у нас есть некий абстрактный стажер, и наставник, который дает этому стажеру задачу. Стажер задачу решает, приносит код своему наставнику, тот смотрит на этот код и дает своему стажеру некую обратную связь. Если вы пользуетесь какими-то более сложными, чем хранилище, серверами по контролю версий (например, Github, Gogs или Gitlab), то у вас есть возможность точечного просмотра измений каждого помещения (коммита) или формировать запросы на слияние кодовой базы, где разработчики могут более подробно и более детально изучать, какие же были изменения в вашем коде.
  • Третий подход – это разовые автоматизированные отчеты о качестве кода. Например, у вас есть некая система, в которую вы загружаете весь свой код, она вам долго-долго его анализирует, а потом опять-таки выдает огромный отчет. Вы смотрите на этот отчет, но так как у вас перед этой системой нет никаких обязательств, и вы ее запустили именно разово, для того, чтобы увидеть, насколько у вас все плохо, то чаще всего, вы откладываете этот отчет в дальний ящик стола и продолжаете кодировать дальше.
  • А четвертый подход – это непрерывная инспекция. Именно о ней я и собираюсь рассказать чуть подробнее.

Continuous Inspection – ключевые принципы

Что же вообще такое Continuous Inspection (непрерывная инспекция кода), какие у нее ключевые принципы и из чего она состоит?

  • Основной ее постулат заключается в том, что качество – это общая задача всей команды разработки и результат выполнения этой задачи зависит непосредственно от самих разработчиков, потому что они производят код, за который несут ответственность.
  • Второй ключевой принцип – это актуальность информации. Если мы проверяем нашу систему и получаем о ней какие-то качественные показатели, мы должны их получать регулярно, чтобы у нас под рукой всегда была актуальная информация о текущем состоянии нашей кодовой базы.
  • Данные о качестве (как показатели, так и какие-то списки замечаний), мы должны получать не только в абсолютных значениях, но и в разностных. Мы должны понимать, а что же у нас изменилось за неделю с выхода прошлой версии, за день и т.д.
  • Проверка качества должна быть автоматизированной, и мы в идеале должны исключить каких-то конечных людей (внешних аудиторов либо самих разработчиков в плане ручного code-review), чтобы проводить эти проверки автоматически.
  • И еще один ключевой принцип – стандарты качества должны быть едиными для всех проектов. Часто бывает ситуация, когда какая-то команда уже 8 лет внедряет УПП, а теперь начала внедрять УТ 11 на управляемых формах. И в головах возникает такое отношение – проекту по УПП уже 8 лет, 1С этот продукт уже давным-давно не поддерживает, там уже в принципе все плохо и за его качеством можно не следить. А вот для УТ 11 в плане контроля качества еще можно что-то сделать, поэтому следить будем только за ним. Это – неправильно. Не смотря на то, что УПП – это система, которая разрабатывается давным-давно, стандарты качества к ней точно такие же. Просто здесь на первый план выходят не абсолютные показатели (когда мы знаем, что за 8 лет разработки у нас накопилось 10 лет технического долга), а именно относительные – когда мы разрабатываем новую версию функциональности, мы должны быть уверенными в том, что мы ее сделали качественно.
  • Последний ключевой принцип – это то, что все новые замечания, особенно критические, должны иметь ответственного. И если у нас несколько человек в команде, то каждое выявленное замечание по качеству должно относиться на конкретного разработчика. Может быть, он уже уволился – это неважно, но в принципе, мы должны понимать, кто привел к конкретной проблеме.

Сравнение подходов.

Аудит, если он проводится вручную, и код-ревью имеют под собой некий человеческий фактор.

  • Люди чаще всего имеют склонность пропускать какие-то замечания, у них может «замылиться» глаз. Аудиторы на этой ниве работают уже много лет, они какие-то моменты могут случайно упустить, и в результате мы, выполняя задачу контроля качества, можем не получить полную картину того, что у нас происходит.
  • А в случае применения неких автоматизированных систем (либо разово, либо в непрерывном варианте), влияние человеческого фактора уходит, потому что все эти проверки проводятся автоматически, и код у нас анализируется на основании каких-то алгоритмов.

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

  • Чаще всего аудит выполняется долго, и пока отчет не готов, мы продолжаем разрабатывать. Когда мы этот отчет получаем, у нас уже и код поменялся, и состав модулей другой. Получается, что та конфигурация, которую изучал аудитор, и то, что у нас в кодовой базе сейчас – это в принципе, два разных программных продукта.
  • С код-ревью получше, он производится либо в момент сдачи функциональности, либо в момент влития изменений в основную ветку, поэтому там с актуальностью все более-менее хорошо.
  • И разовые проверки (в случае, если вы сразу исправляете свой код) также могут быть полезны. А если вы откладываете их исправление «в долгий ящик» – пользы не будет.
  • Continuous Inspection предполагает частую автоматическую проверку вашего кода. Причем, когда я говорю «частую», это не значит, что раз в неделю или раз в месяц. Проверяется каждое ваше изменение при помещении в хранилище, либо коммит в Git (если вы пользуетесь системой контроля версий). И на каждое изменение вы получаете отчет о качестве.

Следующая проблема заключается в том, что аудит имеет свойство некоего психологического давления на команду разработки.

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

То же самое касается распределения ответственности.

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

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

Также для всех перечисленных разовых подходов характерно отсутствие динамики.

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

Что такое Continuous Inspection с точки зрения разработки?

Каждый день каждое изменение в хранилище должно сопровождаться результатами контроля качества.

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

Второй вариант – если вы используете Git-flow и Pull-request (программисты знают, что это такое), то можно оценивать и сами изменения кода – только то, что поменялось в конкретном предложении на влитие в основную ветку. И тоже получать об этом отчет.

Результаты анализа должны быть инкрементальны не только относительно вашего текущего изменения, но и от последнего релиза вашего продукта. На данном слайде вы видите в левой части количество зафиксированных ошибок, а посередине (где написано «Новые ошибки», «Новый некачественный код») – именно то, что у нас изменилось с прошлой версии. Это – уже инструмент для релиз-менеджера, чтобы он мог видеть, что же у нас происходит с кодовой базой и насколько наш релиз готов к выпуску. В данном случае, вы видите рейтинг надежности E (наихудший). Это потому, что одна из этих 18-ти новых ошибок – блокирующая, и ее нужно срочно исправить.

Каждое замечание должно иметь ответственного.

Мы должны иметь возможность посмотреть общий список зафиксированных ошибок, чтобы понять, что у нас происходит в системе. Заметьте, здесь каждая ошибка назначена на конкретного человека: что-то на меня, что-то на уважаемого Алексея Лустина и т.д.

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

Так как проверки кода у нас автоматизированы, мы можем сразу накапливать некую информацию не только о том, что у нас плохо, но и почему это плохо, предоставляя методические материалы о том, как это нужно исправить, со ссылкой на те же самые стандарты ИТС. Здесь в нижней части скриншота как раз и представлен текст с ИТС об этой конкретной ошибке.

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

Скриншот с техническим долгом проекта я вам уже показывал, а это – его расширенная версия. Здесь на средней полоске как раз виден график тренда увеличения или уменьшения нашего технического долга.

Важной концепцией для релиз-менеджера является порог качества. В качестве него мы можем настроить некоторые очень объективные показатели.

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

И последнее, что я хочу сказать – это то, что список наших ошибок в идеале мы должны получать еще на этапе кодирования, до того, как мы поместили наши изменения в хранилище. В других языках такие вещи уже давно поддерживаются на уровне редакторов кода, а для 1С такие инструменты только начинают появляться. Например, это есть в Eclipse, на базе которого построен EDT, а теперь такие инструменты появились и для VSCode.

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

***************

Данная статья написана на основе доклада, представленного автором на конференции Infostart в 2016 году. Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.

 

92

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. vano-ekt 526 30.06.17 09:05 Сейчас в теме
Что такое Технический долг?

как изящно слово "**внокод" завуалировали :-D
wowik; Vladimir Litvinenko; Berckk; Brawler; sorb; корум; Lem0n; artbear; Bazil; +9 Ответить
2. Артано 663 30.06.17 09:55 Сейчас в теме
(1) Речь не только о говнокоде, а в принципе о копро-методах в разработке. В известном мультике это обозначали фразой "и так сойдёт"
wowik; Vladimir Litvinenko; Brawler; корум; nixel; +5 Ответить
3. nixel 796 30.06.17 09:55 Сейчас в теме
(1) для *овнокода есть изящный "code smells" :)
Когда мы делали плагин локализации SonarQube, очень долго думали, как же его перевести эээ... по-корректнее :) и чтобы в интерфейсе легло
4. Stepa86 1256 30.06.17 10:15 Сейчас в теме
Все таки истина посередине. Действовать нужно согласно ситуации и выгодам. Для написания одноразовой обработки нет смысла задумываться над качеством, а при старте огромного проекта не очень хорошо сразу кидаться херачить код. И в больших проектах есть одноразовые вещи, в которых есть смысл повышать качество только если они перестают быть одноразовыми.

Ну и график сравнения команд не очень верный. У синей команды должен быть более быстрый старт, но в концовке линия может даже пойти вниз и закончиться регрессионной спиралью смерти, а у оранжевой наоборот более долгий старт, но потом производительность растет лучше, чем линейно, скорее квадратично
Артано; sulfur17; +2 Ответить
5. v3rter 30.06.17 10:54 Сейчас в теме
Законы ненадежности Джилба.

1. Компьютеры ненадежны, но люди еще ненадежнее.
2. Любая система, зависящая от человеческой надежности, ненадежна.
3. Число ошибок, которые нельзя обнаружить, бесконечно, в противовес числу ошибок, которые можно обнаружить,- оно конечно по определению.
4. В [исправление *%вн0к0да] поиски повышения надежности будут вкладываться средства до тех пор, пока они не превысят величину убытков от неизбежных ошибок или пока кто-нибудь не потребует, чтобы была сделана хоть какая-то полезная работа.

Законы Мерфи. Законы машинного программирования

1. Внутри каждой большой программы есть маленькая, которая там совсем не нужна.
2. Все ошибки, описанные как особенности [фичи], в момент сдачи программы не сработают или будут вести себя, как ошибки.
3. Все программы содержат ошибки, просто о некоторых мы не догадываемся.
4. Если Вы заводите в компьютер ерунду, то ничего кроме ерунды оттуда не выходит, только прошедшая через обработку такой умной машиной ерунда становится ценной и значимой.
6. Если Вы точно не знаете, что ваша программа должна делать, надо ли ее начинать?
7. Если программа бесполезна, она будет документирована. Если программа полезна, ее изменят.
8. Если программа полностью отлажена, ее нужно будет скорректировать.
10. Компьютерам свойственно ошибаться, но людям свойственно делать это намного чаще
11. Любая, даже самая гениальная программа никогда не работает в момент сдачи ее заказчику.
12. Любая действующая программа устарела.
13. Любая программа обходится дороже и требует больших затрат времени, чем предполагалось.
14. Любая программа стремится занять всю доступную память.
15. Мощность компьютера увеличивается как квадрат цены. Таким образом, если Вы хотите сделать ваш компьютер в два раза дешевле, Вам нужно сделать его вчетверо быстрее.
16. Неопределимые ошибки бесконечны, а определимые ограничены способностями компилятора.
19. Работа с автоматическим исправителем ошибок приведет к обнаружению его узких способностей и широких недостатков.
22. Сложность программы растет до тех пор, пока не превысит способности программиста.
23. Программы тестирования обязательно находят ошибку там, где их нет. Если ошибка все-таки есть то она в другом месте (например, на 5-10 символов выше, за границей экрана).
24. То, что некоторые пользователи зовут в программе, пользуясь ей, ошибкой, на самом деле является особенностью [фичей].
25. Усилия, прилагаемые для исправления ошибки, увеличивают ее в геометрической прогрессии по отношению к затраченному времени.
26. Ценность программы прямо пропорциональна весу ее "выдачи".
27. Чем более сложна и совершенна программа, тем более неточные результаты она выдает.

Первая компьютерная аксиома Лео Бейзера.
Закладывая что-то в ЭВМ, помните, куда Вы это положили.

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

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

Второй закон Вейнберга.
Если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию.
Показать
rusmil; weissfeuer; +2 Ответить
6. starik-2005 1962 30.06.17 13:15 Сейчас в теме
+ чисто за воспоминание о теме. Не читал, но... )))
7. nixel 796 30.06.17 13:37 Сейчас в теме
8. brr 177 30.06.17 15:26 Сейчас в теме
Условно, с точки зрения разработчика, количество технического долга при просмотре некачественного кода можно охарактеризовать, как количество воскликов «Что же здесь происходит?» в час.


Другие восклики раздаются
9. nixel 796 30.06.17 15:54 Сейчас в теме
(8) во время доклада на слайде в этот момент отображалась строчка "WTF?/hour" :)
10. CSiER 27 01.07.17 05:09 Сейчас в теме
Хорошая статья. Просьба добавить ссылки на инструментарий и мануалы по настройке всего этого в контексте 1С.
wowik; sulfur17; +2 Ответить
11. Makushimo 154 03.07.17 06:00 Сейчас в теме
читаю статью и не дает покоя мысль "где-то в параллельной вселенной: в 1С управляют техническим долгом... автоматический контроль качества кода..."

жаль, что я не в вашей команде...
sulfur17; artbear; +2 Ответить
12. &rew 7 03.07.17 06:12 Сейчас в теме
Статья интересная, и поэтому вызывает вопросы:
1. "Самый распространенный вариант уязвимости в коде 1С ... Например:
Процедура ВыполнитьКод(ПроизвольнаяСтрока) Экспорт Выполнить(ПроизвольнаяСтрока); КонецПроцедуры
Наличие такой уязвимости в худшем случае может привести к очистке всех данных и полному разрушению базы – это очень плачевно скажется на бизнесе. "

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

2. "К сожалению, мало кто из разработчиков знает, а еще меньше применяет стандарты разработки, рекомендованные компанией 1С. Они опубликованы на ИТС – там довольно большой раздел, в котором описано, как правильно писать код, причем не только с эстетической точки зрения, но и для того, чтобы его потом было проще поддерживать и дорабатывать."

Включая саму фирму 1С. Глядя в типовые конфигурации сейчас очень легко запутаться, какие данные откуда берутся (например при работе с Хранилищем). Переменные очень часто не информативны. Избыточные "перескоки" между процедурами, функциями и фоновыми заданиямиФоновые задания тогда тоже можно отнести к "самым распространенным уязвимостям". Дублирование кода тоже имеется. И всё это в типовых! конфигурациях.
.......
sulfur17; Makushimo; +2 1 Ответить
13. ifilll 03.07.17 14:19 Сейчас в теме
(12) Андрей +

Правда "перескок" чаще объясним особенностями реализации БСП или отклонения от него в конкретном случае.
Модули продуктов разрабатываются разными командами программистов, где могут преследоваться локальные условности, либо недоговоренности с другими командами.

Но в целом вы правы, ИМХО конечно.
14. chng 07.07.17 11:48 Сейчас в теме
(12)
А вообще перед внесением изменений + ежедневно хотя бы раз в день бэкапы уберегут бизнес от простаивания

Эта фраза верна только до определенного размера бизнеса...
15. &rew 7 10.07.17 08:05 Сейчас в теме
(14)Вы знаете, любое утверждение верно только до конкретных значений элементов объектной природы. Мне кажется, что вы в курсе как именно уберечь обслуживаемый Вами бизнес.
Кстати, как там аукцион по 1С по присоединению вновь обретенных мощностей? Выполнили? (простите за моветон)
16. sulfur17 17.07.17 10:14 Сейчас в теме
Восхитительно! Добавил в избранное и очень надеюсь на развитие этой темы (ссылки на скачивание, мануалы). Один проект уже пришлось бросить из за чрезмерного тех.долга, хотелось бы научиться с этим бороться.
Оставьте свое сообщение

См. также

Незакрытый проект на 1000 часов 62

Статья no Нет файла Россия Бесплатно (free) Управление проектом

История о незакрытом проекте, о бессонных ночах, о попытках его выгрести, о бесплатной работе, о вселенской боли.

19.09.2019    6929    ogroup    153       

Стратегия выживания в корпоративных войнах 47

Статья no Нет файла Бесплатно (free) Управление проектом

Айтишникам сложно строить карьеру управленца. И все потому, что в их «техническое ДНК» не заложено умение справляться с окружающими их интригами. Однако, поскольку это навык, это можно исправить, считает ИТ-директор в ПАО «Светлана». На конференции Infostart Event 2018 он поделился с коллегами, что и как надо делать, чтобы не погрязнуть в корпоративных интригах и сделать так, чтобы они не мешали выполнению основной работы.

16.09.2019    4099    GSoft    14       

Мастер-класс СППР 39

Статья Программист Руководитель проекта Нет файла Бесплатно (free) Управление проектом СППР

Сергей Наумов, в прошлом разработчик подсистемы бюджетирования в конфигурации «1С:ERP», на мастер-классе конференции INFOSTART EVENT 2018 EDUCATION поделился опытом управления проектами с помощью «1С:Системы проектирования прикладных решений» и показал, как использовать эту программу в работе над разными задачами: для сбора, классификации и хранения требований; для управления разработчиками и консультантами; в качестве системы документирования; в качестве баг-трекера на этапе опытно-промышленной эксплуатации.

30.08.2019    3272    SergeyN    4       

Как заработать миллион или История успешного сотрудничества 45

Статья Программист Нет файла Бесплатно (free) Управление проектом

Многие мечтают один раз что-то создать, а потом жить на заработанные деньги до конца своих дней. Но миллионерами становятся не все, их единицы. Среди них – разработчик Андрей Карпов. Человек, который сумел за полтора года заработать 2 миллиона рублей чистой прибыли, поделился с гостями конференции Infostart своими секретами.

05.08.2019    4097    karpik666    77       

Управление качеством кода 126

Статья Программист Руководитель проекта Нет файла v8 Бесплатно (free) Математика и алгоритмы Рефакторинг и качество кода

О SonarQube, АПК, EDT. Какие преимущества дает их использование. Для каких команд подходит.

22.07.2019    6956    Stepa86    23       

Бизнес-аналитика с помощью Power BI 65

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

11.07.2019    6356    pbazeliuk    18       

Интеграция сценарного тестирования в процесс разработки 81

Статья Программист Нет файла Бесплатно (free) Практика программирования Разработка

Разработчик системы «Тестер» Дмитрий Решитко в своем докладе на конференции INFOSTART EVENT 2018 EDUCATION показывает, что процесс тестирования можно очень плотно интегрировать в процесс разработки, что внедрение тестирования – это возможность развития программиста как такового, позволяющая ему упорядочивать ход мыслей и оставаться «в фокусе». Навыки построения процесса кодирования на стыке с тестированием сокращают время на концентрацию, освобождают от страха перед изменениями и улучшают память разработчика.

08.07.2019    4429    grumagargler    7       

Управляй качеством кода 1С с помощью SonarQube 220

Статья Программист Нет файла Россия Бесплатно (free) Практика программирования Разработка

Управляй техническом долгом проектов 1С с помощью SonarQube. В статье рассматривается пример применения SonarQube при разработке.

07.07.2019    16103    olegtymko    191       

Управление проектами по автоматизации бюджетирования 35

Статья Бизнес-аналитик Руководитель проекта Нет файла УУ Финансовый учет и бюджетирование (FRP) Бесплатно (free) Управление проектом

Автоматизация бюджетирования позволяет максимально эффективно планировать ресурсы предприятия и управлять масштабированием компании. Как учесть особенности бюджетирования, встроить его в процессы стратегического планирования, чтобы получить гибкий инструмент управления и аналитики, рассказал Сергей Наумов на конференции INFOSTART EVENT 2018 EDUCATION.

28.06.2019    3194    SergeyN    1       

Путь джедая в управлении проектами 1С: умение быть, а не казаться 36

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Чем руководитель проекта “на бумаге” отличается от “настоящего” руководителя проекта, умеющего направлять команду и выдавать ценный результат?

15.04.2019    6764    MariaTemchina    15       

Управление ИТ-проектами, базовый курс, 3 поток. Онлайн-курс с 15 мая по 1 июля 2019 16

Курс Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Отличительная черта курса - органичное сочетание трех вещей: - Теория проектного управления (PMI®+Agile Alliance+Российские ГОСТ+Методологии от 1С)  - Опыт внедрения продуктов 1С (опыт франчайзи и успешных компаний + тренды Infostart Event и Agile Days) - Разбор реальных проблем и рекомендации экспертов по проектам слушателей Мы будем фиксироваться на тех инструментах, которые реально оказываются полезными в практике  руководителей проектов внедрения. 

04.04.2019    9257    infostart    18       

О времени и 1С 206

Статья Программист Нет файла Бесплатно (free) Практика программирования Разработка

Основы и особенности работы со временем в 1С. Как избавиться от боли при работе в разных часовых поясах. Что такое момент времени. И другое.

01.04.2019    15223    YPermitin    58       

Быстрее чем INSERT! BULK-операции и примеры использования 112

Статья Системный администратор Программист Нет файла Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка Внешние источники данных Перенос данных из 1C8 в 1C8

Microsoft SQL Server поддерживает так называемые BULK-операции, используемые для быстрого изменения больших объемов данных в базе. В статье пойдет речь о практических примерах их использования. Все примеры сделаны в контексте платформы 1С (а как иначе).

09.03.2019    9756    YPermitin    38       

Как писать понятные коммиты 67

Статья Программист Нет файла Россия Бесплатно (free) Практика программирования Разработка

Как писать сообщения коммитов так, чтобы потом не было мучительно больно.

06.03.2019    7827    Scorpion4eg    34       

20 мыслей об ИТ-проектах. Мысль №2. "С какой стороны подойти к новому проекту?" 38

Статья Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Продолжаем серию статей из цикла “20 мыслей об ИТ-проектах”. Сегодня мы поговорим о том, с какой стороны подойти к новому проекту. Такой вопрос возникал у каждого, кому приходилось выступать в роли руководителя проектов, особенно первый раз. Да и для опытных РП некоторые проекты вызывают аналогичный вопрос.

13.02.2019    4419    chavalah    22       

Бизнес, не горюй 33

Статья no Нет файла Бесплатно (free) Управление проектом

Про цели автоматизации.

04.02.2019    5772    1c-intelligence    64       

Ошибки управленцев: как топ-менеджеров убивает перфекционизм 5

Статья no Нет файла Бесплатно (free) Управление проектом

В преддверии онлайн-конференции «Гнев и слезы руководителя» мы решили заранее познакомить нашу аудиторию со спикерами, причем сделать это через видео-истории. Начнем с видео-приглашения от Миланы Джиджоевой и ее виденья диджитализации рекрутинга в России.

24.01.2019    6139    user809424    11       

20 мыслей об ИТ-проектах. Мысль №1. "О незаменимых людях" 62

Статья no Нет файла Бесплатно (free) Управление проектом

Этой статьей начинается цикл из 20-ти обещанных мыслей об ИТ-проектах. Надеюсь, что по прочтении кто-то посмотрит на проблему незаменимых людей с другой стороны.

10.01.2019    8973    chavalah    123       

Где мы взяли флакон? 38

Статья no Нет файла Бесплатно (free) Управление бизнес-процессами (BPM) Управление проектом

История появления и развития методики

26.12.2018    6197    1c-intelligence    7       

Озарение после прочтения макулатуры по проектному управлению 42

Статья Бизнес-аналитик Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Открываю этой публикацией мини-рубрику "Письма в редакцию". По мотивам очередной статьи на Инфостарте пришло мне письмо на корпоративную почту. Прямо-таки, крик души. С разрешения автора, решила опубликовать публичный ответ. Ибо согласна с автором письма, пишущим: "Я уверен, что не я один такой убогий, кто задается подобного рода "идиотскими" вопросами, но при этом почему-то все молчат, видимо, pmbok с agile-ом поистине творят чудеса молчания..."

19.12.2018    6473    MariaTemchina    24       

20 мыслей об ИТ-проектах, или 20 лет спустя. 53

Статья no Нет файла Бесплатно (free) Управление проектом

В этой серии из 20-ти статей я готов поделиться своей практикой управления проектами. Примеры, опыт и только то, что проверено лично. Выбираем темы голосованием!

09.12.2018    5940    chavalah    119       

Памятка руководителя: не играйте с деньгами 83

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом Личная эффективность Управление персоналом (HRM)

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

05.12.2018    13242    andironenko    128       

Шаг назад и ... шаг назад (классификация внутренних проектов) 34

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

03.12.2018    5517    capitan    26       

1С + asterisk (автоматический обзвон) часть 1 38

Статья Системный администратор Программист Нет файла Россия Бесплатно (free) Практика программирования WEB Телефония, SIP

Пример реализации автообзвона (с обработкой ответа на отвечающей стороне) с использованием ami asterisk. Данная статья может быть полезна программистам, интеграторам, администраторам. Версия и релиз технологической платформы не имеет значения.

29.11.2018    7241    dmarenin    9       

Памятка руководителя: Будьте оптимистичным или на крайний случай злым 46

Статья no Нет файла Бесплатно (free) Блоги Управление проектом

Следующая статья из цикла Управление персоналом - в этот раз предлагаю обсудить вопросы психологии управления и подчинения. Для тех, кто начинает читать этот цикл с этой статьи, вот ссылка на прошлый материал https://infostart.ru/public/937923/, в конце статьи будут ссылки на все статьи из серии «Памятка руководителя» - читатели просили. Итак, продолжаем работать с персоналом.

22.11.2018    8907    andironenko    43       

Роевой интеллект (Swarm intelligence) как метод управления проектами (анти-утопия) 35

Статья no Нет файла Бесплатно (free) Управление проектом

Так уж получилось, что на сайте я представляю средний класс. А именно программистов и сисадминов, работающих не у франчайзи и не на фрилансе, а в обычных ИП, АО, ООО, и т.п., основная деятельность которых, никаким образом с производством программных продуктов не связана. Посему все удивительные рассказы Марии Темчиной про Agile это как анекдот...

19.11.2018    6282    capitan    41       

Почему внедрение ERP-системы не приносит пользы бизнесу? 87

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Интеграция Управление проектом

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

15.11.2018    15706    rossoxa    62       

Памятка руководителя: В одиночку здесь не выжить 43

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом Личная эффективность

Продолжаю цикл материалов, в котором рассказываю о своем опыте работы в качестве директора по ИТ. Этот материал будет посвящен теме управления персоналом.

07.11.2018    9255    andironenko    62       

Памятка руководителя: Уволь HRа и найди себе хороших сотрудников 67

Статья Руководитель проекта Нет файла Управление персоналом (HRM) Бесплатно (free) Управление проектом

Продолжаю цикл «Памятка руководителя». Эта статья будет на тему поиска новых сотрудников и одной грубой ошибки при проведении собеседования.

29.10.2018    8909    andironenko    35       

Опыт внедрения ESB (интеграционной шины) в ПАО "Газпром нефть" 34

Статья no Нет файла Бесплатно (free) Управление проектом

Харитонов Михаил описывает проект по внедрению интеграционной сервисной шины предприятия (ESB) «2iS:Интеграция» на платформе “1С:Предприятие 8” в компании ПАО «Газпром нефть». Проект уникален тем, что это – первое решение, использующее отечественное ПО в качестве полноценной интеграционной шины для столь крупного заказчика с обширным ИТ-ландшафтом. В статье подробно рассмотрена архитектура решения, способы тестирования и масштабирования.

17.10.2018    7353    Mick2iS    8       

Развитие 1С программиста 51

Статья Программист Нет файла Бесплатно (free) Практика программирования Личная эффективность

Делюсь своим опытом и видением развития 1С программиста.

17.10.2018    13558    pashamak    62       

#БезОценок, или Как перестать беспокоиться об оценке проекта, всегда успевать в срок и укладываться в бюджет 32

Статья Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Считается, что для планирования и принятия решений по проектам их нужно прогнозировать и оценивать. Александр Белов, генеральный директор и руководитель проектов ГК «Белов и партнеры», рассказывает, почему стоит отказаться от оценок.

11.10.2018    5240    AlexWhite    7       

Построение высокоэффективной Agile-команды 34

Статья no Нет файла Бесплатно (free) Управление проектом

Меня зовут Асхат Уразбаев, я из компании ScrumTrek. Наша компания помогает внедрять Agile, Scrum, Kanban – гибкие методологии и гибкие подходы. К миру 1С я совсем не принадлежу, но в прошлом я, тем не менее, программист – занимался разработкой на самых разных языках программирования. Помимо основной деятельности у меня было несколько технологических стартапов, в которые я был так или иначе вовлечен. И сегодня мы поговорим о том, как сделать так, чтобы команда была крутой и эффективной.

08.10.2018    5225    askhatu    15       

История одного провала внедрения 1С:ERP 2 по классической технологии. С последующим спасением по Scrum 106

Статья no Нет файла Бесплатно (free) Управление проектом

Статья описывает успешный опыт реализации проекта после перехода от классической технологии «каскада» к методологии Scrum. Автор приводит примеры конкретных инструментов для построения эффективных коммуникаций в команде, ведения технической и пользовательской документации, реализации Scrum-доски, проведения стендапов и т.д. Также в статье даются рекомендации для тех, кто хочет научиться применять Scrum в своей деятельности.

01.10.2018    13349    glebushka    41       

Контракты Agile: как заключать договора в условиях расползания содержания 41

Статья Системный администратор Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

В большинстве проектов, реализуемых при помощи гибких методологий, точное содержание продукта невозможно выяснить на этапе инициации. Отсюда и возникает крик души руководителей проектов – «Как можно заключить контракт, не понимая точный бюджет проекта?» В статье я попробую рассмотреть этот вопрос с двух сторон: рекомендации от идеологов Agile и опыт реальных практиков. 

25.09.2018    6828    MariaTemchina    10       

Как из разработчика сделать руководителя, даже если он этого не хочет? 70

Статья no Нет файла Бесплатно (free) Управление проектом

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

06.09.2018    8930    galina.petuhova_2015    40       

Что такое Agile mindset или, говоря по-русски, пронырливый образ мысли 47

Статья Системный администратор Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

04.09.2018    10474    MariaTemchina    57       

Как собрать исчерпывающие бизнес-функциональные требования в начале проекта внедрения? 57

Статья Системный администратор Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

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

29.08.2018    9577    MariaTemchina    28       

Канбан в условиях российской действительности 71

Статья Системный администратор Бизнес-аналитик Пользователь Руководитель проекта Нет файла Россия Бесплатно (free) Управление бизнес-процессами (BPM) Управление проектом

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

08.08.2018    14901    MariaTemchina    63       

Записки про metadata.js 53

Статья Программист Нет файла Бесплатно (free) Практика программирования

Отличительные особенности разработки на metadata.js

31.07.2018    9112    1c-intelligence    59       

Что можно назвать проектом, а что нельзя, и каковы критерии успеха менеджера. Курс по управлению проектами, часть 1 63

Статья Бизнес-аналитик Пользователь Руководитель проекта Нет файла Россия Бесплатно (free) Управление проектом

Разберемся: что такое проекты в классическом понимании, почему строительство египетских пирамид проектом считать нельзя, почему многие "продуктовые" компании могут обходиться без проектного управления, каковы критерии успеха для руководителя проекта.

30.07.2018    11497    Selikhovkin    39       

Почему Agile превращается в Тяп-ляп. Кто виноват и что делать? 42

Статья Системный администратор Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

В моей практике довольно много историй, когда компании, решившие внедрять гибкие методологии, начинали за здравие (Agile), а кончали за упокой - Do & Fix (делаем, как бог на душу положит). Попробуем разобраться, почему так происходит.

27.07.2018    10032    MariaTemchina    19       

Можно ли объять необъятное или чем Agile отличается от водопада? 64

Статья Системный администратор Бизнес-аналитик Пользователь Руководитель проекта Нет файла Бесплатно (free) Управление проектом

Что общего между управлением парусной яхтой и проектом по внедрению ERP-системы на предприятии? В данной статье я постаралась понятным языком описать разные подходы к проектному управлению, и разобраться при каких условиях та или иная методология может быть полезной при реализации проектов.

23.07.2018    9254    MariaTemchina    42       

Redmine для управления ИТ: практический опыт обширного внедрения opensource-системы 72

Статья no Нет файла Бесплатно (free) Управление проектом

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

16.07.2018    23219    Hissin    15       

Учебный курс. Повышение качества разработки. Ошибки программы 97

Статья Программист Нет файла Бесплатно (free) Практика программирования Математика и алгоритмы Рефакторинг и качество кода

Учебный курс по теории и практике программирования. Бесплатно. В виде структурированного текста. Лекции № 3,4,5. Эти лекции посвящены ошибкам программ, их классификации и способам исправления

10.07.2018    15785    Артано    92       

Автоматизируй это! 148

Статья Системный администратор Программист Нет файла Бесплатно (free) Практика программирования

Здравствуйте. Меня зовут Виталий Онянов. Я работаю в компании ФТО. Мы занимаемся внедрением и поддержкой ERP-систем, в том числе и на 1С. Сегодня я хотел бы поделиться нашим опытом автоматизации своих задач и рассказать о том, какие регламентные задания мы настраиваем на серверах наших клиентов. Возможно, кому-то покажется, что это совсем простые и очевидные вещи, но я в своей работе периодически вижу разработчиков, которые делают какие-то задачи руками изо дня в день, и мне бы хотелось донести до них мысль о том, что многие из этих задач можно и нужно автоматизировать.

02.07.2018    16125    Tavalik    12       

Экспансия решений 1С на глобальный рынок: как взять быстрый старт? 42

Статья no Нет файла 1С:Франчайзи, автоматизация бизнеса Бесплатно (free) Управление бизнес-процессами (BPM) Управление проектом

Николай Шилкин рассказал о требованиях, которые предъявляет глобальный рынок к решениям 1С, рассмотрел достоинства и недостатки платформы в контексте ее выхода за пределы рынка стран СНГ. Он также объяснил, у каких решений есть шансы добиться успеха на мировом рынке, и дал рекомендации 1С-стартаперам.

04.06.2018    9302    RayCon    21       

Учебный курс. Повышение качества разработки. Вводная лекция, часть 2 49

Статья Программист Нет файла Бесплатно (free) Практика программирования Математика и алгоритмы

Учебный курс по теории и практике программирования. Бесплатно. В виде структурированного текста. Лекция №2. Эта лекция посвящена абстракциям, их свойствами и практическому применению в рамках классических парадигм программирования.

24.05.2018    10701    Артано    36