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

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

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

Анализатор PVS-Studio умеет "схлопывать" повторяющиеся предупреждения. Предоставляет возможность задать baseline, что позволяет легко внедрять статический анализ в legacy-проекты. Стоит ли предоставить эти возможности для сторонних отчётов?

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

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

Всем привет! Меня зовут Меньшиков Илья, я тимлид в Бизнес-юните классифайдов в VK.

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

Story Point (иногда Scrum Point) — относительная мера сложности или трудоёмкости элементов бэклога продукта.

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

Если отвечать утилитарно — оценки(Estimate) нужны для быстрого и реалистичного планирования объема работы на спринт и построения BurnDown (BurnUP) диаграммы или Velocity Chart.

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

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

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

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

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

они оценивали меня.

Вместе с изменениями рынка меняется и наша объединенная конференция DevOps Conf & TechLead Conf 2022. Мы запустили дополнительный Сall for Paper, собрали заявки и отобрали самые горячие антикризисные доклады. Никаких банальностей, которые легко гуглятся или читаются в документации — не будет. Участники конференции, как обычно, поделятся собственным опытом и свежеобкатанными идеями.

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

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

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

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

Этой статьёй я хочу ещё раз напомнить, как инструменты командного взаимодействия решают проблемы качественной разработки, что ответственность за качество лежит на всей команде и что agile-понятия «Прозрачность» и «Предсказуемость» часто теряются на фоне клепания тасок в Jira. Несмотря на свою очевидность, Agile-практики применяются не везде, где могли бы приносить пользу, либо применяются с ошибками и антипаттернами, противоречащими самой культуре Agile. Я расскажу, с какими сложностями столкнулся на разных этапах распространения этой культуры и что делал, чтобы их преодолеть.

Если вы готовы тащить такие практики или пробовали их, но не взлетело, тоже смело заходите под кат. Буду счастлив, если найдёте для себя что-то новое и интересное.

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

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

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

И сразу 3 важных отступления:

В очередной статье, посвящённой практике перехода с 1С:УПП на 1С:ERP, мы рассмотрим перенос пользователей в новую автоматизированную систему с сохранением прежних прав на примере кейса одного из наших заказчиков, крупного производителя кофейной продукции.

Автор статьи: Дмитрий Малышев - разработчик 1С с 2004 года на платформах 1С 7.7, 8.1, 8.2, 8.3. Сертификат «1С:Эксперт по технологическим вопросам». Участник 30 проектов полного цикла внедрения 1С:УПП и 1C:ERP.

Привет, я Black из Scalable, QA Lead в команде бэкенда по разработке биржевого ядра. Так как уже долгое время занимаюсь развитием высоконагруженной платформы, решил написать о том, как нам удалось поставить QA-процесс с 20 000 тест-кейсов, создать гибкую инфраструктуру для автоматизированного тестирования в нескольких типах API, включая асинхронные бинарные протоколы, и пройти путь разработки от отладочных утилит до специализированных тестовых фреймворков для интеграционного и компонентного тестирования. 

Добрый день, уважаемые читатели Хабра!

На тему онбординга написано немало - в основном про то, как здорово устроен процесс в компании N. Я же, хочу с вами поделиться своими наблюдениями на тему “как делать ни в коем случае нельзя”, ведь порою отрицательный опыт не менее важен, чем истории успеха. 

Я часто слышу от владельцев бизнеса сомнения и неуверенность в сторону собственной команды разработки. Самое частое недовольство — срыв сроков и удорожание работ. При этом команда довольно логично объясняет причины и того, и другого, но уровень доверия к ней начинает падать. 

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

Как же предпринимателям без технических знаний понять программистов и подружиться с разработкой? Я уверен, что залог успеха — партнерские отношения между бизнесом и инженерами. У инженеров есть видение, мнение и экспертиза. А у бизнеса есть свои цели. В то же время, инженерия — это всегда расходная статья бюджета, а не доходная. Либо компания, потратив деньги на разработку, получит профит, либо разработка, с точки зрения бизнеса, просто сжигает бюджет. Технический склад ума разработчиков зачастую концентрируется на красивом коде, использовании best practice,  настройке, рефакторинге. На это команде разработки требуется дополнительное время. А бизнес знает, что если в определенный момент времени потребность клиента не удовлетворена, позже она просто теряет смысл. Давайте разберемся, почему возникают проблемы в общении и как можно их устранить.