Comments 29
Очень хороший текст, спасибо автору! Мне ближе Scrum, он как-то хорошо ложится на проект. Но идея комбинирования двух подходов тоже интересная. Мы однажды практиковали что-то подобное скраму в проекте, тогда еще не было такого названия. Просто составляли список задач, которые выдавали пользователи, затем оценивали их сложность по времени предполагаемой реализации. После чего выбирали задачи для реализации. Обычно брали для начала что-то среднее по сложности для разогрева. Слишком тяжелые могли провалить, а слишком легкие ничему не учили и не разогревали. Из своих ощущений помню 3: 1) Такой анализ помогал выстраивать последовательность выполнения, видишь общую картину и какие-то связи между задачами; 2) мелкие задачи выполняли время от времени, причем даже не по причине логики, а просто для настроения между более сложными задачами. Причем сами программисты предложили их группировать и выполнять типа небольшими пачками; 3) программисты наглядно увидели, что работа руководителя проекта - это не пустое времяпровождение, а реальная работа, где надо собрать информацию, сгруппировать и проанализировать ее, а затем принимать решения, причем зачастую не имея полной информации, т.е., приходилось брать ответственность на себя и принимать груз возможной ответственности за ошибки. Потому как это делалось не где-то в отдельном кабинете, а вместе с ними. Т.е., они получали хороший менеджерский опыт. Ну и наградой конечно был момент, когда приходили к пользователям и строго по списку показывали, что сделано. И они, и мы получали кучу позитивной энергии. P.S. Там по ходу есть одна неточность в таблице, п.9, Поток работы, перепутаны столбцы.
Очень хороший текст, спасибо автору! Мне ближе Scrum, он как-то хорошо ложится на проект. Но идея комбинирования двух подходов тоже интересная. Мы однажды практиковали что-то подобное скраму в проекте, тогда еще не было такого названия. Просто составляли список задач, которые выдавали пользователи, затем оценивали их сложность по времени предполагаемой реализации. После чего выбирали задачи для реализации. Обычно брали для начала что-то среднее по сложности для разогрева. Слишком тяжелые могли провалить, а слишком легкие ничему не учили и не разогревали. Из своих ощущений помню 3: 1) Такой анализ помогал выстраивать последовательность выполнения, видишь общую картину и какие-то связи между задачами; 2) мелкие задачи выполняли время от времени, причем даже не по причине логики, а просто для настроения между более сложными задачами. Причем сами программисты предложили их группировать и выполнять типа небольшими пачками; 3) программисты наглядно увидели, что работа руководителя проекта - это не пустое времяпровождение, а реальная работа, где надо собрать информацию, сгруппировать и проанализировать ее, а затем принимать решения, причем зачастую не имея полной информации, т.е., приходилось брать ответственность на себя и принимать груз возможной ответственности за ошибки. Потому как это делалось не где-то в отдельном кабинете, а вместе с ними. Т.е., они получали хороший менеджерский опыт. Ну и наградой конечно был момент, когда приходили к пользователям и строго по списку показывали, что сделано. И они, и мы получали кучу позитивной энергии. P.S. Там по ходу есть одна неточность в таблице, п.9, Поток работы, перепутаны столбцы.
Канбан, скрам и водопад в своей сути отличаются атомарностью отчётности - одна задача, пакет задач, все задачи. Отчётность подбирается под проект. Остальной инструментарий - бантики - подбирается по необходимости и степени следования карго культам. Пока не видел компании, которая следует им до точки.
Согласен, каждая методология имеет свои уникальные аспекты и подходы к отчетности. Важно выбирать инструменты, которые действительно работают для вашей команды и проекта. Гибкость и адаптация — ключ к успеху!
Нет. Отчётность тут вообще ни при чём. Ее может даже не быть вовсе. Отличаются они подходом к планированию и организации работы. И это ни разу не "бантики".
Вы описали скорее Канбан. К Скраму указанный подход не имеет никакого отношения (благодаря чему, скорее всего, и удалось получить пользу).
Вы голосовали по карме мне? Если да, то не могли бы вы объяснить причину?
Данная статья не содержит никакой полезной или новой информации, зато содержит множество ошибок, написана без особого понимания как Скрама, так и Канбана, противоречит даже скрам-гайду.
Более того, подобных сравнений и так очень много в интернете (и даже на хабре), причем гораздо более качественных. Т.е. проблема не в каких-то заблуждениях автора, а в полном безразличии к качеству предоставляемых материалов, потому и минус в карму.
В отметке по карме вы указали не конструктивное общение - это полностью противоречит вашему нынешнему комментарию. Это означает, что причина была указана неверно. Спасибо.
Теперь, по поводу вашего текущего комментария с которым я Полностью Несогласен. Уточните, где именно вы видите противоречие со скрам гайдом? Поделитесь более детальной информацией, чтобы мы могли лучше понять вашу точку зрения.
Так публикация статей без содержания - это и есть неконструктивное общение, так что причина указана верно. И как-то при такой реакции не возникает никакого желания указывать на ошибки, тем более каким-то странным "мы".
Сначала скажите, что в данной статье нового относительно примерно десятка прочих статей про скрам и канбан, которые опубликованы на хабре. Читали ли вы их вообще перед публикацией собственной? Если нет, то почему решили, что скажите что-то новое?
Понятно. Противоречия со Скрам гайдом вы привести неможите. Общение, на мой взгляд, происходит либо в сообщениях, либо в комментариях. Я с вами лично не общался во время вашего голосования, и вы говорили про ошибки, соответственно, нужно было выбирать этот пункт. По остальным вопросам я не согласен. Если можете, раскройте тему подробнее и напишите пост/статью — Мы все почитаем!
Да, вы правы, это скорее было похоже на Канбан, потому как не было спринтов с ограничением по времени. Но и визуализации тоже особой не было, просто список задач в Excel. Единственное, что вспомнилась ещё одна ассоциация, что если задача не решалась в течение 2-х недель, то приходилось с ней что-то делать. То ли дробить на более мелкие, то ли как-то перестраивать общую картину.
Большое спасибо за ваш комментарий! Очень рад, что текст вызвал у вас положительные эмоции. Действительно, Scrum – отличный подход, и ваша идея комбинирования методов выглядит весьма перспективно. Здорово, что у вас был опыт, который помог команде не только организовать работу, но и получить ценный управленческий опыт. Такой анализ действительно позволяет лучше видеть общую картину и налаживать связи между задачами. И, конечно, ничто не сравнится с той позитивной энергией, которую приносит удовлетворение от выполненной работы и благодарность пользователей. Спасибо, что поделились своим опытом! P.S. Поправил 9 пункт в таблице!
Если еще короче - самая основная основа (это частично упомянуто в разделе Демо, статьи): результат работы команды. т.н. Артефакты или деплой:
в Скраме происходит в конце спринта, т.е. "деплоим, то что готово на момент времяни",
в Канбане - в момент завершения пула фичей - "Деплоим, когда готово заданный список задачь"
Хотел бы у вас спросить, как практического знатока систем планирования/ведение проектов, какие есть системы (может менее известные или экзотические или настраиваемые) где объем проекта, подпроекта и даже задачи просчитать не получается?
Для исследовательских и изобретательских проектов.
Каждый раз ситуация одна и та же - объем работ порой равен полному рандому. Задача может занять несколько часов, а может пару лет, т.к. "внезапно" (а скорее предсказуемо) натыкается на неисследованный ключевой момент(ы).
Но при этом все равно нужно как-то вести проекты. При чем не один, а сразу несколько.
Сейчас для ведения подобного типа проектов и планирования используются "палки-копалки" в виде гугл доков и таблиц. Пробовал разные системы - в одних упирается в том, что нужно точно фиксировать время/объем проекта, задач. В других - в том, что нужно точно знать структуру (разбитие всего проекта через древовидные структуры до микрозадач).
Но и то и другое - "облачно, туманно", то есть не определено.
не аффтор но позволю себе написать свои мысли: вообще как раз скрам или ХП считаются подходящим для проектов с большой степенью неопределенности. В них это решается за счет итераций - если делаем не то - быстро замечаем и исправляем. Проблема, которую вы описали (задача может затянуться на пару лет) не решается никакой системой ведения проектов, все они направленны на ускорение типовых задач (понятно что сделать новую программу это новая но понятная задача). Единственное что я вижу - возможно проблема в недостаточном декомпозировании сложных задач (гуглите ADR, инициация требований)
Единственное что я вижу - возможно проблема в недостаточном декомпозировании сложных задач (гуглите ADR, инициация требований)
Благодарю - гуглю на сию тему. Походу нужно назначат какие-то метрики чтобы останавливать процессу углубления в изучаемую под-задачу, т.к. всегда не ясно достаточно или недостаточно она изучена.
вообще как раз скрам или ХП
Подскажите, что означает ХП?
Если возникает некая неопределенная задача, связаннная с ресерчем чего бы то ни было, то я обычно сначала делаю задачу на ресерч и отвожу на нее некое определенное время, которое мы с командой посчитаем достаточным для иследования исхдной проблемы.
Результатом выполнения этой задачи будут шаги по решению проблемы (то есть список конкретных задач) и оценка трудоемкости.
Каждый раз ситуация одна и та же - объем работ порой равен полному рандому. Задача может занять несколько часов, а может пару лет, т.к. "внезапно" (а скорее предсказуемо) натыкается на неисследованный ключевой момент(ы).
Я думаю, что тут дело не системе ведения проектов, а в организации работы, декомпозиции задач, отслеживании прогресса. Задача может быть в работе два года по двум основным причинам:
она сложная и имеет много подзадач
она часто блокируется
если есть что-то ещё - скажите
так вот, если упрощенно, на условную доску todo|work|done надо
выносить более маленькие задачи
добавить статус blocked
если хотите поговорить об этом, приглашаю написать в личку (за советы денег не беру)
Первый раз услышал про СкрамБан, и приятно удивился. Значит мы не единственные, кто берет известные практики, но не следует им. Потом это всё перемешивается, и получившийся монстр, который не имеет названия. Но ведь главное, чтобы все были счасливы, правда?!
Кстати, когда пытались строго следовать скраму, жизнь в проекте была очень изнурительной. Всё время казалось, что что-то висит над головой, а мы постоянно опаздываем. Потом вспоминая этот опыт я даже увидел наглядное объяснение почему мне не нравится этот подход. Спринт - это очень быстрый бег, когда тебе надо пробежать короткую дистанцию. Но ведь разработать программный продукт - это не короткая дистанция. Попробуйте пробежать марафон, нарезав его на стометровки, и бежать каждую как спринт... А потом удивляются, почему все айтишники говорят про выгорание.
Я приверженец канбана для опытных и сработанных команд с понятным скоупом возможных задач по продукту.
Вижу регулярно коллег соседей, работающих по скраму. Так вот мы с командой даем результат для бизнеса существенно быстрее, так же быстрее переключаемся на более приоритетные задачи, но работать как на конвейере без пауз для людей не просто, выгорают. Ну и у менеджера команды работа с бэклогом считай постоянная при канбане, потому что нужно нагружать команду задачами, а даже бизнес не всегда поспевает, тогда приходиться набрасывать оптимизации, тюнинг, рефакторинг в промежутках между фичами и релизами для бизнеса.
Ещё, если у вас есть работа с внешним вендором в команде от которой зависит и ваша работа, то как по мне спринты при таком варианте вообще не подходят, ну или вы будете для бизнеса крайне медленными.
По моему опыту скрам лучше заходит, когда есть большой беклог и нужно откусыать от него понятными кусочками, чтобы итеративно идти к конечной реализации продукта. Канбан лучше, когда продукт уже живет, и нужно его развивать: выполнять как стратегические задачи по роад-мэпу, так и чинить проблемы, возникающие на проде.
Статья затрагивает механические аспекты Scrum, но недостаточно освещает его принципы и ценности, что искажает представление о данном фреймворке.
Product Owner: отвечает за создание и приоритезацию бэклога продукта.
Главная ответственность PO — максимизация ценности продукта для клиента. Создание и приоритизация бэклога — это лишь часть его задач.
Обзор спринта: встреча для демонстрации завершенной работы(демо) заинтересованным сторонам.
Целью Sprint Review является не только демонстрация инкремента, но и совместная инспекция с заинтересованными сторонами, а также адаптация бэклога продукта на основе полученного фидбека.
Каждый спринт — это возможность для инспекции и адаптации.
На самом деле таких возможностей в Scrum много. Например, Daily Scrum позволяет инспектировать прогресс команды относительно цели спринта и адаптировать план на день. Sprint Review фокусируется на инспекции инкремента и адаптации бэклога продукта и др.
Скрам изначально не приветствует изменения объема задач, включенных в спринт. Дело в том, что если мы определили цель для конкретного спринта и команда взяла на себя ответственность за ее достижение
Scrum Guide против тех изменений, которые ставят под угрозу достижение цели спринта. Если возникает дополнительная задача, которая нужна для достижения поставленной цели, то команда берет ее в текущую итерацию.
Как мне кажется, не совсем верно сравнивать скрам и канбан в лоб. Канбан, если грубо, предназначен для нахождения проблем в потоке нематериальной работы. Так что вы можете использовать Канбан поверх скрам, и поверх вотерфолл.
Скрам vs Канбан: Погружение в Agile, плюс памятка для проектных менеджеров