Agile *

В Agile есть прекрасная штука, которая называется Daily Standup или «Ежедневный стендап». Короткая ежедневная встреча команды, во время которой каждый сотрудник делится своими достижениями, планами и затруднениями. Эти встречи позволяют держать руку на пульсе и решать возникшие трудности быстро, а так же не терять фокус на текущей работе. Меня зовут Виталий, я хочу рассказать в этой статье о том, с какими проблемами мы столкнулись при внедрении в команде стендапов (хотя казалось бы что‑там сложного) и как их решили. Получилось, на мой взгляд, достаточно просто, красиво и функционально.

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

Но для начала рассмотрим, что из себя представляет методология Agile, и чем она отличается от классической Waterfall.  

Меня зовут Александр, я CTO компании AppFox. Мы более 10-ти лет занимаемся заказной разработкой и также имеем собственные продукты. 

Всем привет, на связи Scrum‑мастер команды eXpress Дмитрий Шугалей. Совсем недавно мы добавили функцию тегов в мобильной версии нашего корпоративного мессенджера (на десктоп‑клиенте они работали уже давно), и еще раз убедились, что это вполне рабочий инструмент организации работы над задачами в проекте. Попробовал сам, поговорил с коллегами — и родилась идея посмотреть, как один из популярных методов повышения личной эффективности «встраивается» в рабочий мессенджер при помощи тегов. Получилась эта заметка как отражение личного опыта и нового взгляда на старый известный подход.

В первой части статьи я коротко напомню суть метода GTD (Getting Things Done), как одного из приемов работы с информацией, который помогает классифицировать рабочие задачи. Далее покажу, как этот метод можно внедрить в рабочую рутину с помощью тегов. А после поделюсь лайфхаками и собственными системами тегов от моих коллег. Статья может быть полезна как тем, кто уже использует теги в рабочем мессенджере, так и тем, кто сомневается в их эффективности или еще просто не попробовал внедрить их в свою рабочую рутину.

Привет, Хабр! Меня зовут Игорь Батулин, я руководитель группы разработки виртуального хостинга в Рунити. Эта статья — не просто рассказ о том, как я люблю рогейн, а пример того, как можно за несколько итераций и в условиях ограниченных ресурсов создать полезный инструмент, действительно помогающий команде принимать решения. Мой рассказ также подскажет, как можно применять Agile-подходы в реальных задачах.

Внедрение Agile «на хайпе» и искаженное понимание принципов манифеста ведет к сырым ненужным пользователю продуктам. Вместе с автором канала Junior PM, Артемом Летюшевым, разбираемся в разнице между настоящим значением принципов и мифами, которые компании принимают за правила и внедряют в свои процессы.

Небольшое интро:

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

— Удивительно, но в комментариях была тотальная поддержка «претензий». Одна из цитат, набравшая больше всего лайков: «Если человек отрабатывает от звонка до звонка, например с 9 до 18, то он не заинтересован в этой работе».

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

ИИ повышает эффективность Agile за счёт автоматизации задач, улучшения решений и оптимизации рабочих процессов. По прогнозам Gartner, в скором времени ИИ заменит 80 % ручного труда в управлении проектами, а это означает, что команды Agile смогут быстрее выявлять закономерности, прогнозировать проблемы и вносить коррективы в проекты.

Аналитик живёт в мире противоречий. С одной стороны - методологии, которые обещают навести порядок: SMART, INVEST, MoSCoW. С другой - реальность: брифы, скользкие бизнес-цели и коммуникации в духе “Ну тыжаналитик! Разберись!”

Инструменты вроде SMART, INVEST и MoSCoW помогают систематизировать хаос, структурировать требования, сделать их понятными, оценимыми, удобными для команды. Но если применять их бездумно, то становятся просто декорацией.

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

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

Меня зовут Алексей Панаэтов. Я руковожу технической командой Центра Геосервисов в МТС Web Services и сегодня расскажу, как мы оцениваем задачи через их декомпозицию, чтобы на выходе получались понятные всем значения без флера «я так вижу».

Привет! Я Алина, руководитель разработки конструктора ботов Smartbot. В этой статье я хочу поделиться опытом развития цифрового продукта силами маленькой команды.

Если у вас уже есть MVP и вы даже смогли привлечь первых юзеров, перед вами встает целый ряд интересных задач: нужно разрабатывать новую функциональность, исправлять баги, обрабатывать запросы пользователей и искать способы привлечения новой аудитории. Крупным корпорациям в этом плане неплохо живется — обычно под каждую из таких задач формируется целый отдел. А что делать, если над вашим продуктом работает всего 5-6 человек?

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

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

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

Всем привет! Меня зовут Олег Косарев. Я – ведущий инженер-программист. В группе компаний «Цифра» занимаюсь развитием и поддержкой продукта «Диспетчер». Моя основная специализация – Frontend-разработка.

В данной статье я хочу поделиться с вами нашим опытом по созданию MVP (Minimum Viable Product, «минимально жизнеспособный продукт») редактора аналитических панелей.

Привет, Хабр! Меня зовут Владимир Казаков, я руковожу продуктом «Обучение» в МТС Линк. В его основе — решение для вебинаров, с которого мы начали 16 лет назад как самостоятельный продукт. Сейчас наша платформа для обучения решает более широкий круг задач, к ней добавились и новые продукты (Курсы, Формы). Растет ответственность, число вовлеченных команд, но кое-что остается неизменным — сложность с проставлением дедлайнов.

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

Каждый раз, когда меня спрашивают: «А как ты вообще пришел к этим заповедям?», я улыбаюсь и вспоминаю одну историю. Она началась не в IT, не в офисе и даже не за чашкой кофе (хотя кофе, конечно, был). Она началась там, где начинается всё важное — в голове одного человека, который однажды осознал, что его жизнь превратилась в бесконечный марафон без финишной черты.

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

Очень давно я чувствовала, что меня распирает от разных мыслей о профессии. Мои друзья больше не хотят слушать мои идеи о работе, и поэтому у меня созрел план поделиться мыслями с профессиональным сообществом и единомышленниками.

Скорость чтения публикации — 10 минут (но, я надеюсь, вы проведете время с удовольствием).

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

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

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

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

А есть ли что-то более новое и при этом не кринжовое? Есть! Если вы хоть каким-то боком связаны с современным ИТ вы можете наблюдать и даже участвовать в становлении нового религиозного культа.

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

Software Development Life Cycle (SDLC) — это фундамент, на котором строится разработка. Он помогает выстроить процессы так, чтобы команда четко понимала, что и когда ей нужно делать, а заказчик знал, на каком этапе находится работа. 

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

А еще пообщались с командой AGIMA — интегратором, который более 15 лет создает веб-решения и мобильные приложения для клиентов. Компания показала, как выстроила процесс разработки и как она управляет командой.

«Нет, это не будет работать»
«Сейчас вообще нет времени на это»

И еще тысяча и одна фраза от людей, которые сопротивляются.

Когда я начинала работать Scrum Master»ом, мне было страшно столкнуться с сопротивлением и менять процессы. Я боялась, что мои предложения не поддержат. Ретроспективы вызывали тревогу, потому что ожидала волну негодования, с которой не справлюсь.

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

Представьте: ваш СТО тратит месяцы на безупречную архитектуру, но пользователи массово уходят к конкурентам с кривым, но быстрым MVP. Знакомый сценарий? Технический перфекционизм vs. продуктовая реальность — вечная дилемма. Разбираем, почему код не равно продукт и как не дать идеальным решениям похоронить бизнес.