Вы знаете, книга читается на удивление легко! Я долго держала ее на todo-read полке, потому что очень уж толстая, одним внешним видом наводила уныние. В итоге взялась просто потому, что пора! Да и надоели простые бизнес-книги, хотелось что-то про нашу ИТ область уже почитать.
А в итоге прочитала быстрее, чем некоторые бизнес-книги обычного размера. Шрифт не сильно мелкий, автор пишет легко и достаточно интересно. Каждая глава занимает около 10 страничек, что удобно. В итоге получалось читать по 1-2-3 главы за раз.
В конце каждой главы есть выводы. Это тоже довольно удобно =)
Важно понимать, что канбан — это не строго gitflow или строго доска «Один пришел, второй ушел». Нет. Канбан как раз очень гибкий. Он подстраивается под организацию, команду, процессы. В одной большой компании может быть десяток разных канбан-досок, и все будут чем-то отличаться.
А то у нас как-то зашел разговор про канбан, и сразу стали видны стереотипы:
И в идеале для gitflow должна быть роль (пусть и переходящая) "Вливатель в транк"
Выделенный человек отсматривает push-реквесты и вливает в транк.
В больших организациях это норм, а у нас народу мало, всем нужно работать а не штаны протирать.
Я против канбана )
А в книге автор как раз делает упор на то, что внедрение канбана — это внедрение небольших изменений в процесс. Чтобы не было так, что "с сегодняшнего дня мы живем по новому и точка", ведь такие процессы команда чаще всего отвергает. А вот потихоньку что-то внедрять, это может сработать.
И, как пишет автор: «Вам разрешается попробовать Канбан, модифицировать свои процессы, быть другими. Ваша ситуация уникальна. Вы можете разработать свое решение, оптимизированное под вашу компанию, вашу команду, ваш проект».
Рецепт успеха
Есть у автора и свой рецепт успеха. Это подсказка для менеджера, как потихоньку перейти на канбан, не вызывая сильного сопротивления команды, но давая эффект. Всему свое время, в каждый момент надо сосредоточиться на чем-то одном.
Этапы развития от автора:
- Концентрация на качестве.
- Снижение количества незавершенных задач.
- Частые релизы.
- Баланс требований и пропускной способности.
- Приоритезация.
- Борьба с источниками вариативности для улучшения предсказуемости.
Так что если у вас качество УГ, начните с него 
А то и правда, некоторые начинают пробовать жить вообще по другому, а потом жалуются, что ничего не получилось. Лучше начать с одной проблемы, а потом переходить дальше. Вы просто не сможете доказать заказчикам, что им стоит перейти на новые вехи планирования, если вы не можете обеспечить их качественными релизами.
А вообще автор рассказывает истории, как он в итоге добился от заказчиков такого, что нет четких обещаний «мы сделаем в этом релизе вот эти 15 фич». Вместо этого разработчики берут 2 новых фичи в текущий релиз. Как только сделают, освобождается место в беклоге и заказчики принимают решение, что будет делаться следющим.
Заказчики знают, что получат этот функционал максимум через пару месяцев. Потому что смотря в какой релиз он попадет, может, и в текущий. Но они знают максимальный срок и это уже кое-что. Плюс они каждую неделю принимают решение, какая фича для них наиболее приоритетна в ближайшее время.
Конечно, тут есть свои проблемы. Одно дело, если заказчики — это представители одной компании, просто разных подразделений. И тогда маркетинг и бизнес-пользователи просто договариваются, «сегодня моя фича, через неделю твоя». А как быть с коробочным продуктом? Не совсем понятно.
Но в любом случае переход на такое планирование возможен только при огромном доверии между заказчиком и исполнителем. А добиться его можно только тогда, когда вы начнете уделять внимание качеству и следить за тем, чтобы держать свое слово. Как-то так.
Стендапы
Конечно, не обходит автор стороной и общее описание процессов на конкретных примерах из жизни. В том числе и про ежедневные митинги пишет. Но пишет хорошо — у них в командах митинг на 50+ человек может идти 5-10 минут. И вся команда довольна.
А все почему? А потому, что нет этого правила «Каждый обязательно должен рассказать, что делал вчера, сегодня, какие проблемы». Внимание уделяется разве что красным (заблокированным) элементам. Команда обсуждает, что надо сделать, чтобы их разблокировать и нужна ли в этом помощь. Потому что эти задачи приоритетнее всего остального.
Тут важно только подготовиться к митингу. Так как обычно используют электронные и бумажные доски — одна из какой-нибудь JIRA или другого баг-трекера, а вторая со стикерами для наглядности. Если обновить бумажную вовремя, это сэкномит время.
У нас примерно также получилось. Мы сначала стали собираться реже — не каждый день, а два раза в неделю, а потом перестали обязательно давать слово каждому. А то если вас 6-7 человек, это уже может стать довольно унылым, если ни у кого нет проблем. Получается просто бюрократический отчет, который никому не нужен. А вот десятиминутный митинг на 50-70 человек — это круто! Хотя у нас небольшая команда и меня это радует, но я просто восхищаюсь автором =)
Триаж
Триаж — медицинский термин, чтобы классифицировать поступающих больных. Исходно применялся в военно-полевых условиях, где пациентов делили на 3 категории:
Стендапы
Конечно, не обходит автор стороной и общее описание процессов на конкретных примерах из жизни. В том числе и про ежедневные митинги пишет. Но пишет хорошо — у них в командах митинг на 50+ человек может идти 5-10 минут. И вся команда довольна.
А все почему? А потому, что нет этого правила «Каждый обязательно должен рассказать, что делал вчера, сегодня, какие проблемы». Внимание уделяется разве что красным (заблокированным) элементам. Команда обсуждает, что надо сделать, чтобы их разблокировать и нужна ли в этом помощь. Потому что эти задачи приоритетнее всего остального.
Тут важно только подготовиться к митингу. Так как обычно используют электронные и бумажные доски — одна из какой-нибудь JIRA или другого баг-трекера, а вторая со стикерами для наглядности. Если обновить бумажную вовремя, это сэкномит время.
У нас примерно также получилось. Мы сначала стали собираться реже — не каждый день, а два раза в неделю, а потом перестали обязательно давать слово каждому. А то если вас 6-7 человек, это уже может стать довольно унылым, если ни у кого нет проблем. Получается просто бюрократический отчет, который никому не нужен. А вот десятиминутный митинг на 50-70 человек — это круто! Хотя у нас небольшая команда и меня это радует, но я просто восхищаюсь автором =)
Триаж
Триаж — медицинский термин, чтобы классифицировать поступающих больных. Исходно применялся в военно-полевых условиях, где пациентов делили на 3 категории:
- умирающие, кому оказать помощь уже нельзя;
- те, кто может выжить только при неотложной помощи;
- и те, кто, скорее всего, останется в живых и без срочной помощи.
Похожую классификацию стоит проводить и ошибок: что исправить в этом релизе, а что подождет?
И даже для беклога — что из этих фич действительно нужно и важно, а что подождет?
Резюме
Книгу рекомендую, ее очень полезно почитать и подумать. Помедитировать — как это можно было бы применить в нашей организации? Что бы нам подошло? А как вообще у нас устроен процесс?
Особенно мне нравится сама идея того, что канбан — это процесс плавного перехода из одного состояния в другое. А не так, что "завтра мы живем по скрам и точка". Смотрим, что плохо, потихоньку улучшаем.
Как в Toyota, где каждый рабочий может предложить идею по оптимизации производственного процесса. Пусть она будет небольшой, ну и что? Каждый день разные сотрудники вносят микро-улучшения, а сколько их в итоге набирается за год? Сотни, тысячи! И прогресс становится очевиден.
Так что изучайте гибкие процессы, сравнивайте со своим и думайте, можно ли перенять какую-то практику у коллег, подойдет ли она конкретно к вашей команде.
А книга... Книга хорошая, интересная, рекомендую 
PS: добавила книгу в общий список прочитанных мною книг.
Комментариев нет:
Отправить комментарий