Рубрика «управление разработкой» - 56

Почему взрываются ракеты, что скоро появится в Kotlin и как спасти код ревью - 1

6 декабря мы провели очередной Java-митап. Там говорили вот о чём:

  • о разработке Moira — системы экстренного реагирования на инциденты (про ракеты — здесь);
  • о контрактах в Kotlin, задачах, проблемах и улучшениях для DSL;
  • о том, как роботом выбирать ревьюеров в большой команде разработчиков;
  • о том, как научить все компоненты генерировать графики и метрики на боевой среде;
  • о правильной обратной связи для обнаружения проблемных релизов.

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

Читать полностью »

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

Или есть? Может, оглядимся вокруг? Кто у нас есть, кроме менеджеров? Продавцы, конструктора, снабженцы, маркетологи, кадровики, бухгалтера, кладовщики, производственники, рабочие, системные администраторы… Так, кто еще? Вон там, что за парень в углу сидит, в компьютере ковыряется?

Этот парень – программист 1С. И он – лучший кандидат. Не верите? Это нормально, никто не верит. В том числе сам программист 1С. Но это факт, увы.Читать полностью »

Знакомьтесь – это костяк программного комитета нашей TeamLead Conf: Георгий Могелашвили (Booking.com), Николай Крапивный (Badoo) и Станислав Цыганов (Tutu.ru). Те люди, которые формируют содержание и задают направление. Мы задали им несколько простых вопросов о работе ПК, подборе тем и тому, на чем будет делаться упор на очередной февральской конференции.

Кто и зачем делает TeamLead Conf - 1
Читать полностью »

Нередко слышишь мнение, что составление Технического задания по ГОСТ 34 (ТЗ) занятие не только трудоемкое, но и крайне раздражающее, поскольку приходится писать много всякой ерунды, воды. Но подумайте: разработкой этого ГОСТа занимались целые НИИ, это был проект на государственном уровне, обобщен опыт сотен проектов автоматизации, сложных проектов. Неужели они могли написать чушь?

На самом деле, при грамотном подходе ГОСТ очень сильно помогает не только при разработке ТЗ, но в ходе реализации проекта автоматизации в целом (и не только в госконтрактах, но и для коммерческой разработки). Грамотные люди его писали. Но чтобы воспользоваться плодами их трудов, нужно немного понять замысел не только ТЗ, но и ГОСТ 34 в целом.

В данной статье мы пункт за пунктом разберем все требования ГОСТа и попробуем сделать разработку ТЗ по ГОСТ 34 не обременением, а большой помощью в проекте.

Читать полностью »

Настройка Jira под ваши нужды. Синхронизация команд в потоке проектов - 1

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

Дано:

  • вы разрабатываете и поддерживает сложный программный продукт, работающий на нескольких клиентах;
  • у вас несколько инженерных команд (бекенд, IT Ops, iOS, Android, веб и т. д.), которые работают независимо друг от друга с отдельными беклогами;
  • у вас несколько продуктовых направлений, то есть, грубо говоря, один продуктовый менеджер ведёт несколько проектов по своему направлению, другой менеджер — по своему;
  • ваши инженерные команды функциональны, то есть они не выделены на отдельные продуктовые направления, а решают задачи всех юнитов сразу, обслуживая определённую часть технологического стека;
  • и, конечно, вы используете Jira!

Читать полностью »

Jira против хаоса в разработке: как не терять задачи - 1

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

Дано:

  • вы разрабатываете и поддерживает сложный программный продукт, работающий на нескольких клиентах;
  • у вас несколько инженерных команд (бекенд, IT Ops, iOS, Android, веб и т. д.), которые работают независимо друг от друга с отдельными беклогами;
  • у вас несколько продуктовых направлений, то есть, грубо говоря, один продуктовый менеджер ведёт несколько проектов по своему направлению, другой менеджер — по своему;
  • ваши инженерные команды функциональны, то есть они не выделены на отдельные продуктовые направления, а решают задачи всех юнитов сразу, обслуживая определённую часть технологического стека;
  • и, конечно, вы используете Jira!

Читать полностью »

Несколько правил работы в команде, которые могут сохранить нервные клетки всех в сложные моменты. Бывает, работы так много, что некоторые моменты забываются. Поэтому важно создать некоторый свод правил, хотя бы для себя, чтобы иметь возможность быстро вернуть себя в эффективное состояние хорошего Team Player. Под катом правила, которые вывел для себя.
Читать полностью »

Тема оказалось слишком широка, чтобы уместить её в одну статью. Предлагаю вашему вниманию вступительную часть. В ней пойдёт речь о действиях, которые желательно предпринять ещё до написания технического задания на разработку, чтобы существенно снизить риски неудачи.
Разработка электроники. Выигрышная стратегия технологического стартапа. Часть I - 1
Мир вошёл в эпоху “умных вещей”, что породило интерес к технологическим стартапам, который только растёт год от года. На КС они бьют рекорды по сборам, даже несмотря на то, что достойно выполнить свои обязательства удаётся далеко не всем. За десяток с хвостиком лет попыток работы в роли волшебника воплощающего задумки клиентов и вдыхающего в них жизнь мною накоплено много опыта. Безжалостная статистика говорит о том, что 9 из 10 стартапов терпят фиаско, в моей практике это соотношение менее драматично, но возможно потому, что стараюсь не принимать участие в проектах, изначально имеющих большие шансы на провал. Основываясь на собственном опыте я попытаюсь сформулировать стратегию разработки, повышающую шанс на успех, для технологического стартапа средней сложности и проиллюстрировать её примерами.

О чём пойдёт речь под катом

Не стоит отливать ТЗ в граните.
Сколько денег необходимо для запуска технологического стартапа?
Начинать проверку вашей идеи стоит ещё до начала разработки.
Стратегическая канва — отличный инструмент для проверки конкурентоспособности.
Создание пространства, свободного от конкуренции на реальном примере.
Изучение ближайших аналогов — хорошая практика.
Подбор ключевых компонентов и оценка себестоимости.

Читать полностью »

image

Примечание автора спустя 42 года после публикации:

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

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

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

Предлагаю вам ознакомиться с материалом, а потом оглянуться и поискать его в других сферах.

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

Как комитеты создают новое?

Мелвин Конвей (Melvin E. Conway)
Оригинал PDF.
Читать полностью »

Путешествие gocritic'а в прошлое - 1

Хочу поделиться результатами работы последних нескольких дней, которые включали в себя анализ git истории некоторых крупных Go проектов с целью нахождения коммитов, которые исправляли ошибки c последующей их формализацией для детектирования в случае их появления в новом коде.

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

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js