В очередной раз на форуме RSDN.RU возник спор про гибкие методологии и, в частности, канбан. Некоторое время назад я опубликовал статью "Халтура.Ру: Как халтурят отечественные ИТ-консультанты?".
Сегодня мне бы хотелось привести дополнительные аргументы.
Предположим, команда из 6 разработчиков + 1 аниматор + 1 UI-дизайнер + 2 3D-моделлера + 2 2D-артиста делают игру. Как Вы думаете, сколько нужно поставить deliverables к ближайшему майлстоуну? Промежуток между майлстоунами месяц — полтора. В нашем случае количество deliverables — 45.
Каждый deliverable — это feature, которая включает в себя несколько технических и артовых задач. Сколько было таких задач? Порядка 300 технических + артовые, которые я не считал, т.к. ими занимался ведущий артист.
Каждая техническая задача имеет свой estimate (который, согласно отраслевым стандартам варьируется от 4 до 24 часов) и текущий прогресс по нему. Некоторые задачи закрываются с опережением срока. Некоторые — с задержкой, которая связана с обнаружением непредвиденных обстоятельств. Происходит переоценка задач и, как результат, перепланирование работы и перераспределение задач между разработчиками. Нередко случается, что задача одного разработчика переходит к другому из-за того, что первый разработчик погряз в предыдущей своей задаче, а другой — справился со своей быстрее, чем ожидалось.
Ряд задач откладывается из-за того, что арт у художников ещё не готов или продюсеры (о, чудо!) решают полностью переделать дизайн фичи.
Как всем этим управлять при помощи карточек? При таком объёме задач бумажные карточки осыпятся под собственной тяжестью, а электронные канбан-доски будут полностью захламлены.
Представьте теперь, что произойдёт, когда над проектом работают не 10, а 100 человек. А ведь именно так и происходит при разработке больших игр.
Z>Ну, наверное, это можно только составить для какой-то работы, которая постоянно повторяется. Например, делать одинаковые сайты — картинки меняй и всё. Тут и сроки известны, и бюджет и соответствования целям. Ну, или траншею рыть — тоже всё известно.
Вы ошибаетесь. Есть вполне устоявшиеся и апробированные процессы в крупных корпорациях. Они не так известны и популярны, как модные аджайл и канбан, однако предсказуемы и приводят к запланированному результату. Да что там корпорации! Даже американские стартапы используют процессы. И без дизайн-документации и планирования никто и строчки кода не напишет.
Просто это не так весело, как играть в геймификацию и тасовать карточки. Зато — надёжно и практично.
Разумеется, для PR-целей корпорации утверждают, что они следуют тренду и используют аджайл.
Просто надо научится отделять зёрна от плевел. Реальные процессы не светят.
Обсуждение на форуме RSDN.RU можно прочитать здесь.
Сегодня мне бы хотелось привести дополнительные аргументы.
Предположим, команда из 6 разработчиков + 1 аниматор + 1 UI-дизайнер + 2 3D-моделлера + 2 2D-артиста делают игру. Как Вы думаете, сколько нужно поставить deliverables к ближайшему майлстоуну? Промежуток между майлстоунами месяц — полтора. В нашем случае количество deliverables — 45.
Каждый deliverable — это feature, которая включает в себя несколько технических и артовых задач. Сколько было таких задач? Порядка 300 технических + артовые, которые я не считал, т.к. ими занимался ведущий артист.
Каждая техническая задача имеет свой estimate (который, согласно отраслевым стандартам варьируется от 4 до 24 часов) и текущий прогресс по нему. Некоторые задачи закрываются с опережением срока. Некоторые — с задержкой, которая связана с обнаружением непредвиденных обстоятельств. Происходит переоценка задач и, как результат, перепланирование работы и перераспределение задач между разработчиками. Нередко случается, что задача одного разработчика переходит к другому из-за того, что первый разработчик погряз в предыдущей своей задаче, а другой — справился со своей быстрее, чем ожидалось.
Ряд задач откладывается из-за того, что арт у художников ещё не готов или продюсеры (о, чудо!) решают полностью переделать дизайн фичи.
Как всем этим управлять при помощи карточек? При таком объёме задач бумажные карточки осыпятся под собственной тяжестью, а электронные канбан-доски будут полностью захламлены.
Представьте теперь, что произойдёт, когда над проектом работают не 10, а 100 человек. А ведь именно так и происходит при разработке больших игр.
Z>Ну, наверное, это можно только составить для какой-то работы, которая постоянно повторяется. Например, делать одинаковые сайты — картинки меняй и всё. Тут и сроки известны, и бюджет и соответствования целям. Ну, или траншею рыть — тоже всё известно.
Вы ошибаетесь. Есть вполне устоявшиеся и апробированные процессы в крупных корпорациях. Они не так известны и популярны, как модные аджайл и канбан, однако предсказуемы и приводят к запланированному результату. Да что там корпорации! Даже американские стартапы используют процессы. И без дизайн-документации и планирования никто и строчки кода не напишет.
Просто это не так весело, как играть в геймификацию и тасовать карточки. Зато — надёжно и практично.
Разумеется, для PR-целей корпорации утверждают, что они следуют тренду и используют аджайл.
Просто надо научится отделять зёрна от плевел. Реальные процессы не светят.Обсуждение на форуме RSDN.RU можно прочитать здесь.
Канбан работает в Яндекс.Картинках, там команда в 45 человек, доста у них 1,5 на 6 метров.
ОтветитьУдалитьДля менеджеров есть упрощенные доски по фичам.
В принципе kanban легко декомпозируется: есть общая доска со стадиями, описывающая фичи высокоуровнево и работает на уровне отделов\команд.
В каждом отделе\команде есть своя доска, которая описывает задачи и работает на уровне отдельных людей.
И везде применяется основной принцип kanban - ограничение WIP.
Кстати когда на одном проекте 100 человек и нету никакой внутренней структуры в этой толпе, то любая методология плохо сработает.
Станислав, а чем, например, redmine или jira хуже, чем доска с карточками? Тем более, что такс-трекеры обладают фильтрами, инструментами для поиска, отслеживают историю изменений и т.д. и т.п.
УдалитьНикто не говорит, что у команды нет структуры. Просто за списками фич и технических задач нужно следить, как бы ни структурировались разработчики.
хуже банально ненаглядностью. при наличии сотен отрытых задач в трекере сложнее понять что вообще происходит, чем при наличии доски с сотнями карточек. ключевое слово "вообще". в трекере надо обладать чорным поясом кунг-фу по составлению отчетов, чтобы понять хоть что-то.
Удалитькроме того доска всегда на виду. это создает еще и моральный аспектведь программист начинает видеть что ему надо сделать и все остальные тоже. это неявный публичный commitment, который повышает эффективность. а если еще стенд-апы проводить регулярно, то возможности увильнуть нету.
В ТФС есть доска. И для распределенных команд она очень помогает. А редмайн не имеет никакой интеграции со студией как и жираф. Вот обычный юз кейс как я мучась с редмайном:
УдалитьВ редмайн, чтобы залить картинку с результатом работ, надо проделать следующие операции.
1. Зайти в РЕДМАЙН свернув IDE.
2. Выбрать задачу.
3. Закачать картинку в задачу, нажать обновить.
4. Нажать обновить, вставить уже закаченную картинку в html разметку и отписаться под картинкой.
Что надо сделать в ТФС:
1. Не выходя из студии выбрать нужную задачу.
2. Отписаться вставив туда хоть видео хоть, что без тыкания обновить загрузить.. и.т.д.
3. Нажать чекин с прописанным ID work item.
Какой профит?
1. В случае с ТФС я получаю привязанную задачу к чекину.
2. На доске в ТФС отразятся эти изменения (если настроить воркфлоу то захламления можно избежать - это фишка канбана в тфс. Там можно поставить ограничения количества тикетов на 1 столб).
В редмайне неудобная навигация, а в студии, я могу поставить древовидное представление задач, и не выходя из студии, сразу увидеть, чего не хватает для реализации фичи - это позволяет сразу увидеть как обстоят дела и выбрать, то, что ты сейчас можешь делать. Для ПМ-ов это представление дает огромное преимущество, он сразу видеи затыки и проблемы, где не может двигаться команда. JIRA и REDMINE (работаю с этими недотрекерами уже 2й год).
УдалитьСтанислав,
Удалить1)При сотнях запланированных и открытых задач на доске появляется мешанина, в которой невозможно разобраться. Если в электронной системе задач ещё можно поставить фильтр, то тут его не применишь.
2)Моя цель, как тим лида, чтобы разработчик видел свои задачи - над которыми он работает сейчас и над которыми он будет работать в ближайшей перспективе, мог бы почитать историю в этих задачах, смог бы перекинуть тикет на продюсера или QA инженера при помощи клика, а не бегал бы целый день к большой доске, чтобы переместить бумажную карточку и написать на ней свой вопрос ручкой.
Виталий,
УдалитьРечь не идёт о споре Электронная Система Контроля Задач № 1 vs. Электронная Система Контроля Задач № 2.
Неужели прямо таки "Канбан"? Ставлю десятку против рубля, что вы гоните. Принимаем пари?
УдалитьСтранно спорить о методологиях. Гибкие методологии управления проектом, как и паттерны проектирования, не являются серебряной пулей, работают далеко не во всех случаях, и порой приводят к катастрофе и хаосу, будучи внедренными без осознания причин и последствий. В каждой компании свой канбан, скрам или whatever, которые отличаются от канбанов и скрамов компании по соседству. Процесс разработки формируется эволюционно, и в этом участвует вся команда. Какой смысл пытаться внедрять процесс из книжки? Используйте то, что в вашей ситуации может работать лучше всего.
ОтветитьУдалить