Да, фактически это и есть создание дополнительного проекта. Возможно мое мнение предвзято — я привык работать на больших проектах, которые было бы удобнее «разбить» на несколько поменьше.
По поводу применимости Канбана к большим проектам, возможно все упирается в психологию малых групп — формальная группа численностью более 8 человек стремится к разбиению на две неформальных. Ну или принцип Паркинсона — кабинет численностью более 5 человек теряет эффективность :)
Конечно, это не значит что большой проект нежизнеспособен. Просто с моей точки зрения, управлять двумя небольшими прозрачнее и удобней чем одним большим.
Эффект привязки — особенность оценки числовых значений человеком, из-за которой оценка смещается в сторону начального приближения. В психологии есть похожий термин, забыл какой :) Проще говоря мы ожидали что звонки сработают (окажут положительный эффект). После появления положительного эффекта мы инстинктивно считаем что сработали звонки (т.е. наше первоначальное приближение). В то же время, нельзя исключать что на удачный исход события повлияли другие, неизвестные нам причины.
С большим уважением отношусь к блогу Стратоплан. Тем не менее, несколько громкий заголовок, к тому же не очевидно, что именно звонки сыграли ключевую роль. Вывод больше похож на эффект привязки.
В США не немецкое а общее право. Тролли же наживаются не на системе права, как таковой, а на отсутствии практики оплаты судебных издержек выигравшей стороны проигравшей стороной.
В США такая практика отсутствует формально для того чтобы рядовые граждане не боялись судиться с корпорациями и прочими богатыми субъектами, т. к. рядовой гражданин может пользоваться дешевым или государственным адвокатом, и не должен нести риски по оплате огромных гонораров, которые оплачивают корпорации юридическим компаниям.
В общем, обе системы не идеальны.
Если система не сбалансирована для такой вариации задач, почему не выбрать вариант «переработать систему»? Разделение на специализированные команды — один из вариантов, и он работает. Automation не решает проблем тестирования, и в случае если тест повторяется не более 3 раз (примерная эмпирическая цифра), то усилия на автоматизацию могут не окупиться.
Дополнительный пример из жизни это специализированные задачи де-факто, которые не требуют тестирования или девелопмента. Пример для задач которые не требуют девелопмента — интеграционное тестирование с новой версией сервиса, от которого зависит наше приложение. Такая задача «минует» фазу разработки и не будет отвлекать людей от их дел :)
Конечно, этот вариант не единственный. Возможно, специфика проектов, на которых я работал не типична для большинства других проектов. Но пока единственной слабой стороной такого решения мне видится необходимость заведения лишней доски :)
Поэтому удобнее разделить группы по специализации. Получается своеобразный аналог производственной линии с гибкой связью. К примеру, есть группа разработки, которая производит фичи со скоростью 6 фич в неделю. Эти фичи переходят в группу тестирования, которая тестирует со скоростью 4 фичи в неделю. На выходе «главный конвейер» (к примеру билд-инженеры) ожидают 5 фич в неделю. «Затык» становится сразу очевиден (по каким-то причинам тестирование идет медленнее чем ожидается, а разработка быстрее) и эту проблему можно решить достаточно оперативно.
Я встречал «жесткий» Канбан, в котором состояние «в разработке» разбито на состояния «в разработке», «в тестировании», однако такой подход вносит следующие трудности:
— как задавать «лимит»? для каждого состояния в отдельности, или для всех одинаковый? В любом случае, возможна ситуация что разрабатывать будут быстрее чем тестировать (или тестировать быстрее чем деплоить, и т.д.), что в итоге лишь усложнит процесс управления.
— в идеале, все задачи должны быть разбиты на «равные куски» работы, с каким-то определенным временем на выполнение. И для каждого этапа работы обычно эти куски различные. С возрастанием количества состояний падает прозрачность процесса.
Возможно это субъективные критерии, но мой опыт показал что разделение команд на разные Канбан-доски принесло позитивные изменения.
Любая методология должна прежде всего упрощать процесс разработки, а не поддерживать сама себя. Если какая-то методология не помогает — значит что-то не так :)
Согласен, пример натянутый. В реальной жизни в данной ситуации возможно более подойдет другая методология. В продолжении я планирую расписать Kanban применяемый на Toyota, «книжный» вариант для разработки ПО, и примеры из реальной жизни, где Kanban пришелся к месту. (В основном — это команды автоматизации тестирования, «обслуживающие» несколько отдельных групп тестирования)
По поводу того, что любая задача может быть сдвинута — в классическом Kanban такого происходить не должно. Возвращаясь к аналогии с производством автомобилей — производственная станция не может прекратить производство зеркала без существенных потерь времени, поэтому из «in progress» путь в backlog должен быть только один — задача заблокирована и не может быть выполнена.
Правомерность использования термина «методология» применительно к Kanban я планирую рассмотреть в продолжении статьи.
Да, ситуация к нам благосклонна :) Однако подобный подход может «аукнуться» в периоды кризиса, или стать препятствием на пути к карьерному росту (хотя не всем оно и надо)
Мне кажется что налицо старый, как мир, конфликт:
-желание делать любимое дело, со своими критериями красоты (творчество)
-выполнение работы по найму
Мне понравилась аналогия с музыкой, приведенная выше. Подобное разделение, в общем, есть в любом искусстве. Грубо — попса, созданная с целью делать деньги, и авангард (андеграунд, народные напевы и.т.д.) созданные ради себя самих.
Проблема в том, что программисты (в широком смысле слова — сотрудники, занятые в разработке ПО), в большинстве своем, очень любят свое дело. Поэтому стараются делать его наилучшим (с их точки зрения) образом. А с точки зрения руководителя/заказчика нужно чтоб работало ТОТЧАС. Стройные иерархии классов конечному пользователю не видны, и польза от проработки архитектуры «на будущее» — не очевидна.
Тем не менее, программисты вряд ли захотят делать «ширпотреб». Для себя я нашел любопытное решение — я занимаюсь разработкой дома для души. А на работе перешел из разработки в тестирование :)
По поводу применимости Канбана к большим проектам, возможно все упирается в психологию малых групп — формальная группа численностью более 8 человек стремится к разбиению на две неформальных. Ну или принцип Паркинсона — кабинет численностью более 5 человек теряет эффективность :)
Конечно, это не значит что большой проект нежизнеспособен. Просто с моей точки зрения, управлять двумя небольшими прозрачнее и удобней чем одним большим.
В США такая практика отсутствует формально для того чтобы рядовые граждане не боялись судиться с корпорациями и прочими богатыми субъектами, т. к. рядовой гражданин может пользоваться дешевым или государственным адвокатом, и не должен нести риски по оплате огромных гонораров, которые оплачивают корпорации юридическим компаниям.
В общем, обе системы не идеальны.
Дополнительный пример из жизни это специализированные задачи де-факто, которые не требуют тестирования или девелопмента. Пример для задач которые не требуют девелопмента — интеграционное тестирование с новой версией сервиса, от которого зависит наше приложение. Такая задача «минует» фазу разработки и не будет отвлекать людей от их дел :)
Конечно, этот вариант не единственный. Возможно, специфика проектов, на которых я работал не типична для большинства других проектов. Но пока единственной слабой стороной такого решения мне видится необходимость заведения лишней доски :)
Я встречал «жесткий» Канбан, в котором состояние «в разработке» разбито на состояния «в разработке», «в тестировании», однако такой подход вносит следующие трудности:
— как задавать «лимит»? для каждого состояния в отдельности, или для всех одинаковый? В любом случае, возможна ситуация что разрабатывать будут быстрее чем тестировать (или тестировать быстрее чем деплоить, и т.д.), что в итоге лишь усложнит процесс управления.
— в идеале, все задачи должны быть разбиты на «равные куски» работы, с каким-то определенным временем на выполнение. И для каждого этапа работы обычно эти куски различные. С возрастанием количества состояний падает прозрачность процесса.
Возможно это субъективные критерии, но мой опыт показал что разделение команд на разные Канбан-доски принесло позитивные изменения.
Любая методология должна прежде всего упрощать процесс разработки, а не поддерживать сама себя. Если какая-то методология не помогает — значит что-то не так :)
По поводу того, что любая задача может быть сдвинута — в классическом Kanban такого происходить не должно. Возвращаясь к аналогии с производством автомобилей — производственная станция не может прекратить производство зеркала без существенных потерь времени, поэтому из «in progress» путь в backlog должен быть только один — задача заблокирована и не может быть выполнена.
Правомерность использования термина «методология» применительно к Kanban я планирую рассмотреть в продолжении статьи.
-желание делать любимое дело, со своими критериями красоты (творчество)
-выполнение работы по найму
Мне понравилась аналогия с музыкой, приведенная выше. Подобное разделение, в общем, есть в любом искусстве. Грубо — попса, созданная с целью делать деньги, и авангард (андеграунд, народные напевы и.т.д.) созданные ради себя самих.
Проблема в том, что программисты (в широком смысле слова — сотрудники, занятые в разработке ПО), в большинстве своем, очень любят свое дело. Поэтому стараются делать его наилучшим (с их точки зрения) образом. А с точки зрения руководителя/заказчика нужно чтоб работало ТОТЧАС. Стройные иерархии классов конечному пользователю не видны, и польза от проработки архитектуры «на будущее» — не очевидна.
Тем не менее, программисты вряд ли захотят делать «ширпотреб». Для себя я нашел любопытное решение — я занимаюсь разработкой дома для души. А на работе перешел из разработки в тестирование :)