Pull to refresh
272.1
Karma
0
Rating
  • Followers 72
  • Following 56

Nokia Booklet 3G: В продаже с 22 октября

12 часов тянент с нашим антивирусом (F-Secure), сам тестировал и оптимизировал :)

«Улучшаем» тренажер для скалолазов

Фотка из Хельсингского аквапарка «Серена». Там, чтоли, это уже поставили? В прошлом году не видел.

Том ДеМарко: инжиниринг ПО — идея, время которой прошло?

Все верно вы написали, даже добавить нечего.

Том ДеМарко: инжиниринг ПО — идея, время которой прошло?

>> BTW, вижу некоторую агрессивность комментариев — может это надо было в «Управлении
>> проектами» постить?

Все равно уже на главной — все прочитают и оттуда и оттуда :)
На самом деле, чем больше агрессии, тем больше шансов, что «агрессоры» задумаются. И вообще, хорошо, что они это прочитали.

Том ДеМарко: инжиниринг ПО — идея, время которой прошло?

А попробуйте «инжиниринг» на русский перевести. «Программотехника» я нашел, но звучит по-советски. Уж лучше «индиниринг».

Том ДеМарко: инжиниринг ПО — идея, время которой прошло?

>> Но ни слова о том, что отсутсвие метрик — залог успеха.

«Залога успеха» в разработке ПО вообще нет и быть не может. А уж называть «залогом успеха» отсутствие чего-то — это глупо было бы.

Том ДеМарко: инжиниринг ПО — идея, время которой прошло?

Странно, может мы разные статьи читали?

Статья не просто предостерегает, а говорит прямо о невозможности контроля и о, собственно, ненужности его.
А если учесть, кто автор, то эти слова окрашиваются в особенные цвета…

Канбан в IT (Kanban Development)

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

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

Канбан в IT (Kanban Development)

В классическом Канбан Product Owner должен решить, какую из задач в очереди убрать и куда поместить новую высокоприоритетную. Но он не может ее впихнуть в производство, т.к. только одну может.

У нас же проще — мы просто берем вторую в производство. Третью уже можем и не взять — тогда это задача product owner-а поменять список в очереди задач.

Канбан в IT (Kanban Development)

>> Кто будет думать над hi-lvl архитектурой, когда product owner
>> лично назначает приоритеты? Где в данной схеме место
>> тех.лида?

Я могу сказать только про наш опыт. Мы разрабатывали архитектуру по большей части сами, то есть и тех. лид и архитектор находились в команде.
Когда были совсем высокоуровневые вопросы, то у нас в компании есть должность главного архитектора — шли к нему и обсуждали. Никаких проблем с архитектурой замечено не было.

Канбан в IT (Kanban Development)

Наша постоянно лезла в разработку, «управляла». Нейтрализовало на 100%.

Значит все-таки не обезьяна :)

Блин, да что я вам говорю, про это классики пишут в почти каждой книжке.

Все зависит от команды и проекта. Для каких-то проектов планирование и согласование — важнейшая часть проекта. Для других это ненужная трата времени. Есть отличная статья недавняя Тома Демарко — советую прочитать. И учтите, что он был одним из апологетов контроля за разработкой.

Дело в том, что если сравнивать скрам с канбаном, если вы признаете последний набором методик, а не процессом разработки, некорректно. Если же брать канбан как процесс в том виде, в котором он приведен в статье — то канбан нежизнеспособен в жестких условиях поставки.

Всё верно написано. В жестких условиях может не подойти. И это не процесс, а надстройка над процессом — над тем же скрамом или xp.

Канбан в IT (Kanban Development)

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

Так ли это по сути?
Вы можете рассчитать этот квант и соотношение запланированного к выполненому. Вы можете знать, сколько команда выполнит в следующем спринте, исходя из этих данных.
И это всё!

Что вы знаете про весь проект с этими данными? Ведь чтобы оценить весь проект, надо оценить каждую фичу в проекте, причем довольно точно. Если неточно оценил — грош цена такой оценке и это тоже самое, что и менеджер на коленке бы прикинул, что успеет сделаться, а что нет.
Собственно, гибкая разработка как раз о том, что нифига мы не можем прогнозировать точно и должны быть просто готовы зарелизить тогда, когда надо, а что не успели — отрезать.
Точные прогнозы — это к более тяжелым процессам, а не к agile.

В канбане все тоже самое — есть примерный скоуп проекта и команда его выполняет максимально быстро. product owner следит за скоупом и за временем выполнения одной задачи — из этого он делает выводы, сколько будет выполнено к дедлайну и меняет приоритеты, если что.
Контроль не хуже, чем в скраме — время выполнения задачи можно сравнивать и задача команды — сокращать это время. Если оно растет — что-то не так.

стало быть менеджер будет скакать вокруг меня и орать, чтобы мы работали быстрее, будет пытаться впихнуть больше задач единовременно или увеличить емкость семафора с задачами.

Ну, если менеджер — обезьяна, то тут и скрам не поможет. Обезьяна все равно скакать вокруг постоянно будет :)

Канбан в IT (Kanban Development)

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

Канбан в IT (Kanban Development)

С какими, например?
Общий случай — включать их в более крупные фичи.

Канбан в IT (Kanban Development)

Да, первое предложение не очень-то верно.
Канбан — это не полноценная методология разработки. Это скорее надстройка над другими методологиями. Канбан добавляет в то, над чем он построен, некоторые плюсы, и это методология, но не полная.

А «lean» и канбан — это немного понятия разного уровня. lean — это высокоуровневая система ценностей, в которую канбан входит, как составная часть.

Канбан в IT (Kanban Development)

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

Вы можете по-прежнему делать TDD, парное программирование, daily митинги, даже может быть итерации — все, что угодно, что помогает вам двигать задачи по доске Канбан как можно быстрее. Про конкретные методы и приемы разработки Канбан вообще ничего не говорит.

Канбан в IT (Kanban Development)

Приоритеты ставит product owner. И он же должен и фичам сопротивляться — он владелец проекта и он лучше всех остальных должен знать, что хорошо, а что плохо.

Канбан в IT (Kanban Development)

А вот еще мои слова, подтверждающие ваши: :)
Во-первых, нужно сразу понять, что Канбан — это не конкретный процесс, а система ценностей. Как, впрочем, и SCRUM с XP. Это значит, что никто вам не скажет что и как делать по шагам.

Канбан в IT (Kanban Development)

Про приоретизацию в трех основных правилах не сказано, да. Наверное потому, что это не задача команды, а задача product owner-а, который является внешней силой.
Про оценку времени сказано в третьем правиле.

Канбан в IT (Kanban Development)

Это не совсем Ad hoc, т.к. есть бэклоги, приоритизация, оценки времени на выполнение задач, ограничение работы в прогрессе и т.д.
А так в целом — да, похоже на Ad hoc.

Information

Rating
Does not participate
Location
Финляндия
Date of birth
Registered