Управление разработкой *

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

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

В посте я расскажу про методы повышения качества, которые сейчас получили особую популярность — построенные на основе методологий Lean Six Sigma, а также обсудим гибкие методики на основе подходов Agile и гибридных подходов PRINCE2. Разберу плюсы каждого из подхода и разберу необходимые шаги и условия для их внедрения.

Всё это в разрезе создания ПО (также подойдет и для производства радиокомпонентов).

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

* В статье пойдет речь о кейсе трансформации компании, чье название в этой статье нельзя упоминать. Но чтобы вы все-таки чуть лучше понимали контекст, далее в тексте я буду использовать термины "Красно-белый оператор" (КБО) и его банк (КБО Банк)

Для начала, думаю, будет нелишним начать с предыстории и предпосылках начала трансформации КБО.

Итак, в начале 2019г. КБО принимает стратегию трансформации компании в продуктовую экосистему. Что это и зачем?

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

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

«Всё, договорились, скрам-мастером теперь будет Полина», — отлично, кто-то договорился о том, что я буду скрам-мастером. Отрицание, гнев, торг, депрессия, принятие.  

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

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

Всем привет, это снова Макс Кравец, CEO IT-компании Holyweb. Публикуя статью о зарплатах разработчиков, я хотел поделиться с окружающими собственным представлением о том, что происходит на рынке IT. Но это точка зрения бизнеса, а есть и другая сторона. Дискуссия, которая развернулась под статьей — настоящая «Карта Мародеров», показывающая, куда идет и о чем переживает каждый комментатор. Ниже — несколько тем, которые родились в ходе обсуждения и оказались интересны самим разработчикам. 

Дисклеймер: комментарии авторов приведены без изменений или с минимальным редактированием.

Она помогла нам переиспользовать игровые механики в непохожих проектах и увеличила скорость разработки на 25%.

Определение подходов к автоматизации бизнес-процессов и связанный с этим выбор конкретных технологий, особенно в крупной организации, - комплексная задача, которая требует учитывать экономические, организационные, функциональные, технические и другие аспекты. Сегодня на рынке существует множество BPM-технологий самого разного масштаба - от легковесных библиотек до крупных платформ. В этой статье мы подготовили сравнительный анализ двух очень непохожих представителей из разных областей этого спектра - Pega и Camunda. По каждой из этих технологий мы, ЛАНИТ - Би Пи Эм, накопили немалый опыт использования и наработали портфолио крупных корпоративных решений. Среди них есть проекты по автоматизации кредитных конвейеров и других бизнес-процессов в крупнейших банках РФ (Сбербанк, ВТБ, Альфа-Банк). Есть проекты как с монолитной, так и с распределенной, микросервисной архитектурой.

Если кратко, Pega - экосистема для IT-поддержки процессного подхода в бизнесе, а Camunda - набор инструментов для реализации процессных приложений.

Больше 8 лет я использую Impact Map для аналитики IT-продуктов. Я довольно активно делился знаниями об этом подходе: писал статьи, выступал на конференциях с докладами и мастер-классами, рассказывал студентам в университетах и интернам в компании. Слушатели и участники мастер-классов легко улавливают, как создавать и использовать Impact Map, т.е. с теорией нет проблем. Тем не менее, я вижу большие затруднения с применением этого подхода в реальной практике, когда нужно придумать и описать идеи для сложного IT-продукта.

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

Про то, почему и как в разных компаниях приходят к продуктовым командам. Мыслями поделился автор telegram-канала для продактов alexcouncil Алексей Арефьев.

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

Привет! Я тимлид команды «Добро» в «Сравни.ру», мы занимаемся разработкой сервиса по подбору кредитных продуктов. 

Сервис, над которым мы работаем, помогает нашим клиентам подобрать кредитные продукты с высокой степенью одобрения. Для этого мы придумали алгоритм, который аккумулирует необходимый объем данных, обрабатывает их и подбирает кредитные продукты от банков, которые с высокой долей вероятности одобрят заявку конкретного пользователя. Нетипичное название команды («Добро») произошло от слова «одобрение». 

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

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

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

Меня зовут Владислав Романенко, я Senior iOS QA Engineer в Badoo и Bumble. Мы регулярно внедряем новые фичи в приложения, и автоматизация тестирования — один из способов не пропустить баги. Фактически автотесты входят в жизненный цикл всех частей наших приложений: бэкенда, сервисов, фронтенда и мобильных клиентов. Чем раньше мы обнаружим ошибку, тем дешевле будет её исправить. 

Сегодня я расскажу об автоматизации тестирования в iOS, потому что на протяжении всей своей карьеры в Badoo я плотно занимался тестированием наших нативных iOS-приложений, которые написаны на Objective-C и Swift. Хотя кое-где я буду упоминать характерные для iOS инструменты и термины (например, XCTest), общие принципы и подходы универсальны. Так что, даже если в вашем проекте используется совсем другой стек, статья будет вам полезна.

Представим простую историю. Вы заканчиваете делать рефакторинг, которым занимались последние 2 недели. Вы хорошо над ним поработали, сделали несколько ключевых изменений в проекте. Делаете долгожданный pull request, и ... 12 конфликтов.

Или другой вариант. Вы работали и постоянно подливали себе основную ветку, так чтобы код сильно не расходился. Делаете pull request, он висит несколько дней, после этого вы получаете approve и ... 15 конфликтов. Кто-то слил свой большой pull request раньше.

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

В этой статье поговорим про технику Branch by Abstraction. Как она может помочь не копить большие изменения в нашей ветке, избегать merge hell и прокачать ваш CI.

Я буду описывать примеры из Android-разработки, но они также справедливы для большинства типов проектов и платформ.

О том, что такое SCRUM, рассказывать на Хабре необходимости нет. Эта методология применяется компаниями любого масштаба для работы над проектами с оптимизацией взаимодействия команды. У нее есть как поклонники, так и противники, в чем можно убедиться, почитав комментарии под статьями соответствующей тематики – хоть на том же Хабре, хоть на других ресурсах. 

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

Продолжаем серию маленьких заметок про то, как анализатор PVS-Studio может быстро находить новые ошибки в коде. При условии, конечно, что он регулярно используется :). Итак, перед нами очередной баг в проекте Blender.

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

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

Но мы отвлеклись. Сегодняшний материал будет о продукте «Кредиты». О том, как создавались кредиты на Финуслугах, с какими вызовами мы столкнулись и как с ними справились, рассказывают ребята из продуктовой команды: Андрей Кителёв (тимлид команды), Алёна Садовская (лидер разработки продукта) и Павел Кряженков (директор департамента разработки электронных платформ). Спойлер: будет и про командную работу, и про knowledge-management, и про чистую архитектуру.