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

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

Вместо предисловия

Agile. Кругом Agile. Наверное не осталось людей, команд и организаций, которые работают не по Agile. Слово «SCRUM» прочно вошло в жизнь разработчика. Я уже и не помню, была ли разработка иной. А когда спрашиваешь, почему у вас в организации насаждается Agile, в ответ получаешь либо цитату из эпиграфа, либо, если человек более откровенен, слова "так все делают". Ну не может же быть, чтобы миллионы мух ошибались то, что делают все, было ошибочным?

Но, как известно, есть некоторые особенные люди, которые могут попытаться проверить, ошибаются ли мухи верно ли то, что делают все? Приятно, черт возьми, ощущать себя особенным!

Для начала попробуем подсчитать стоимость ритуалов SCRUM

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

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

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

Мы существуем в мире, где слова «мы не Яндекс» часто становятся прикрытием для многих предпринимателей, у которых что‑то зудит в работе с командой. Или с поиском талантливых людей в неё.

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

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

Я решил проверить действие метода в реальной жизни...

В 98 году в школе, где я учился, компьютер был только у директора. Наш учитель биологии, замечательный мужик, который по ночам подрабатывал админом в компьютерном клубе через дорогу, был единственным человеком, который шарил как этот ящик вообще работал. Я там тоже периодически зависал, поэтому в какой-то момент получил доступ к директорскому компу, под видом чистки и настройки. Все попытки заинтересовать меня программированием заканчивались включением SimCity, Caesar или Settlers и парой часов упорных тренировок в мобами. Позже, уже закончив универ, я работал в различных конторах, писал код для проектов не связанных с игростроем, но постоянно мечтал о создании игр. Пробовал заниматься маленькими играми для себя, да только в 2006 году бесплатные движки, такие как Unity и Unreal, ещё не существовали. В итоге получалось в основном писать свои движки с нуля и делать разные демки, которые благополучно забыты.

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

Над открытыми мирами не довелось работать, ну кроме, разве что, Cuisine Royale, которая, как бы, не совсем честный открытый мир, но задачи анализа технических решений в других играх и движках, чтение соответствующих лекций и статей помогают понимать какие решения были приняты дизайнерами при разработке, и главное зачем это было сделано. При погружении в новую игру, эти решения еще не так очевидны, но когда набегаешь под сотню часов в Witcher 3 или Zelda, эти паттерны становятся видны и легко ловятся взглядом. Хочу заметить, что ни та ни другая игра не ставят исследование в качестве основной цели. Квесты в Witcher рассказывают уникальные истории, а Зельда, как бы это не показалось странным, акцентируется на боевке и системе крафта. И что еще заметно, в этих играх не обязательно сильно исследовать окружающий мир. Дизайн уровней и компоновка golden path построены так, что игры ведут игрока за ручку, и он все равно оказывается возле важных областей или сюжетных квестов. А когда появилась возможность покопаться в движке и уровнях Metro: Exodus, то конечнo, с интересом начал разбираться с доступными материалами.

Опять будет много текста и картинок

Погружение в мир контейнеризации с докером — это путь к оптимизации развёртыванию приложений, а также ключ к упрощению жизни разработчиков и системных администраторов. Меня зовут Андрей Аверков, в IT c 2008 начинал пусть с аналитика-проектировщика IT систем, 11 лет в роли разработчика и последние годы на руководящих должностях. Сейчас я тимлид команды разработки из 9 человек в группе компании Кокос. Мы занимаемся созданием и поддержкой CPA платформ (gdeslon.ru, fxpartners.ru, ads.mobisharks.com), а также проектом по генерации лендингов — lpgenerator.ru. У нас большой опыт в разделении продуктов на части, поэтому, сегодня мы собрали самое основное и необходимое для работы с Docker. В нашей шпаргалке вы найдете все необходимое для успешного старта с докером: от базовых концепций и установки до продвинутых техник работы с контейнерами.

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

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

Цель статьи — исследовать, что на самом деле означают понятия «рост» и «развитие» в контексте профессиональной жизни IT‑специалиста и как эти аспекты влияют на выбор при найме на руководящие должности.

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

Статья будет полезна менеджерам проектов, разработчикам, тестировщикам, аналитикам и другим IT‑специалистам. Поговорим о способах выработки и применении стандартов, их влиянии на проектирование, разработку, тестирование и стабильность системы в целом. Для примера возьмем ERP CDEK, которая ежедневно обеспечивает работу десятков тысяч пользователей, нескольких сотен тысяч клиентов и позволяет нам обрабатывать до полумиллиона заказов в день.

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

Начнем с основ: потребности заказчика в информационной системе покрываются или ее доработкой, или ее донастройкой, или уже реализованы и не требуют дополнительных усилий. Первые два исхода задают Gap-область, последняя – Fit (рис. 1). Все доделки Gap-области можно классифицировать согласно RICEFS подходу [2], что представляет собой сокращение от англоязычных слов: Report, Interface, Conversion, Enhancement, Form и S (отчет, интерфейс, программа обработки данных, расширение, печатная форма и настройка). Введя термин сложности (низкая, средняя, высокая и очень высокая), можно построить элементарный Оценщик (от английского Estimate, оценивать) [3]. В нем для каждой пары «Тип разработки – сложность» эмпирически задаются плановые трудозатраты для этапов проектирования и разработки, то есть ресурсы функциональных консультантов на фазе дизайна и разработчиков для этапа разработки (табл. 2). Более сложные формы оценщика включают дополнительные параметры: новая разработка или модификация имеющейся, %-переиспользования, а также оценку трудозатрат не только для фаз проектирования и реализации, но и этапов анализа, теста и перехода.

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

В этой статье мы рассмотрим:

1. списки задач;
2. диаграмму Ганта.

Эти представления очень важны для эффективной работы. Давайте разберемся, чем они полезны.

Длинные выходные и сидящие на карантине (по ветрянке) дети позволили взяться за очень масштабный проект — строительство своего личного замка🕍, который мне подарили мои замечательные коллеги, когда я уходил из МТС. 🥚→👩‍🌾

Всем привет!

На связи GlowByte Soft. В серии статей мы хотим рассказать о  разных подходах к управлению продуктами, проектами и услугами в разрезе практической реализации фреймворков. В качестве инструмента будем использовать ZenTao –  профессиональный инструмент для управления проектами, разработкой и тестированием. 

Как быстро установить ZenTao Max на Windows или Astra Linux, рассказали в наших предыдущих статьях. Устанавливайте и пробуйте!

А подробнее о самой системе и о том, какие ИТ- и бизнес-процессы могут быть реализованы в ZenTao, можно прочитать тут: ZENTAO – больше чем просто ITSM-платформа.

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

В кризис open source вендоры коммерциализируют свои разработки активнее и все чаще переходят на формат распространения кода «source available». Резкие изменения в лицензиях — головная боль для руководителей и юристов, вынужденных разбираться в хитросплетениях новых условий. В качестве своеобразного ответа на подобные сложности появляются абсурдные тексты лицензий на открытые разработки.

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

Шутка! На самом деле платформу мы сделали, чтобы измерять здоровье компонентов в отделе фронтенд-разработки ЮMoney. А на бананах с печеньем (и на кофемашинах) объяснили коллегам, как всё это работает.

Меня зовут Борис Рябов, я руководитель отдела разработки интерфейсов в ЮMoney. Расскажу, какие задачи нам помогает решать Health Check Dashboard во фронтенд-разработке, и покажу, как выглядит платформа изнутри.

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

Хабр, привет! Сегодня хочу рассказать про этапы жизненного цикла программного обеспечения на примере алгоритма Software Life Cycle Model (SLCM)

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

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

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

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

По данным исследования компании Atlassian, средний работник тратит до 31 часа в месяц на непродуктивные совещания. Это примерно 8 часов в неделю, что равносильно полной рабочей неделе одного сотрудника из команды из пяти человек каждый месяц. Если мы переведем это в рабочие дни, то получается, что в среднем четыре человека работают, а один постоянно находится на совещаниях. Это не учитывает дополнительное время, потраченное на неформальные обсуждения и ad-hoc встречи, которые еще больше сокращают время, доступное для непосредственной работы над созданием продукта. Таким образом, разработчики фактически проводят менее половины своего рабочего дня на прямую разработку, что является тревожным сигналом для любой организаци.

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

Мое нежелание тратить время впустую или неэффективно, вылилось в то, что в департаменте разработки программного обеспечения мы тщательно следим за временем, которое наши разработчики тратят на совещания. В среднем, на разработчика приходится всего 2 часа 15 минут обязательных совещаний в неделю, включая четыре стендапа по 15 минут, встречу 1 на 1 с руководителем на 30 минут каждые две недели и 60 минут на различные совещания, такие как планирование и демонстрации. Остальное время, примерно 5 часов 45 минут, уходит на прочие активности в MS Teams, включая чаты и единичные созвоны. Хотя мы считаем, что и это время следует оптимизировать, основное внимание мы уделяем именно ключевым совещаниям, чтобы убедиться, что каждая минута проведенного времени имеет ценность.

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