Привет, друзья! Пока в соцсетях айтишники зумеры хвастаются шикарными офисами с видом на океан, я просто работаю: развиваю 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%.
В публикации речь пойдет о подходах в разработке ПО. Речь пойдет о некой компании, которой никогда не существовало и порядки, заведенные в ней – это исключительно собирательный образ. Если вы решили, что в вашей компании очень похожая ситуация, то это совпадение.
Вы думаете, что Канбан – это просто доска с карточками? Ошибаетесь!
Сегодня мы работаем головой больше, чем руками. Современный бизнес – это управление задачами, информацией, креативными процессами. Но вот беда: старые методы управления, пришедшие из заводов и фабрик, в мире интеллектуального труда часто не работают.
И тут на сцену выходит Канбан Метод – инструмент, который помогает навести порядок в работе, улучшить процессы и сделать их прозрачными. Не путайте его с обычной доской задач – Канбан Метод гораздо глубже. Это не жёсткая методология и не пошаговая инструкция, а гибкий подход к организации труда, который адаптируется под ваши задачи.
Алексей Пименов — тренер, эксперт и практик по Канбан Методу, Гибкости Бизнеса и Стратегическому Маркетингу. Более 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 в проектных Организациях со стороны самой Организации, её руководства должен быть очень простым, дешевым и качественным – да, именно все эти три взаимоисключающих условия.
