Как стать автором
Обновить
293.41

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

Планирование, отслеживание и контроль

Сначала показывать
Порог рейтинга
Уровень сложности

METEOR. Что может? Чем полезен? Виды представлений в METEOR. Часть 2

Уровень сложности Простой
Время на прочтение 7 мин
Количество просмотров 580

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

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

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

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

Читать далее
Всего голосов 4: ↑3 и ↓1 +2
Комментарии 0

Сборка Lego. Первый спринт

Время на прочтение 2 мин
Количество просмотров 2.9K

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

Читать далее
Всего голосов 15: ↑9 и ↓6 +3
Комментарии 3

Дзен в управлении продуктами

Уровень сложности Простой
Время на прочтение 5 мин
Количество просмотров 775

Всем привет!

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

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

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

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

Читать далее
Всего голосов 5: ↑3 и ↓2 +1
Комментарии 3

Понятный и неунылый open source — абсурдные, но занимательные лицензии на свободное программное обеспечение

Уровень сложности Простой
Время на прочтение 10 мин
Количество просмотров 5.2K

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

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

Читать далее
Всего голосов 27: ↑25 и ↓2 +23
Комментарии 7

Истории

Стратегии избегания и снижения риска: в чём разница?

Время на прочтение 4 мин
Количество просмотров 1K


Риски представляют собой любые трудности, факторы, события или проблемы, которые могут оказать положительное или отрицательное влияние на проект или конкретный бизнес-процесс. Эффективное управление рисками необходимо для того, чтобы риски, которые всё же возникают, не влияли негативно на общие цели. Менеджеры, ответственные за планирование и инициирование проектов, часто придерживаются стратегий, направленных как на избегание, так и на снижение потенциальных рисков. В этой статье мы поговорим об избегании и снижении рисков, а также о том, что следует учитывать при разработке стратегии управления рисками.
Читать дальше →
Всего голосов 19: ↑13 и ↓6 +7
Комментарии 0

Сделали платформу, которая считает, хватает ли нам в офисе бананов и печенья

Уровень сложности Простой
Время на прочтение 4 мин
Количество просмотров 635

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

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

Читать далее
Всего голосов 5: ↑3 и ↓2 +1
Комментарии 2

Настраиваем рабочее место: полезные инструменты для разработчиков и не только

Уровень сложности Простой
Время на прочтение 12 мин
Количество просмотров 5.2K

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

Читать далее
Всего голосов 9: ↑9 и ↓0 +9
Комментарии 16

Этапы жизненного цикла разработки ПО или что такое SDLC?

Время на прочтение 4 мин
Количество просмотров 2.2K

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

Читать далее
Всего голосов 2: ↑1 и ↓1 0
Комментарии 1

Что такое Risk Storming?

Уровень сложности Простой
Время на прочтение 3 мин
Количество просмотров 924

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

Читать далее
Всего голосов 12: ↑11 и ↓1 +10
Комментарии 1

Таск-трекер METEOR. Что может? Чем полезен?

Уровень сложности Средний
Время на прочтение 8 мин
Количество просмотров 1.1K

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

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

Читать далее
Всего голосов 2: ↑2 и ↓0 +2
Комментарии 2

Как мы автоматизировали и упростили процесс ведения релизов

Время на прочтение 5 мин
Количество просмотров 1.7K
image

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

После трансформации весь описанный выше функционал перешёл в одну группу — «Управление релизами». Коммуникации, работу с командой тестирования, отчётность и встречи — всё стала вести наша команда.

Большая часть коммуникаций проходила в почте. Сбор, фиксацию состава релиза и отчётность — всё приходилось делать вручную. Процесс подготовки к релизу занимал до пяти рабочих дней. Релиз-менеджер каждый день из confluence сохранял pdf-файл со списком задач и сравнивал состав релиза на предмет добавленных и исключённых задач. После включения задачи в релиз тест-менеджеры самостоятельно вносили её на страницу «Актуализация регрессов» на confluence согласно цветовой легенде и определяли, какие задачи требуют изменения в тестовой модели, а какие ещё не брали в работу. Было много ручных активностей релиз-менеджеров и тест-менеджеров, и это заставило нас подумать над частичной автоматизацией процесса ведения релизов.

Дальше я расскажу в деталях, как всё было «до» и как стало «после».
Читать дальше →
Всего голосов 12: ↑12 и ↓0 +12
Комментарии 2

Продуктивность в тишине: Отказ от совещаний как идеал

Уровень сложности Простой
Время на прочтение 10 мин
Количество просмотров 2.6K

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

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

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

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

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

Читать далее 🔥
Всего голосов 15: ↑12 и ↓3 +9
Комментарии 18

Как быстро выучить язык моделирования Archimate?

Время на прочтение 4 мин
Количество просмотров 4.4K

Я использую Архимейт в своей работе уже более 7 лет. Когда я познакомился с этим языком, то он привлек меня тем, что позволял изображать систему в динамике, то есть отображать не только структуру программы, но и бизнес-процессы, которые она автоматизирует, и средства, на которых она развернута. К тому же Архимейт казался очень простым — подумаешь, каких-то 10 стрелок и 20 компонентов. На тот момент я был уже очень опытным программистом и архитектором, у меня был огромный опыт проектирования систем и баз данных, также я на приличном уровне освоил несколько языков программирования. И казалось, что выучить такой простой язык — это дело нескольких часов.

Но как же я был не прав: приличные Архимейт модели у меня стали получаться только через 3 месяца, а спустя год я понял, что всё, что я рисовал ранее — хорошо бы перерисовать. Но вот почему Архимейт оказалось освоить совсем не так просто?

Читать далее
Всего голосов 24: ↑12 и ↓12 0
Комментарии 6

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн
PG Bootcamp 2024
Дата 16 апреля
Время 09:30 – 21:00
Место
Минск Онлайн
EvaConf 2024
Дата 16 апреля
Время 11:00 – 16:00
Место
Москва Онлайн

Как сделать джуна полноценной частью команды

Уровень сложности Простой
Время на прочтение 5 мин
Количество просмотров 3.7K

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

Читать далее
Всего голосов 22: ↑19 и ↓3 +16
Комментарии 3

От А до Я: Руководство по воспитанию молодых специалистов (на необычном примере )

Уровень сложности Простой
Время на прочтение 3 мин
Количество просмотров 2.7K

В жизни каждого руководителя возникает дилемма: взять эксперта за большие деньги или попытаться вырастить крутого специалиста самому? У меня был успешный и неуспешный опыт найма и тех, и других. К примеру, в МТС у нас были различные программы для найма специалистов без опыта, и я довольно активно в них участвовал — стажировки, различные хакатоны и прочее. Некоторые из участников потом оставались в компании и добивались больших успехов. При этом знаю руководителей, которые категорически против того, чтобы тратить на это время. У каждого сценария есть свои плюсы и минусы, и сегодня я хотел бы подробнее остановиться на найме джунов.

В качестве примера я взял свой недавний опыт "найма" джуна. 😀

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

Читать далее
Всего голосов 17: ↑14 и ↓3 +11
Комментарии 6

Как использовать макросы для систематизации документов «как в Confluence»?

Уровень сложности Простой
Время на прочтение 6 мин
Количество просмотров 1.4K

Привет! Приятно ведь читать хорошо оформленные статьи на уютном хабре? В которых часть текста спрятана под катом, есть подписи к картинкам, красивые и понятные таблицы и все остальные плюшки? Я думаю очень приятно. Поэтому предлагаю рассмотреть немного полезных советов, о том какие макросы в Confluence помогали делать это раньше, а теперь точно также помогают в EvaWiki.

В интернете много полезной информации по использованию Confluence. Например, вот статья с рекомендациями по использованию макросов. В ней всё достаточно круто описано, но хотелось бы внести поправку. Конфлюенс ушел из России, а EvaWiki осталась. И теперь тот функционал, который был в зарубежном решении можно использовать в российском.

Статья может быть полезной для тех, кто активно работал в Confluence и хочет точно также делать это в нашем ПО.

Читать далее
Всего голосов 9: ↑7 и ↓2 +5
Комментарии 0

Спринт с багами, или как (не) создать себе проблем

Уровень сложности Простой
Время на прочтение 3 мин
Количество просмотров 5.7K

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

Читать далее
Всего голосов 15: ↑10 и ↓5 +5
Комментарии 50

Передача контекста и знаний в IT команде

Уровень сложности Простой
Время на прочтение 19 мин
Количество просмотров 1.6K

Всем привет и добро пожаловать! Данная статья не является научной и не относится к разряду технических, она больше про коммуникации и командные процессы в IT. Это попытка систематизировать реальные практики по передаче контекста и знаний в IT команде, показать их актуальность и важность. Я уверен, что про что‑то из статьи вы уже слышали, видели, читали, или даже сами использовали. И для начала давайте определим основные понятия.

Контекст — совокупность различных факторов и/или сведений, необходимых для понимания или объяснения какого‑либо явления действительности.

Знание — проверенный практикой результат познания, то есть научные сведения, которые были проверены практикой и отражены в сознании человека.

В IT существует множество технологий, методологий, подходов, технических решений. Их комбинация определяет стек технологий компании, которых тоже оказывается множество. Найти специалиста с 100% совпадением по стеку технологий фактически очень сложно, да и знать всё на свете нереально. На самом деле это и не нужно, но статья немного про другое.

С контекстом, на мой взгляд, всё сложнее. Контекст — это не то, что вы можете изучить где‑то, прочитать статью, пройти курсы. Контекст плотно привязан к историческому наследию компанию. Это из разряда «так исторически сложилось». Я думаю, вам приходилось слышать эту фразу. Но даже в компании контекст от команды к команде может сильно отличаться, для каждой команды контекст тоже уникален.

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

Читать далее
Всего голосов 11: ↑9 и ↓2 +7
Комментарии 0

О причинах технического долга, том, как с ним бороться и убедить бизнес, что это проблема

Время на прочтение 3 мин
Количество просмотров 1.3K

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

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

Читать далее
Всего голосов 14: ↑10 и ↓4 +6
Комментарии 6

Выученные уроки молодого продакта

Уровень сложности Простой
Время на прочтение 5 мин
Количество просмотров 2.2K

Всем привет! Меня зовут Юстина Цига, и я владелец продукта IIoT в Цифровом СИБУРе.

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

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

Читать далее
Всего голосов 10: ↑9 и ↓1 +8
Комментарии 6

Вклад авторов

Работа