Agile *

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы думаете, что Канбан – это просто доска с карточками? Ошибаетесь!

Сегодня мы работаем головой больше, чем руками. Современный бизнес – это управление задачами, информацией, креативными процессами. Но вот беда: старые методы управления, пришедшие из заводов и фабрик, в мире интеллектуального труда часто не работают.

И тут на сцену выходит Канбан Метод – инструмент, который помогает навести порядок в работе, улучшить процессы и сделать их прозрачными. Не путайте его с обычной доской задач – Канбан Метод гораздо глубже. Это не жёсткая методология и не пошаговая инструкция, а гибкий подход к организации труда, который адаптируется под ваши задачи.

Алексей Пименов — тренер, эксперт и практик по Канбан Методу, Гибкости Бизнеса и Стратегическому Маркетингу. Более 10 лет помогает компаниям разного уровня с построением адаптивных процессов. Организатор, продюсер, постоянный спикер и кейноут крупнейших профессиональных конференций FlowDays, Kanban Eurasia, AgileDays, TeamLead Conf, Merge, IT Nights, SECON, SECR, CodeFest, Стачка и пр. Специально для комьюнити Skillbox Code Experts рассказал про мифы о Канбан Метода. Публикую статью по мотивам этого эфира.

Важно понимать разницу между методикой, методом и методологией. Если методика – это готовый алгоритм (делай раз, делай два, получи результат), то метод – это способ создавать такие алгоритмы. Канбан Метод именно такой: он не даёт вам готовых решений, а учит выстраивать процессы, подходящие именно для вашей команды, компании или проекта.

Если ты когда-нибудь сталкивался с размытыми задачами или бесконечными доработками кода, то Definition of Ready (DoR) и Definition of Done (DoD) — это именно то, что поможет с этим справиться. Давай разберемся, что это такое, зачем они нужны и как правильно использовать.

План статьи:

1. Что такое DoR и DoD?

2. Чем они полезны?

3. Как выглядят качественные DoR и DoD?

4. Как использовать DoR и DoD на практике?

5. Как создать DoR и DoD?

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

В последнее время я стал замечать, что применение подходов Agile в отдельных проектных коллективах стало носить характер религиозного культа. Иногда понимание целей знание названий основных терминов Scrum  для некоторых эффективных перспективных руководителей успешно заменяет здравый смысл. Они гордо заявляют о якобы успешном применении методов Scrum в условиях, в которых эти методы в принципе неприменимы. При этом в обоснование своих решений адепты Scrum как догму декламируют положения книги Джеффа Сазерленда «SCRUM: революционный метод управления проектами». Однако кроме основных догматов в некоторых конфессиях существуют другие древние артефакты, посвящённые ключевым заповедям. Вместе с тем эти артефакты не признаются церковью и не включены в канон. Несмотря на то, что авторство этих скрижалей также приписывается основателям церкви, эти документы противоречат основным положениям религии и являются запрещенными для адептов культа. Такие документы называются апокрифами.

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

1. Эдвард Йордан «Путь камикадзе»

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

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

Книга наполнена многочисленными примерами из реальной профессиональной деятельности автора, что делает содержащиеся в ней советы практичными, применимыми и не оторванными от реальности.

Основные идеи книги:

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

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

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

Или почему я считаю, что про фасилитацию нужно знать всем.

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

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

Фасилитация значительно упростила мою работу сначала как QA, затем как QA Lead и Engineering Manager. Давайте сразу перейдем от теории к практике, где я использую фасилитацию.

Меня зовут Сергей Яковлев, я руковожу проектами в ИТ более 10 лет. Хочу поделиться историей о том, как мы сделали проект, который попал в статистические 31 % реализованных ИТ-проектов, и при этом выдержали все базовые показатели: содержание, сроки, бюджет, качество. Причём в начале у меня был минимум знаний в предметной области, команды не было вовсе, а сдать проект необходимо было через год. Здесь я постарался описать весь жизненный цикл проекта, чего я ни разу не встречал в книгах и методологиях, и то, с чем сталкивается руководитель создания продукта.

По ретроспективе своего опыта усматривается понимание «что нужно было всё делать не так…».

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

Привет! Меня зовут Маша Резниченко, и я работаю Agile-коучем в Страховом Доме ВСК. До этого 4 года я была скрам-мастером, и за это время сталкивалась с разными мнениями о моей профессии: от сомнений в её необходимости до откровенных насмешек и язвительных комментариев о том, что скрам-мастера — это «паразиты» в мире IT. 

Конечно, такие слова задевают. Ведь скрам-мастера — это агенты изменений, которые помогают командам и компаниям внедрять культуру Agile и Scrum. Их влияние выходит далеко за рамки проведения встреч или составления графиков. На Хабре можно найти множество обсуждений на эту тему, и я решила внести свой вклад, развенчав популярные мифы о скрам-мастерах. 

Привет, Хабр! Меня зовут Таня, и последние 3 года я работаю с IT‑командами, помогая им выстраивать процессы, улучшать взаимодействие и внедрять рабочие практики, которые делают их работу продуктивнее и приятнее. За это время я провела десятки ретроспектив — и видела, как они могут либо кардинально менять команды, либо скатываться в скучные и бесполезные обсуждения. Сегодня разберем, как проводить ретро так, чтобы они действительно помогали команде становиться сильнее.

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

Agile-манифест был подписан аж в 2001 году, и неужели за прошедшие 25 лет, никто не захотел в нём что-то поменять?

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

За последние годы на LinkedIn наблюдается рост числа профессионалов, позиционирующих себя как «Google Certified Project Manager». На первый взгляд это звучит впечатляюще — ведь Google является одним из самых уважаемых технологических гигантов в мире. Однако, как нанимающий менеджер в сфере управления проектами, я нахожу эту тенденцию вводящей в заблуждение и, откровенно говоря, непривлекательной при оценке кандидатов. Давайте разберёмся, почему.

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

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

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

Я, Гузель Хамидуллина, системный аналитик департамента управления данными Positive Technologies. Рассказываю, что помогло нашей команде объединиться.