Все знают, что канбан-метод — это стикеры и доски. На самом деле, все несколько сложнее и глубже. Чем этот метод может помочь руководителю, обсудим на совместном вебинаре DataLine и ScrumTrek.

Я и мои коллеги по работе для внутренних сотрудников компании, в которой я работаю, периодически готовим небольшие статьи, где разбираем различные кейсы по гибким подходам, включая и кейсы использования Канбан-метода для совершенствования и управления процессами. Такие статьи мы называем Agile-shorts. И я подумал, "А почему бы не открывать свои статьи и для более широкой аудитории?" И, вот, сегодня я публикую первую свою статью из этой серии.

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

"Мы выбираем, нас выбирают
Как это часто не совпадает"
(с) песня из к/ф «Большая перемена»

Всем привет! С вами рубрика Agile Shorts и сегодня мы с вами поговорим о "Предназначении".

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

Обычная практика при работе с госами - это долгосрочное планирование, тщательное проектирование, разработка по детальным спецификациям, тестирование и релиз раз в три-четыре месяца. Вроде все логично и понятно но, по моему опыту, в современном быстро меняющемся мире работает далеко не идеально. Многие технологические компании (Amazon, Facebook, Netflix и др.) уже отказались от такого каскадного подхода: формируют гипотезы, проводят  множество маленьких экспериментов для их быстрой апробации в бою. Думаете, чтобы разработать ракету нужен детальный техпроект, план и далее сборка по чертежам? Тогда вы сильно удивитесь, если прочитаете, как это делается в SpaceX.  С таким же недоумением со стороны коллег я сталкиваюсь, когда говорю, что мои команды на госпроектах делают каждый день релизы, организуют частые показы заказчику или пользователям. А еще мы не пишем детальных спецификаций и постоянно развиваем инженерные практики. Почему такой подход имеет место быть и приводит к хорошим результатам, расскажу на примере проекта по созданию ГИС Открытый контроль. 

Как же вы планируете без диаграмм Ганта? Почему ваши разработчики не оценивают задачи? Зачем вы делаете частые релизы и частые показы? Что делаете, еcли прилетела срочная задача от заказчика? Какие инженерные практики вам пришлось внедрить, чтобы делать релизы каждый день? Ответы на эти вопросы, а также то, почему мы отказались от Scrum вы найдете в статье.

Привет, я Евгений Степченко, delivery-менеджер Тинькофф. В октябре мы провели Tinkoff Agile Conference про масштабирование изменений и изменения при масштабировании, развитие команд и инженерные практики. Нам важно, чтобы тимлиды, техлиды, менеджеры и эксперты развивались как единое сообщество. Поэтому мы собрали конференцию, позвали профессионалов из разных областей и постарались создать площадку для нетворкинга. Спикеры рассказывали о методах управления, метриках, технических аспектах гибкой разработки и о том, как безопаснее проводить изменения. 

Шесть тысяч зрителей смотрели конференцию онлайн, а двести пятьдесят человек присутствовали в новом для нас формате — живого общения. Участники активно задавали вопросы и вовлечённо работали на воркшопах. Писали в чате, как не хватало живых мероприятий во время пандемии, увозили домой инсайты, а кто-то даже поменял представление о Тинькофф в лучшую сторону.

Я участвовал в подготовке программы мероприятия и помогал с организацией на месте. Хочу поделиться с вами атмосферой конференции и рассказать подробнее про несколько докладов. В конце статьи оставлю ссылки на все записи и подборку фотографий. 

Всем привет! Я Виталий Дощенко, ньюбиз-директор AGIMA. Обычно на Хабре мы рассказываем, как работаем над цифровыми продуктами. Над мобильными приложениями, высоконагруженными системами или чат-ботами. Но только не в этот раз. В этой статье я расскажу, как Канбан-метод помог нам устранить последствия пожара. Не того пожара, где куча задач и ты ничего не успеваешь, а самого настоящего пожара, который чуть не уничтожил дом моей семьи.

Тимлиду постоянно приходится отвечать на вопрос «когда сделаете?» или «когда будет готово?». И часто для ответа на этот вопрос нужно отвлечь от работы своего сотрудника, обсудить с ним задачу и только после этого дать ответ.

Не факт, что ответ совпадет с реальностью. И любой руководитель знает, что для того, чтобы гарантированно уложиться в названый срок, нужно заложить минимум трехкратный запас времени. Заказчики этот принцип тоже знают и поэтому стремятся срезать срок, насколько это возможно. Тимлиду опять приходится отвлекать сотрудника и обсуждать с ним «варианты оптимизации сроков выполнения». Потом цикл повторяется до тех пор, пока кто-то — либо заказчик, либо тимлид — не упрется рогом, не продавит свое решение.

Недовольными, как правило, оказываются все. Тем не менее все постоянно играют в эту игру, и никто никому не верит.

Однако, если использовать исторические данные по сделанным ранее проектам и задачам, то можно узнать с 80% вероятностью срок исполнения задачи любого типа. Никакой магии. Просто математика и немного теории вероятностей :)) В этом суть Канбан-метода.

Привет, Хабр! Я Денис Бартоломе, Agile-коуч Сбера.

Вся эта статья ― обсуждение последней, седьмой, версии руководства к Project Management Body of Knowledge (PMBoK) и её влияния на прекрасный мир проектного управления. PMBoK ― свод знаний, максимально полное изложение информации по управлению проектами. Этими «священными скрижалями» современных управленцев ведает Институт управления проектами (Project Management Institute, или сокращённо PMI).

В 2021 году свод знаний кардинально изменился. Ну, например, в последней версии популярного стандарта основным объектом управления стал не проект, а производственная система организации. В этой статье я рассказываю о влиянии этих изменений на мир проектного управления, а также о том, какую во всём этом роль играют Agile и Kanban. Если тема интересна, приглашаю под кат.

Привет всем, кто интересуется Канбан‑методом, и кто хочет познакомиться поближе с одним из его инструментов — S.T.A.T.I.K.

Задумка этой статьи появилась тогда, когда в очередной раз ко мне кто‑то подошел с вопросом: «Мы собираемся делать СТАТИК, где про это можно почитать?»

И я решил поделиться личным опытом и интерпретацией этого инструмента с широкой аудиторией, ну и за одно, чтобы потом у меня была возможность просто кидать другим ссылку на эту статью, а не посылать читать Майка Барроуза или гуглить по сети другие описания, которые потом еще надо комментировать, исходя из собственного консалтингового опыта.