>> BTW, вижу некоторую агрессивность комментариев — может это надо было в «Управлении
>> проектами» постить?
Все равно уже на главной — все прочитают и оттуда и оттуда :)
На самом деле, чем больше агрессии, тем больше шансов, что «агрессоры» задумаются. И вообще, хорошо, что они это прочитали.
Статья не просто предостерегает, а говорит прямо о невозможности контроля и о, собственно, ненужности его.
А если учесть, кто автор, то эти слова окрашиваются в особенные цвета…
У меня сейчас в проекте намечается момент, когда канбан может взорваться как раз из-за множества высокоприоритетных задач, которые берутся в работу немедленно. Из-за этого могут откладываться старые задачи.
Пробую с этим справиться, но пока что таким образом, что product owner-у не отказываю, но людей со старых задач стараюсь не снимать — пытаюсь хэндлить их самостоятельно. То есть как бы есть специальный выделенный человек на «неожиданности».
В классическом Канбан Product Owner должен решить, какую из задач в очереди убрать и куда поместить новую высокоприоритетную. Но он не может ее впихнуть в производство, т.к. только одну может.
У нас же проще — мы просто берем вторую в производство. Третью уже можем и не взять — тогда это задача product owner-а поменять список в очереди задач.
>> Кто будет думать над hi-lvl архитектурой, когда product owner
>> лично назначает приоритеты? Где в данной схеме место
>> тех.лида?
Я могу сказать только про наш опыт. Мы разрабатывали архитектуру по большей части сами, то есть и тех. лид и архитектор находились в команде.
Когда были совсем высокоуровневые вопросы, то у нас в компании есть должность главного архитектора — шли к нему и обсуждали. Никаких проблем с архитектурой замечено не было.
Наша постоянно лезла в разработку, «управляла». Нейтрализовало на 100%.
Значит все-таки не обезьяна :)
Блин, да что я вам говорю, про это классики пишут в почти каждой книжке.
Все зависит от команды и проекта. Для каких-то проектов планирование и согласование — важнейшая часть проекта. Для других это ненужная трата времени. Есть отличная статья недавняя Тома Демарко — советую прочитать. И учтите, что он был одним из апологетов контроля за разработкой.
Дело в том, что если сравнивать скрам с канбаном, если вы признаете последний набором методик, а не процессом разработки, некорректно. Если же брать канбан как процесс в том виде, в котором он приведен в статье — то канбан нежизнеспособен в жестких условиях поставки.
Всё верно написано. В жестких условиях может не подойти. И это не процесс, а надстройка над процессом — над тем же скрамом или xp.
Квант здесь — измеримое понятие, т.е. бизнес-людям можно оценить сверху, будут ли реализованы все важные запланированные задачи к сроку поставки, или же нужно сокращать функционал.
Так ли это по сути?
Вы можете рассчитать этот квант и соотношение запланированного к выполненому. Вы можете знать, сколько команда выполнит в следующем спринте, исходя из этих данных.
И это всё!
Что вы знаете про весь проект с этими данными? Ведь чтобы оценить весь проект, надо оценить каждую фичу в проекте, причем довольно точно. Если неточно оценил — грош цена такой оценке и это тоже самое, что и менеджер на коленке бы прикинул, что успеет сделаться, а что нет.
Собственно, гибкая разработка как раз о том, что нифига мы не можем прогнозировать точно и должны быть просто готовы зарелизить тогда, когда надо, а что не успели — отрезать.
Точные прогнозы — это к более тяжелым процессам, а не к agile.
В канбане все тоже самое — есть примерный скоуп проекта и команда его выполняет максимально быстро. product owner следит за скоупом и за временем выполнения одной задачи — из этого он делает выводы, сколько будет выполнено к дедлайну и меняет приоритеты, если что.
Контроль не хуже, чем в скраме — время выполнения задачи можно сравнивать и задача команды — сокращать это время. Если оно растет — что-то не так.
стало быть менеджер будет скакать вокруг меня и орать, чтобы мы работали быстрее, будет пытаться впихнуть больше задач единовременно или увеличить емкость семафора с задачами.
Ну, если менеджер — обезьяна, то тут и скрам не поможет. Обезьяна все равно скакать вокруг постоянно будет :)
Про рефакторинг — это целый отдельный разговор. Кто-то делает его постоянно про разработке любой фичи, считая, что тронул код — прорефакторь его.
Кто-то выделяет специально время на него — это уже может быть вне канбана. Просто раз в полгода на 2 недели все делают рефакторинг.
А можно и фичу такую завести и назвать ее как-нибудь типа «Улучшение надежности, стабильности и поддерживаемости кода».
Да, первое предложение не очень-то верно.
Канбан — это не полноценная методология разработки. Это скорее надстройка над другими методологиями. Канбан добавляет в то, над чем он построен, некоторые плюсы, и это методология, но не полная.
А «lean» и канбан — это немного понятия разного уровня. lean — это высокоуровневая система ценностей, в которую канбан входит, как составная часть.
Канбан может быть использован вместе с Scrum или XP.
Канбан-команда может использовать любые артефакты из других методологий, т.к. Канбан — это не методология по сути, а набор ценностей, надстройка над методологией.
Вы можете по-прежнему делать TDD, парное программирование, daily митинги, даже может быть итерации — все, что угодно, что помогает вам двигать задачи по доске Канбан как можно быстрее. Про конкретные методы и приемы разработки Канбан вообще ничего не говорит.
Приоритеты ставит product owner. И он же должен и фичам сопротивляться — он владелец проекта и он лучше всех остальных должен знать, что хорошо, а что плохо.
А вот еще мои слова, подтверждающие ваши: :) Во-первых, нужно сразу понять, что Канбан — это не конкретный процесс, а система ценностей. Как, впрочем, и SCRUM с XP. Это значит, что никто вам не скажет что и как делать по шагам.
Про приоретизацию в трех основных правилах не сказано, да. Наверное потому, что это не задача команды, а задача product owner-а, который является внешней силой.
Про оценку времени сказано в третьем правиле.
Это не совсем Ad hoc, т.к. есть бэклоги, приоритизация, оценки времени на выполнение задач, ограничение работы в прогрессе и т.д.
А так в целом — да, похоже на Ad hoc.
>> проектами» постить?
Все равно уже на главной — все прочитают и оттуда и оттуда :)
На самом деле, чем больше агрессии, тем больше шансов, что «агрессоры» задумаются. И вообще, хорошо, что они это прочитали.
«Залога успеха» в разработке ПО вообще нет и быть не может. А уж называть «залогом успеха» отсутствие чего-то — это глупо было бы.
Статья не просто предостерегает, а говорит прямо о невозможности контроля и о, собственно, ненужности его.
А если учесть, кто автор, то эти слова окрашиваются в особенные цвета…
Пробую с этим справиться, но пока что таким образом, что product owner-у не отказываю, но людей со старых задач стараюсь не снимать — пытаюсь хэндлить их самостоятельно. То есть как бы есть специальный выделенный человек на «неожиданности».
У нас же проще — мы просто берем вторую в производство. Третью уже можем и не взять — тогда это задача product owner-а поменять список в очереди задач.
>> лично назначает приоритеты? Где в данной схеме место
>> тех.лида?
Я могу сказать только про наш опыт. Мы разрабатывали архитектуру по большей части сами, то есть и тех. лид и архитектор находились в команде.
Когда были совсем высокоуровневые вопросы, то у нас в компании есть должность главного архитектора — шли к нему и обсуждали. Никаких проблем с архитектурой замечено не было.
Значит все-таки не обезьяна :)
Блин, да что я вам говорю, про это классики пишут в почти каждой книжке.
Все зависит от команды и проекта. Для каких-то проектов планирование и согласование — важнейшая часть проекта. Для других это ненужная трата времени. Есть отличная статья недавняя Тома Демарко — советую прочитать. И учтите, что он был одним из апологетов контроля за разработкой.
Дело в том, что если сравнивать скрам с канбаном, если вы признаете последний набором методик, а не процессом разработки, некорректно. Если же брать канбан как процесс в том виде, в котором он приведен в статье — то канбан нежизнеспособен в жестких условиях поставки.
Всё верно написано. В жестких условиях может не подойти. И это не процесс, а надстройка над процессом — над тем же скрамом или xp.
Так ли это по сути?
Вы можете рассчитать этот квант и соотношение запланированного к выполненому. Вы можете знать, сколько команда выполнит в следующем спринте, исходя из этих данных.
И это всё!
Что вы знаете про весь проект с этими данными? Ведь чтобы оценить весь проект, надо оценить каждую фичу в проекте, причем довольно точно. Если неточно оценил — грош цена такой оценке и это тоже самое, что и менеджер на коленке бы прикинул, что успеет сделаться, а что нет.
Собственно, гибкая разработка как раз о том, что нифига мы не можем прогнозировать точно и должны быть просто готовы зарелизить тогда, когда надо, а что не успели — отрезать.
Точные прогнозы — это к более тяжелым процессам, а не к agile.
В канбане все тоже самое — есть примерный скоуп проекта и команда его выполняет максимально быстро. product owner следит за скоупом и за временем выполнения одной задачи — из этого он делает выводы, сколько будет выполнено к дедлайну и меняет приоритеты, если что.
Контроль не хуже, чем в скраме — время выполнения задачи можно сравнивать и задача команды — сокращать это время. Если оно растет — что-то не так.
стало быть менеджер будет скакать вокруг меня и орать, чтобы мы работали быстрее, будет пытаться впихнуть больше задач единовременно или увеличить емкость семафора с задачами.
Ну, если менеджер — обезьяна, то тут и скрам не поможет. Обезьяна все равно скакать вокруг постоянно будет :)
Кто-то выделяет специально время на него — это уже может быть вне канбана. Просто раз в полгода на 2 недели все делают рефакторинг.
А можно и фичу такую завести и назвать ее как-нибудь типа «Улучшение надежности, стабильности и поддерживаемости кода».
Общий случай — включать их в более крупные фичи.
Канбан — это не полноценная методология разработки. Это скорее надстройка над другими методологиями. Канбан добавляет в то, над чем он построен, некоторые плюсы, и это методология, но не полная.
А «lean» и канбан — это немного понятия разного уровня. lean — это высокоуровневая система ценностей, в которую канбан входит, как составная часть.
Канбан-команда может использовать любые артефакты из других методологий, т.к. Канбан — это не методология по сути, а набор ценностей, надстройка над методологией.
Вы можете по-прежнему делать TDD, парное программирование, daily митинги, даже может быть итерации — все, что угодно, что помогает вам двигать задачи по доске Канбан как можно быстрее. Про конкретные методы и приемы разработки Канбан вообще ничего не говорит.
Во-первых, нужно сразу понять, что Канбан — это не конкретный процесс, а система ценностей. Как, впрочем, и SCRUM с XP. Это значит, что никто вам не скажет что и как делать по шагам.
Про оценку времени сказано в третьем правиле.
А так в целом — да, похоже на Ad hoc.