В публикации речь пойдет о подходах в разработке ПО. Речь пойдет о некой компании, которой никогда не существовало и порядки, заведенные в ней – это исключительно собирательный образ. Если вы решили, что в вашей компании очень похожая ситуация, то это совпадение.
Вы думаете, что Канбан – это просто доска с карточками? Ошибаетесь!
Сегодня мы работаем головой больше, чем руками. Современный бизнес – это управление задачами, информацией, креативными процессами. Но вот беда: старые методы управления, пришедшие из заводов и фабрик, в мире интеллектуального труда часто не работают.
И тут на сцену выходит Канбан Метод – инструмент, который помогает навести порядок в работе, улучшить процессы и сделать их прозрачными. Не путайте его с обычной доской задач – Канбан Метод гораздо глубже. Это не жёсткая методология и не пошаговая инструкция, а гибкий подход к организации труда, который адаптируется под ваши задачи.
Алексей Пименов — тренер, эксперт и практик по Канбан Методу, Гибкости Бизнеса и Стратегическому Маркетингу. Более 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. Рассказываю, что помогло нашей команде объединиться.
Как выстроить отдел разработки с нуля, создать сильную команду и организовать процессы так, чтобы они работали даже без тебя? В этом кейсе я расскажу, как мне удалось собрать и масштабировать IT-отдел до 18 человек, выстроить эффективные процессы разработки и реализовать сложную MES-систему для автоматизации производственных линий.
Что в статье:
✔ Опыт организации работы параллельной работы 10+ бэкенд-разработчиков
✔ Ролевая модель и бизнес процесс создания продукта
✔ Почему junior-разработчики могут быть продуктивнее middle’ов
✔ Метрики помогающие контролировать эффективность команды
Расскажу о ключевых вызовах, сложностях и решениях, которые помогли довести проект до успешного запуска. А ещё — какую роль в этом сыграл Эльбрус. Если вам интересно, как построить сильный отдел разработки и не утонуть в процессах, — эта статья для вас.
Привет, хаброжители!
В этой статье я расскажу, как я работаю, когда «подгорает» на примере модуля планирования рабочего времени в нашем корпоративном портале.
Меня зовут Курдюмов Дмитрий, я более 7 лет занимаюсь Agile-трансформациями и помогаю компаниям выстраивать процессы поставки ценности. Одним из главных вызовов крупных организаций является то, как обеспечить сонаправленную работу большого количества команд вокруг единых целей, при этом сохраняя стабильный операционный ритм поставки ценности. Часто разные подразделения работают, как лебедь, рак и щука, делают одни и те же вещи, проделывают много работы с невысоким выхлопом для бизнеса. Классическая иерархическая структура компаний мешает эффективной координации, а управление функциональными отделами ведет к разрозненности процессов.
Фреймворк SAFe (Scaled Agile Framework) помогает решить эту проблему, организовывая команды вокруг value streams (потоков создания ценности), что упрощает управление и повышает предсказуемость работы. Давайте разберемся, как именно SAFe позволяет выстроить ритм поставки ценности.
Когда я начинал свой путь junior PM, мне казалось, что ключ к успеху — это найти ту самую «волшебную» методологию. Scrum там, Kanban или, симпатичный, p3express. Но потом я понял одну штуку (спойлер: я еще в процессе понимания) — пока не разберёшься в пяти классических функциях менеджмента, любые модные фреймворки/методы/методологии будут лишь «пляской с бубном». При том что ты еще не стал шаманом.
