Agile *

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

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

— Удивительно, но в комментариях была тотальная поддержка «претензий». Одна из цитат, набравшая больше всего лайков: «Если человек отрабатывает от звонка до звонка, например с 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. продуктовая реальность — вечная дилемма. Разбираем, почему код не равно продукт и как не дать идеальным решениям похоронить бизнес.

Привет всем! Я работаю Agile-коучем, но смотрю за миром вокруг и вижу что ГИИ (генеративный искусственный интеллект) поменяет работу команд разработки. Меня впечатляет то, что происходит. Решил собрать мысли и поделиться своим взглядом на то, что ждёт нас в ближайшие 5 лет.

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

Такая же история с самоорганизующимися командами. Их не бывает.

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

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

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

Если вы «построили» самоорганизующуюся команду, то приглядитесь к ней. Скорее всего, в ней есть неофициальный тимлид, который почему‑то не хочет получать больше денег за организаторскую работу, которую он ведёт.

Так почему же популярна идея построения команд без явно выделенного тимлида?
Адепты «теории плоской команды» называют следующие причины...

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

Блокер — это задача, выполнение которой  невозможно или существенно затруднено из-за зависимости от другой задачи, ресурса или внешнего фактора. 

Практика работы с блокерами позволяет уйти от субъективного восприятия проблем к объективному анализу системы. Она помогает ответить на ключевые вопросы:

Как часто возникают проблемы и какова их продолжительность?
Главная задача, которую я ставил перед собой, — понять, почему может увеличиваться Lead Time, а также:

- Выявлять причины задержек, анализируя данные, а не полагаясь на догадки;,

- Отслеживать повторяющиеся тенденции в блокировках задач;,

- Формулировать выводы и улучшать процессы на основе объективных данных.

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

Здесь рассказываю о своем опыте, команде, принципах, результатах и факапах.

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

Методов оценки задач с точки зрения трудозатрат и сроков реализации очень много.

Scrum poker, T-shirt, Метод аналогий, Три Амиго ...

Почему в моей команде ни один из этих методов не используется и как мы пришли к точности планирования сроков и трудозатрат 80-90%.