Введение и кто я такой
Статья предназначена для молодой и неопытной команды разработчиков, или начинающему продакт/проджект менеджеру. От опытных специалистов жду конструктивной критики. Спасибо.
Если ты как раз тот самый молодой и неопытный, то крайне рекомендаю ознакомиться с комментариями к посту. Там содержится очень правильная и конструктивная критика. В этой статье я лишь делюсь своими знаниями и заметками, чтобы получить фидбэк от опытных специалистов.
суть правильного процесса в том, чтобы не слепо работать по скраму, а слушать и прислушиваться к своей команде, выстраивая при этом масштабируемую и удобную для всех систему, в которой можно анализировать эффективность и контролировать работу. Scrum - просто некий шаблон, который должен знать хороший продакт/проджект, и уметь его применять по необходимости. Если что - исправьте меня.
Привет, читатель. Недавно я стал Product Manager'ом в одном невероятно крутом и грандиозном проекте. Спасибо за похвалу :)
(если что, я первый день на вастрик, и вообще никогда не писал ничего подобного)
С 14 лет я разрабатываю приложения, мой путь начался с знакомства с HTML и CSS, затем продолжился с Python, далее изучением СИ и C++ в университете и коммерческой разработкой на PHP. Вроде бы, это достаточный опыт в IT-разработке (относительно достаточный).
Программирование давалось мне достаточно тяжело и казалось слишком скучным. Я решил попробовать себя в чем-то новом, и выбор пал на Project Management. Тогда я еще толком не знал, что это такое, понимал только, что это связано с управлением чем-то там, руководством, большой ответственностью и трудом. Всё, как я люблю. Буквально через 2 недели, после того, как я начал погружаться в эту тему, я устроился на работу в одну крутую компанию, которая разрабатывает крипто-платформы и вообще всю деятельность с криптовалютой. Спойлер: я ушёл через очень короткий промежуток времени. Но не потому, что я дурак, а потому, что все их процессы были ужасны.
Приобретя отрицательный опыт в этой компании, я увидел, как делать НЕ нужно. Находясь в спокойной обстановке, я стал долго и мучительно анализировать, что же именно было не так в той компании, и почему всем было очень тяжело. Я сидел, сравнивал, анализировал, размышлял, думал и пришел к выводу, что нужно бы что-нибудь почитать, так как я вообще ничего не понимаю в этом.
Каково было моё удивление, что проект - это не про создание крутых продуктов, да и аналитик, проект и продукт - это не одно и то же. Но статья не про это.
В этой статье я хочу поделиться своими знаниями, которые я приобрел, исходя из моего личного опыта работы продуктом над своим собственным pet-продуктом и коммерческим решением. Конкретно, я хочу показать вам свой документ, который составил для команды.
Этот документ ОЧЕНЬ кратко описывает всё, что нужно знать рядовому неопытному разработчику. Он содержит все вопросы и ответы, которые он может задать. Документ поможет даже ребёнку разобраться, что такое Scrum, что такое спринты, кто такой продукт, почему нужно работать именно так, зачем нам документация и т.д.
Документ не был написан конкретно для статьи в Вастрик. Я просто хотел замотивировать свою неопытную в этом деле команду, объяснить, как я вижу правильную работу и почему.
Судите строго. Очень жду критики. Я ещё учусь, поэтому мне будет очень приятно услышать конструктивную критику и поработать над своими ошибками.
Что ж, не буду затягивать. Приятного чтения!
Манифест гибкой разработки
Для начала ознакомимся с правилами гибкой разработки.
Манифест - это как священный текст для нас, разработчиков. В нем говорится, что важнее:
Люди и взаимодействие больше, чем процессы и инструменты.
Работающий продукт важнее, чем исчерпывающая документация.
Сотрудничество с заказчиком важнее, чем договорные отношения.
Готовность к изменениям важнее, чем следование плану.
Это напоминает нам, что главное - это гибкость и способность быстро адаптироваться к изменениям.
Что такое SCRUM
Давай разберемся, что такое Scrum. Это как игра в футбол, но вместо головы и ног используем мозги и командную работу.
Scrum - это как правила в игре, которые помогают нам работать вместе и делать это эффективно. Основная цель - не просто создать продукт, а создать его так, чтобы он был крутым и полезным.
Если что, Scrum изменил всю жизнь японцев и сделал из слабой страны сильную державу. Это их жизненный уклад.
Мы используем Scrum, потому что это как GPS для нашего проекта. Он помогает нам знать, куда идти, как долго еще путь, и если что-то изменится, быстро перестраивает маршрут.
Это не только для IT-компаний, но и для любых, кто хочет сделать что-то классное. Мы можем быть уверены, что каждая часть команды знает, что делать, и все работает как часы.
Как это нам поможет
Внедрение Scrum может принести команде множество выгод и содействовать достижению успеха в различных аспектах. Вот несколько ключевых преимуществ, которые Scrum может предоставить:
Быстрые результаты: Scrum разбивает работу на короткие спринты, обычно 2-4 недели. Каждый спринт заканчивается готовым к выпуску продуктом. Это означает, что команда быстро видит результаты своей работы, что может повысить мотивацию и уверенность.
Гибкость и адаптивность: Scrum позволяет быстро реагировать на изменения в требованиях или приоритетах. Это важно в быстро меняющейся среде, где необходимость в адаптации может возникнуть в любой момент.
Прозрачность и понимание задач: Регулярные встречи и использование инструментов Scrum обеспечивают прозрачность в работе команды. Каждый знает, над чем работает другой, и какую ценность это приносит продукту.
Контроль качества: Scrum включает в себя регулярные инспекции продукта, что способствует раннему обнаружению проблем и обеспечивает высокий стандарт качества.
Улучшение коммуникации: Регулярные встречи, такие как Daily Standup и Sprint Review, создают открытую обстановку для обсуждения проблем и достижений. Это способствует лучшей коммуникации внутри команды.
Участие заказчика: Роль Product Owner включает заказчика в процесс разработки, что позволяет команде лучше понимать потребности и ожидания клиента.
Развитие команды: Scrum обеспечивает механизмы для обучения и улучшения. Регулярные ретроспективы позволяют команде анализировать свою работу и внедрять улучшения.
Постоянное обучение: Scrum поощряет команды к постоянному обучению и росту. Это помогает удерживать талантливых специалистов и создавать условия для их профессионального развития.
В целом, Scrum не только структурирует процесс разработки, но и создает культуру, способствующую открытости, улучшениям и постоянному стремлению к достижению лучших результатов.
Интересные факты про SCRUM
Scrum как фреймворк, а не методология: Scrum часто описывают как фреймворк, потому что он предоставляет общую структуру, но не задает строгих правил. Каждая команда может настраивать Scrum в соответствии с собственными нуждами.
Scrum вне IT: В начале Scrum был широко использован в области информационных технологий, но с течением времени его применение расширилось на другие области, такие как маркетинг, управление проектами, образование и даже личная жизнь.
Scrum в киноиндустрии: Например, компания Pixar использует Scrum для организации своего творческого процесса при создании анимационных фильмов. Это подчеркивает универсальность и гибкость Scrum в различных сферах.
Scrum и игры: В некоторых компаниях используются элементы Scrum для повышения продуктивности и командного взаимодействия через игры. Это может быть, например, использование досок и карточек для отслеживания задач.
Scrum в образовании: Некоторые учебные заведения и тренинги внедряют Scrum в образовательные программы, чтобы обучать студентов эффективному управлению временем и задачами.
**Scrum и самоорганизация: **Одним из ключевых принципов Scrum является самоорганизация команды. Команда принимает решения о том, как выполнять работу, что может повысить ответственность и мотивацию участников.
Scrum в путешествиях: На некоторых форумах путешественников можно найти отчеты о том, как люди применяют принципы Scrum для планирования и управления своими путешествиями, учитывая бюджет, временные рамки и цели
Что говорят сильные личности про SCRUM
Ken Schwaber: Один из соавторов Scrum Guide, Кен Швабер, сказал: "Scrum не просто организует работу. Это создает среду, которая раскрывает бесценные знания в людях и помогает их использовать."
Jeff Sutherland: Другой соавтор Scrum Guide, Джефф Сазерленд, известен своим высказыванием: "Scrum не создан для того, чтобы сделать вашу жизнь проще. Он создан для того, чтобы сделать вас лучше."
**Майкл Крис: **
"Scrum — это не магия. Но если его правильно внедрить, результаты могут казаться волшебством."
"Scrum помогает командам перестать бороться с хаосом и начать управлять сложностью."
Alistair Cockburn: Известный автор и один из создателей Agile Manifesto, Элистер Кокберн, подчеркнул: "Scrum — это как настоящий метр: он показывает, что случается в вашей команде. Но как часы, он не говорит вам, почему."
Что такое спринт
Спринт - это наш короткий рейс к успеху, обычно длительностью от одной до трёх недель. Как краткосрочное путешествие, спринт представляет собой интенсивный период работы, в течение которого мы фокусируемся на достижении конкретных целей.
Зачем нам это нужно
Быстрые результаты: Спринты позволяют нам видеть первые результаты нашей работы очень быстро. Мы не ждем месяцами - каждый спринт приносит кусочек продукта, который можно предоставить заказчику.
Контроль над процессом: Время спринта - это наше время, когда мы сами управляем тем, что делаем. Мы планируем, работаем и достигаем результатов, всё в рамках установленного времени.
Обратная связь: После каждого спринта у нас есть возможность получить обратную связь. Мы можем посмотреть, что получилось, что не получилось, и быстро внести коррективы. Это как быстрая проверка нашего маршрута.
Как это нам поможет
Мотивация: Завершение спринта дает нам чувство завершенности, достижения. Мы видим, что двигаемся вперед, что наши усилия приносят результаты. Это повышает нашу мотивацию.
Гибкость: Спринты делают нас более гибкими и адаптивными. Если что-то идет не так, мы можем быстро переориентироваться и изменить план на следующий спринт.
Прозрачность: Спринты создают ясность в наших задачах и целях. Каждый видит, над чем работает команда, и какой вклад вносит каждый из нас.
Как мы будем по ним работать
Быстрая поставка ценности: Команда разработки создает инкремент продукта в течение каждого спринта. Это позволяет поставлять новые функции или улучшения заказчику чаще, обеспечивая более быструю поставку ценности.
Раннее выявление проблем: Спринты включают в себя регулярные ревью и ретроспективы, где команда анализирует свою работу. Это позволяет быстро выявлять проблемы и находить способы их решения, что в конечном итоге повышает эффективность процесса.
Гибкость в изменениях: Из-за коротких циклов спринтов команда может легко адаптироваться к изменяющимся требованиям заказчика или рынка. Это помогает избежать задержек, связанных с долгосрочными планами, и обеспечивает более гибкую и отзывчивую разработку.
Лучшая планировка ресурсов: Спринты предоставляют рамки времени, в течение которых команда может сосредоточиться на конкретных задачах. Это помогает более точно планировать ресурсы и управлять рабочей нагрузкой.
Улучшенная коммуникация: Регулярные события в спринте, такие как Daily Standup и Sprint Review, создают возможность для открытой и эффективной коммуникации внутри команды. Это снижает риск недопонимания и повышает согласованность в работе.
Постоянное совершенствование: Ретроспективы в конце каждого спринта предоставляют команде возможность оценить свои процессы и найти пути для их улучшения. Это способствует постоянному росту эффективности.
Структура работы по спринтам
Работать мы будет по адаптированному для нашей команды scrum системе. Что это значит? Это значит, что у нас будут 1-3 недельные спринты(обсуждаемо) со всеми вытикающими. Доски будут kanban.
Представим, что у нас уже был один спринт, и теперь идет следующий. Как будет происходить работа:
Перед началом спринта, за 1-2 дня мы планируем и грумим новый спринт. Мы будет обсуждать весь бэклог на предмет того, какие задачи мы добавим в новый спринт, какие у нас приоритеты на спринт, какие цели. Также мы оценим задачи по STP, распределим и отредактируем их, устраним возникшие препятствия и сделаем так, чтобы каждый участник спринта понимал, что он должен делать и зачем. Каждый участник поймет цель спринта и его суть, мы определим все задачи и приоритеты.
Каждый день в строго назначенное время вся команда собирается на стендап-дейли, на котором мы обсуждаем как идет работа у каждого члена команды, какие у него приоритеты, есть ли какие-нибудь проблемы, все ли ему понятно, что он сделал вчера и будет делать сегодня.
В последний день спринта вся команда собирается на ревью и ретроспективу. На ревью мы делимся результатами проделанной работы, закрываем спринт, подводим итоге по работе и эффективности спринта. На ретроспективе мы думаем о том, как нам лучше работать дальше. Обсуждаем, что можно добавить/убрать, что понравилось/не понравилось, что бы улучшил/убрал и тд. Всё по шаблонам.
Далее опять планирование и груминг и так по кругу 1-3 пункты. Все будет строго документироваться и систематизироваться. Это реально необходимо, так вся команда будет четко понимать цели и задачи продукта, который они делают. Порядок в голове = порядок в продукте, и это важно!
Кто такой продакт менеджер
Я - продакт менеджер, и моя роль подобна роли дирижера в оркестре. Я несу ответственность за весь жизненный цикл продукта, от его концепции до выхода на рынок и дальнейшей поддержки. Моя задача - обеспечить, чтобы мы создавали продукт, который соответствует потребностям пользователей и приносит команде и компании успех.
Роль продакт менеджера в команде
Определение стратегии продукта: Я разрабатываю стратегию продукта, определяю цели и путь к их достижению. Это как карта, которая помогает нам ориентироваться в создании продукта.
Создание видения продукта: Я формулирую ясное видение продукта, чтобы каждый член команды знал, куда мы идем и почему. Это как наше назначение, на которое мы ориентируемся.
Работа с командой: Я взаимодействую с каждым из вас, чтобы понять ваши идеи, предложения и вопросы. Мы вместе формируем стратегию, создаем планы и разрабатываем продукт, который будет успешен.
Разница между проджектом, аналитиком и овнером
Проджект менеджер (Project Manager): Он ответственен за управление проектом внутри установленных рамок, таких как бюджет и сроки. Он следит за тем, чтобы задачи выполнялись вовремя и согласно плану.
Бизнес-аналитик (Business Analyst): Этот специалист анализирует бизнес-потребности, формулирует требования и предоставляет команде информацию, необходимую для разработки продукта. Бизнес-аналитик сосредоточен на понимании бизнес-процессов и требований.
Владелец продукта (Product Owner): Он представляет интересы заказчика и определяет, какие функции и изменения важны для успеха продукта. Владелец продукта принимает решения о приоритетах и направлении развития продукта.
Почему продакт - это и проджект и аналитик и овнер:
**Управление продуктом (Product Management): ** Я объединяю в себе элементы управления проектом, анализа бизнеса и владельца продукта. Моя роль не только в достижении целей проекта, но и в создании продукта, который действительно решает задачи пользователей и соответствует стратегии компании.
Воронки задач
Трекинг задач будет происходить в Yandex Tracker.
Воронка будет состоять из:
Открытые: задачи, которые вынесены из общего бэклога в бэклог спринта. Эти задачи должны быть выполнены за спринт.
В работе: задачА, над который программист работает прямо сейчас. Если задачи две и более, то скорее всего программист либо забыл перетащить их из статуса, либо делает задачи плохо.
На ревью демо: задачи, которые программист выполнил, залил на демо стенд, и готов предоставить на проверку.
Готово к релизу: задачи, которые приняли и утвердили к релизу. Их осталось только зарезилить.
Закрытые: успешно выполненные задачи, которые уже выложены и функционируют на проде.
Приостановленные: задачи, работа над которыми не предоставляется возможной. Либо она глупая, либо не хватает информации, либо вы с ней не согласны. Эту задачу что-то блочит, или вы просто не хотите ее делать по своим причинам.
Описание типов задач
Задачи - это не только задачи(наверное). Тавтология, но это так.
Раньше вы всегда получали только “задачи“. Но помимо задач есть еще “эпик“, “стори“, “баг“, “подзадача“.
“Задача“ - это просто любая задача, которую вам могут поставить. Она содержит в себе описание и критерии приёмки. Описание может быть абсолютно любое.
“Эпик“ - это очень большой блок какой-нибудь сущности. Например: главная страница, регистрация, платежная система. Обычно к эпику прикрепляются задачи, чтобы прогер понимал, над чем он работает. С помощью эпиков удобно закрывать большие блоки. Эпики состоят из описания и критериев приемки.
“Стори“ - это задача, но от лица пользователя. Структура - как пользователь, я хочу что-то, чтобы добиться чего-то. Критерии приёмки … Шаги пользователя …
“Баг“ - это баг 😃 Но в этой задачи мы конкретно описываем как можно воспроизвести баг и к чему он ведет. Баги ВСЕГДА нужно ликвидировать в первую очередь.
Зачем нужна документация
Ясность и понимание: Документация служит руководством для нас всех. Она позволяет всем членам команды и заинтересованным сторонам лучше понимать, как устроен наш продукт, какие задачи мы решаем и какие решения приняты.
**Наследование знаний: **Документация помогает сохранять и передавать знания в команде. Когда кто-то из команды уходит или новый член присоединяется, документация становится ценным ресурсом для быстрого вхождения в курс дела.
Снижение зависимости от личных знаний: Она предотвращает ситуацию, когда целая команда зависит от знаний только одного человека. Документация - это наш страховой полис против потери критической информации.
Обеспечение качества: Документация определяет стандарты и требования к продукту. Это руководство, следуя которому, мы можем обеспечивать высокое качество и соответствие наших результатов заявленным целям.
Легкость масштабирования и сопровождения: С ростом проекта и команды, документация становится инструментом масштабирования. Она упрощает процессы управления и поддержки продукта на протяжении всего его жизненного цикла.
Как это поможет команде
Оптимизация времени: Документация помогает нам не тратить время на повторные вопросы и разъяснения. Каждый может самостоятельно найти ответы и продолжить свою работу.
Снижение риска ошибок: Когда все знают, что и как делать благодаря документации, мы снижаем риск ошибок и неопределенности. Это особенно важно в условиях давления сроков.
**Легкость совместной работы: **Документация становится нашим совместным языком, который помогает нам эффективно общаться и сотрудничать в различных областях проекта.
Почему это обязательно
Профессионализм и ответственность: Наличие хорошей документации свидетельствует о нашем профессионализме и ответственности. Это проявление уважения к работе своих коллег и заказчиков.
Поддержание стабильности: Документация - это основа для стабильности процессов и результатов. Без нее мы рискуем потерять управление над проектом.
Документирование и структура папок
Документация будет храниться и создаваться в Yandex Wiki.
Сначала может показаться, что этой документации слишком много, но это лишь кажется. Мы не будем заполнять её за один присест. 90% всей этой документации лежит на CEO и PM. Так что не пугайтесь. Документация создана как раз для того, чтобы вы прекрасно понимали что мы делаем и зачем. Мы убираем все препятствия и неточности, что поможет нам лучше делать наше дело.
Документация будет постоянно меняться, дополняться, актуализироваться и структурироваться. Примерно на данный момент она будет состоять из (каждый документ отдельно расписывать не буду, за подробностями к Артёму):
OKR
Ссылки
Концепция и ограничения
SRS
Глоссарий
Дизайн
Лендинг
ui/ux Прототипы
Прототип “…“
Прототип “…“
ui/ux Макеты
Макет “…“
Макет “…“
Карта страниц
Платформа
ui/ux Прототипы
Прототип “…“
Прототип “…“
ui/ux Макеты
Макет “…“
Макет “…“
Карта страниц
Диаграммы
bpmn
последовательностей
Архитектура
Интеграционная документация
Концептуальная модель системы
Архитектура системы
Анализ конкурентов
Анализ конкурента “…“
Лендинг
UI/UX платформы
Бизнес-показатели
Отзывы
К разбору
Результаты анализа
Результаты анализа
Спринты
Спринт 1
Груминг
Планирование
Стендапы
Ревью
Ретроспектива
Проблемы
Список проблем
Решение проблемы “…”
Решение проблемы “…”
Важные решения
Разбор решения “…”
Разбор решения “…”
…
Пожелания
Эй, вы все молодцы! Вижу, как каждый вливает свою энергию и крутые идеи в наш проект. Просто космос!
Давайте держать друг друга в курсе, общаться открыто и не бояться делиться своими мыслями. Совместные усилия - наше суперсекретное оружие!
Запоминайте: ошибки - это не провал, а опыт. Давайте учиться на них и расти вместе. У нас впереди много интересного, и вместе мы точно сможем подняться на новый уровень.
Будем как семья - поддерживать друг друга, вдохновлять и творить чудеса. Доверяем друг другу и знаем, что каждый в команде - настоящий герой!
Разрабатываемый нами продукт - это реальная пушка, которая точно будет взрывать интернет и приносить очень много Cash. Сообщества - это новая нефть (не я придумал кстати).
Так что, герои мои, вперед к новым победам! Мы в этом вместе, и вместе мы неуязвимы!
Каждый член команды - это владелец продукта, абсолютно каждый из нас вносит равный вклад в его развитие и создание. Я верю, что мы достигнем великих целей и будем спецами своего дела. Главное стараться и не бояться высказывать свое мнение, так как его точно услышат и точно прислушаются. А если нет, то PM сделает все, чтобы такого не повторилось, даже в ущерб себе. Давайте учиться и развиваться вместе 😃
Литература
Если будет интересна тема гибкой разработки, скрама, управления и тд, то советую почитать:
Марги Каган - Вдохновленные
Scrum. Революционный метод управления проектами - Джефф Сазерленд
Жду конструктивную критику, готов к спорам и обсуждениям 🤯
😱 Комментарий удален его автором...
Попробуй сравнить свою методологию со следующей: каждый человек из команды раз в день пишет в чат то, что сказал бы на стендапе, а каждый другой читает и по мере надобности отвечает в треде.
Накину плюсов последней:
Бонус-поинт: каждый в команде видел эту картинку и способен рассказать, где его задача находится на этом графике
получил такой комментарий в чате тг: "Твоя статья - вольная интерпретация Scrum Guide, по своей сути - ради бога, но интерпретация не есть адаптация под свои нужды, скорее показывает, что ты сам особо не понял, как примерно работать.
в глаза бросаются:
определения (роль product owner, может выполнять pm - на то она и роль)
смысл (ты не делаешь каждые 2-4 недели готовый продукт, ты делаешь итерацию по итогам который создаешь ценность, получаешь обратную связь и адаптируешь - либо направление развития продукта, либо процессы внутри команды или и то, и то)
назначение,
интерпретация ритуалов (дэйлики нужны для синхронизации команды, они не для того, чтобы получить фидбек от кого-то)
Заметки про Яндекс Трекер - окей, видимо ваше личное дело". Недочеты исправлю, погружусь в тему получше. Спасибо
Крайне сложно было прочитать текст. Словно меня швыряли из темы в тему будто я конспект лекции листаю.
Ладно, сказать я вот что хотел. Рулит не какая-то конкретная методология и очередной святой Грааль. Рулит понятная для всех и масштабируемая на несколько команд система. И чем эта система проще - тем стабильнее и комфортнее всем работать.
Неважно скрам или канбан, да хоть Бугаенковские микротаски. Без понимания и опыта построения систем не получится ничего сделать. Будет постоянное перекатывание задач из одного спринта в другой. Или Чайка менеджмент.
Краеугольным камнем затянутых или проваленных проектов как ни странно оказывается менеджмент. В РФ он практически отсутствует потому что не учат ни где ему, а в реальных проектах занимаются прожиганием бюджетов игрой в «мыж семья и строим продукт мечты» и имитацией бурной деятельности.
При сильном и грамотном менеджменте не нужны частые синхронизации звонками. Инженеры вообще прекрасно синкаются между собой в рамках общей задачи. Задача же менеджмента настроить поток задач и обеспечить контроль выполнения.
Почему именно scrum, а не kanban, например?
Выглядит как попытка индоктринации, нет объяснения существующего выбора и критериев, по которым надо взять то или иное, сразу какие-то сильные личности (из прошлого тысячелетия?) давят авторитетом и всё такое.
side note: много где форматирование поехало
С абстрактным скрамом все понятно, методичек в интернетах полно. А какой твой личный опыт? Почему выбрали скрам? Какие элементы посчитали полезными и развили? Какие практики отбросили? Что добавили из других систем или от себя? Какие планы?
Странно. Про Деминга и его вклад в развитие экономики Японии я слышал, про бережливое производство слышал, про kanban (японское слово так-то) тоже слышал, а про то, как Scrum, который сформировался в 1994 году, я не слышал :)
Вообще, я бы очень советовал посмотреть на критику Scrum. Например, послушать выступления Allen Holub:
Ещё бы посоветовал проанализировать границы применимости инструмента. В Scrum явно они не прописаны, а тем не менее, он как и любой инструмент подходит для ограниченного числа контекстов. Можно попытаться их самостоятельно сформулировать исходя из сильных тезисов из гайда, а можно опять же поискать на тему.
Между Scrum и Agile часто ставят знак равенства, а затем начинают делать водопад, разбитый на итерации — в scrum team часто не берут дизайн, аналитику и т.д., а чтобы дизайн и аналитика делали дело, нужен заранее составленный план, чтобы потом запускать спринты по уже отрисованному.
А ещё scrum team начинает очень много времени тратить на то, чтобы обрезать работу так, чтобы она поместилась в итерацию, хотя иногда более выгодная тактика поведения — поставить сложную задачу целиком, а не создавать искусственные границы.
Ну и обязательно — вместо поиска источника неэффективности в процессе команда начинает считать велосити и думать, как бы начать оценивать лучше. Улучшать методику оценки != систематически работать над эффективностью.
Но глобально за тягу разобраться — большой респект! Если будешь не забывать критически смотреть на вещи и периодически спрашивать себя «почему я уверен, что то, что я утверждаю, может работать», то всё будет великолепно)
ДА!
И именно по этой причине, scrum бывает приносит больше вреда, чем пользы. Постоянное использование конкретного фреймворка и следование его принципам это антигибкость.
Лучший скрам это тот скрам, из которого взяли только нужное под текущий момент, или не брали ничего. Лучший скрам тот — практикам которого прекратят следовать, когда больше не будет актуально.
В реальной жизни, к сожалению, обычно так не работает, и поэтому появляются такие посты.
Пока что, честно говоря выглядит карикатурно, как будто кто-то решил написать злую пародию на "манифесты" менеджеров, внедряющих скрам.
Если попытаться выделить главные проблемы этого документа, то это будет:
Или предположим, я никогда не писал документацию ( кстати, как вы думаете почему? ), а теперь это обязательно, потому что иначе "Ты не профессионал, ты не уважаешь коллег и мы рискуем потерять управление над проектом". Что??? У меня этого "управления над проектом и не было", а заход типа "ты меня уважаешь" какой-то совсем глупый.
Понятно, что даже с такой структурой документа народ будет ходить на дейлики и писать что-то в вики ( ну, куда они денутся ... ), но вы можете сделать лучше, гораздо лучше, если подумаете о людях, которые будут читать этот документ, что им нужно, что интересно, чего они боятся.
Ну и буллшит-фразочки россыпью:
Кроме того, что это буллшит, на западе за такие заходы можно и на семинар по Cultural Sensivity отправиться
Буллшит!
Бууууллшиииит!
Рано. Еще не заинтересовали, а уже рандомные факты вываливаете.
Не хочу знать про вашу личную жизнь, хочу знать, что лично мне будет от внедрения скрама
Как говорят у нас в деревне - "чувак, это кринж"
Тони Роббинс? Аяз Шабутдинов?
Definition missed ...
Кто вам это сказал?
Просто удалите это ...
В целом, Артем, мотивирующий документ - жанр очень сложный. Возможно, пока что есть смысл плотнее пообщаться с командой, понять уровень знаний ( может быть они вас скраму научат ), ответсвенности, какие есть проблемы.
В любом случае сама идея попробовать систематизировать свои мысли и написать такой документ - отличная, а то, что вы выставили его на публичную критику очень смело. Категорически желаю вам удачи и в карьере и в вашем грандиозном проекте :)
В начале карьеры всегда хочется найти что-то, что всегда будет работать и будет простым - скрам, дейлики, ретро, но потом понимаешь, что все команды разные.
Как уже отметили - лучшее решение - то, которое работает (как бы странно это не звучало)
Даже при работе чисто по скраму команды могут быть на разном уровне зрелости, коммуницировать синхронно/асинхронно и все это влияет
Для меня сейчас главными принципами является взаимоуважение и культивация безопасной среды, но кажется и это не панацея)
Я 13 лет назад был скрам-мастером, но вроде с тех пор разобрались, что скрам не работает и скорее похож на коммунизм, который никто так нигде и не построил.
И теперь используют нечто агильно-камбанное, где от скрама остались только итерации и бэклог.
Я за этим не следил последние годы, может, что-то поменялось с тех пор и произошёл скрам-ренесанс?
А может, стоило все же переработать для статьи-то? Выкинуть например кусок про планируемую структуру документации и дифирамбы членам команды.
Вашему проекту в целом ок, что вы зашарили в паблик пусть и анонимизированный, но внутренний документ?