CC>А когда команда состоит в основном из DRI, которые берут фичу, дизайнят, планируют, договариваются с другими командами о том, что понадобится от них, и потом пару лет её пилят, координируясь с другими feature owner как внутри как и cross-team, то эти модные методологии только под ногами путаются. Нормально работают прямые коммуникации и периодические sync митинги.
Это не командная разработка, а одиночная (silo-ed).
Скрам и подобия предназначены для командной работы, где предполагается, что упавшее знамя нужно подобрать немедленно, и тут же понести (другим членом команды).
Применять скрам в одиночно-индивидуальной разработке (когда нет постоянных команд, есть лишь проектные группировки) смысла не имеет.
L>Я делюсь своим опытом, где скрам сработал именно так. И добиться большей прозрачности — это уже сама по себе очень серьезная ачивка.
Писал об этом еще с 2007. Равно как и о том, что сия прозрачность зачастую противоречит интересам участников процесса поэтому внедрение методики испытывает жестокие фейлы.
_AB>Основы я лично осваивал через через практику/наставничество и обучающие курсы.
В моем случае курсы и прочие обучения сами по себе не дали особой пользы.
Зато полтора года реальной работы со скрам (в основном как product owner), плюс еще дольше часть meta-scrum команды, можно сказать, что глаза раскрыли.
Здравствуйте, SkyDance, Вы писали:
SD>Писал об этом еще с 2007. Равно как и о том, что сия прозрачность зачастую противоречит интересам участников процесса поэтому внедрение методики испытывает жестокие фейлы.
Ну да, особенно когда привыкли в одиночку "пилить проект два года"
Здравствуйте, SkyDance, Вы писали:
SD>Скрам и подобия предназначены для командной работы, где предполагается, что упавшее знамя нужно подобрать немедленно, и тут же понести (другим членом команды).
И даже не только, и не столько в этом, а в том, чтобы создать эффективную модель сотрудничества в команде, когда все члены команды принимают участие в реализации любых тасков, а не отвлеченно пилят свой проект два года
SD>Применять скрам в одиночно-индивидуальной разработке (когда нет постоянных команд, есть лишь проектные группировки) смысла не имеет.
На самом деле, даже там стоит. чтобы ставить планы и не терять фокус.
Здравствуйте, gandjustas, Вы писали:
G>Детализация задач до размера одного дня и ежедневные стендапы позволят это узнать пораньше.
Не позволят, потому что обычно самые большие риски идут в конце, и ты скорее всего "успешно сделаешь" две трети задач, прежде чем вляпаться в непреодолимую проблему.
Попытки все спланировать только приводят к потере времени на собственно планирование и попытки следовать плану, и создают ложное чувство контроля, что еще хуже. Потому что самые опасные риски — это те, наличие которых ты не осознаешь.
Здравствуйте, landerhigh, Вы писали:
L>Может, в иной вселенной и ложная. В нашей дело обстоит именно так.
Пардон, но это просто чушь. Никто тебе не запрещает делать разработку поэтапно и ничего не планировать. Ну, кроме религиозных соображений.
На самом деле, пытаться все планировать — это характерная черта именно водопадной модели, а не ее противоположность.
Здравствуйте, Codealot, Вы писали:
L>>Может, в иной вселенной и ложная. В нашей дело обстоит именно так. C>Пардон, но это просто чушь. Никто тебе не запрещает делать разработку поэтапно
Да, даже целая методология разработки, основанная на коротких этапах, есть. Угадаешь, как называется?
C>и ничего не планировать. Ну, кроме религиозных соображений.
Если Ничего не планировать, то получится примерно Ничего.
C>На самом деле, пытаться все планировать — это характерная черта именно водопадной модели, а не ее противоположность.
На самом деле, пытаться рассуждать на темы, о которых имеешь очень отдаленное представление, это характерная черта кывта
Здравствуйте, Codealot, Вы писали:
C>Не позволят, потому что обычно самые большие риски идут в конце, и ты скорее всего "успешно сделаешь" две трети задач, прежде чем вляпаться в непреодолимую проблему. C>Попытки все спланировать только приводят к потере времени на собственно планирование и попытки следовать плану, и создают ложное чувство контроля, что еще хуже. Потому что самые опасные риски — это те, наличие которых ты не осознаешь.
где же, где же, где же она, эта оценка "фейспалм"?
Здравствуйте, landerhigh, Вы писали:
L>Да, даже целая методология разработки, основанная на коротких этапах, есть. Угадаешь, как называется?
То есть ты действительно веришь, что до скрам-фанатиков никто до этого не додумался?
Хотя это типично, каждое поколение детишек думает, что это именно они изобрели секс. Причем делать это надо стоя и в гамаке, и никак иначе.
L>Если Ничего не планировать, то получится примерно Ничего.
То есть, у тебя все сводится именно к религиозным соображениям. Ну ок.
L>На самом деле, пытаться рассуждать на темы, о которых имеешь очень отдаленное представление, это характерная черта кывта
Здравствуйте, _ABC_, Вы писали:
P>>Чем больше неопределенности, тем хуже работает скрам. _AB>Хуже по сравнению с чем работает скрам в таких условиях?
Чем канбан какой. Неопределенность требует гибкости. Не совсем понятно, что в спринт тащить, не ясно, что делать, если в первый же день выясняется, что все планы насмарку.
Здравствуйте, _ABC_, Вы писали:
_AB>Ещё более забавен другой факт — ты ни разу не упомянул общение со своими пользователями, с клиентами. По твоему описанию, вы там варитесь внутри в своём соку, разрабатывая фичи в одиночку и исходя из собственного понимания того, что нужно пользователям. Либо ты упрощаешь всё до невозможности, либо просто не понимаешь всего, что находится над тобой и даёт тебе требования, которые ты реализуешь.
Нет у него ни пользователей, ни клиентов — он же системщик. Специфика труда, отсюда и особенности мировозрения.
Здравствуйте, landerhigh, Вы писали:
L>Вот, в соседней ветке зявили, что скрам работает плохо на задачах с неопределенностью. Мы спросили, в сравнении с чем. Но автора и след простыл.
Вы так торопитесь, что умным мыслям вас не догнать.
P>Чем канбан какой. Неопределенность требует гибкости. Не совсем понятно, что в спринт тащить, не ясно, что делать, если в первый же день выясняется, что все планы насмарку.
Первые 7-8 спринтов так и будет, ничего не понятно, планы не планируются, фичи делаются внезапно и т.п..
Но спринтов через 10-12 оказывается, что накоплено достаточно опыта и исторических знаний. И оно вдруг начинает довольно точно показывать реальность, что будет сделано, а что нет. В общем, как и везде, поначала бардак, потом устаканивается.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, no_ise, Вы писали:
_>>все они в нашем времени.
L>Между тем, что Вася может за пару недель на коленке нашедеврить...
Вася за пару недель на коленке не шедеврит. Вася делает нормальную инженерно-изобретательскую работу. Примеры я уже привел.
L>... до работающего продукта нынче — огромная пропасть. Просто в силу обстоятельств.
Это точно. В цеху требуется много специальностей. И всех нужно синхронизировать в один процесс, так работает завод. Там возможны свои процессы, порядки, и строгие бригадиры.
L>Речь идет не о самородках, которые выдают гениальные идеи, и которые в основном закончились в 90-е...
Ну хорошо, пусть не о самородках. Но откуда такое убеждение, что они закончились в 90-е. После 90-х кто остался то, непонятно.
L>...а о работающих продуктах, реализованнх в означенные сроки без сильного выхода из бюджета.
Так скрам и все такое подобное это подчастую и есть про то, как законно и на вполне
легальных основаниях затягивать сроки до бесконечности путем непрерывных улучшений
косячного фундамента. И про то, как грамотно тянуть из заказчика деньги до бесконечности.
Тут мне приходилось недавно быть заказчиком одной не-софтверной компании. Но скрам
и все стендапы там прям по этой методологии были. Еле отделался от них, пришлось
обращаться к юристам и судиться с ними, а то задолбали со своими 'обсудили на планерке'.
Юристы такой гадюшник, к счастью, знают как правильно прижать.
Кстати, эти исполнители тоже время от времени жаловались на отсутствие эндорфинов.
Ну, такой уж это мошеннический процесс, как мне кажется.
Здравствуйте, no_ise, Вы писали:
L>>Между тем, что Вася может за пару недель на коленке нашедеврить... _>Вася за пару недель на коленке не шедеврит. Вася делает нормальную инженерно-изобретательскую работу. Примеры я уже привел.
Нет там никаких примеров.
В лучшем случае, ключевые инженеры, где кроме них, на проекте работают еще пара десятков инженеров уровня не меньше.
L>>...а о работающих продуктах, реализованнх в означенные сроки без сильного выхода из бюджета. _>Так скрам и все такое подобное это подчастую и есть про то, как законно и на вполне _>легальных основаниях затягивать сроки до бесконечности путем непрерывных улучшений _>косячного фундамента. И про то, как грамотно тянуть из заказчика деньги до бесконечности.
Так водопад и все такое подобное и есть про то, как на вполне легальных основаниях затягивать сроки до бесконечности путем непрерывных "улучшений" изначально неправильно заложенного фундамента. И про то, как грамотно тянуть из заказчика деньги до бесконечности.
Здравствуйте, Pauel, Вы писали:
_AB>>Хуже по сравнению с чем работает скрам в таких условиях?
P>Чем канбан какой.
Канбан — это тот же скрам, только вид в другой проекции.
P>Неопределенность требует гибкости. Не совсем понятно, что в спринт тащить, не ясно, что делать, если в первый же день выясняется, что все планы насмарку.
Скрам в первую очередь про гибкость. Там есть вполне документированная процедура, которую следует применять, если "в первый же день выясняется, что все планы насмарку".
Не все нынешние скрам кучеры до нее дочитали, впрочем.
Здравствуйте, landerhigh, Вы писали:
_AB>>>Хуже по сравнению с чем работает скрам в таких условиях?
P>>Чем канбан какой.
L>Канбан — это тот же скрам, только вид в другой проекции.
поэтому внедрение методики испытывает жестокие фейлы.
