Scrum, Kanban, Waterfall

Фанат

oncle terrible
Команда форума
Насколько я понимаю, Agile предполагает ответственность разрабов. Погружение в бизнес-процесс. Деятельное участие в достижении бизнес-целей. В этом случае обоснованно ожидать обоснованный рефакторинг.
А точка зрения "этим разработчикам только дай - они ни строчки для бизнеса не напишут" - это как раз палочная система из прошлого века, когда разработчик - это винтик в конвейере, тупо клепает код по тикетам, спущенным сверху, не задумываясь о его смысле.
Так что я бы сказал что "рефакторинг ради рефакторинга" - это забота продакта/лида. Если он может продать разрабам бизнес-задачу - то они и сами не будут отвлекаться на рефакторинг сверх необходимого.
 

WMix

герр M:)ller
Партнер клуба
Насколько я понимаю, Agile предполагает ответственность разрабов.
нет, агил это когда ожидаемый продукт важнее пузыря вокруг его разработки, когда мы пытаемся минимизировать бюрократическую машину, если можно так сказать.
 

Фанат

oncle terrible
Команда форума
Не противоречит. Вовлечение разработчиков никак не мешает минимизировать и так далее.
А вот наличие этой мотивации является принципиальным моментом, без которого весь аджайл превратится в карго-культ.
То есть если разработчик является не винтиком а заинтересованным творцом, то аджайл работает и можно не трястись над упущенными на рефакторинг минутами.
А если аджайл только вывеска, то да - тогда только и остается что сажать разработчика в клетку с надсмотрщиком "не дай бог, ты ,сука, лишнюю строчку отрефакторишь!"
 

whirlwind

TDD infected, paranoid
Аджайл разным бывает. Скрам - это аджайл, который позволяет определять стратегию развития, получать фидбек от всех заинтересованных лиц, объективно оценивать и планировать собственные действия (буквально связать KPI с velocity), гибко решать проблемы (в том числе изменяющиеся требования), в течение длительного срока сохранять высокую мотивацию в команде. Главной целью в скраме является "результат точно в срок". Можете кинуть в меня камень, если это не то, что нужно любому заказчику. И достигается это только использованием всей совокупностью артефактов подхода. Потому что он уже вылизан и вычищен от всего лишнего. Возвращаясь к примеру с автомобилем, вам недостаточно взять отдельно руль, колеса или мотор что бы быстро и далеко ехать. А вот канбан это несколько другое. Канбан это всего лишь доска, которую вы можете использовать даже с водопадом. Канбан - это тактика. Скрам - это стратегия. Смесь подходов канбана со скрамом никуда не поедет. Но канбан отлично дополняет скрам. Карго-культ - отличная аналогия непониманию и неправильному использованию скрама.
 

WMix

герр M:)ller
Партнер клуба
может ошибаюсь, отличие скрама от канбана только в спринтах, в первом случае мы спринт (набор задач) планируем заранее, в канбане же, берешь следующий свободный тикет и лепишь. они (свободные задачи) все в приоритете иначе не на доске
Не противоречит.
doch, конечно противоречит,
идея в избавлении от ненужной работы, а не про то чтоб "найти козла отпущения"
которую вы можете использовать даже с водопадом.
как будто скрам это не водопад
 
Последнее редактирование:

whirlwind

TDD infected, paranoid
Я просто оставлю это здесь

https://res.infoq.com/news/2010/01/kanban-scrum-minibook/en/resources/KanbanAndScrum-Russian.pdf

scrum-artifacts.png

PS. Кажется я догадываюсь, почему аджайл такое непонимание вызывает. Вы видите новые декларируемые артефакты, ценность которых для вас не очевидна и говорите - что за черт, придется больше работать! Но ведь тут нет ничего нового. Вы можете взять feature request из RUP и использовать его в любом более адаптивном подходе. Но более директивный подход не означает, что работы больше будет. Более директивный подход говорит о том, что у нас есть набор уже известных вам артефактов, ценность каждого из которых обоснована в рамках единой системы. В итоге мы даем вам чеклист, используя который вы будете идти к результату. Конечно, вы можете взять refactoring из XP и засунуть его хоть в канбан, хоть в водопад. Велосипед тоже может быть оборудован палкой-копалкой с помощью которой вы будете периодически сбивать грязь с колес. Или например фонариком, который позволит вам ехать ночью. Но что бы максимально быстро проехать 1000км вам нужен вот такой конкретный девайс. Вопрос переверните с головы на ноги. Не "почему я должен делать лишнюю работу, что бы сделать свою работу" а "какую работу я должен делать, что бы сделать свою работу максимально эффективно".

Набивший оскомину пример с рефакторингом ради рефакторинга. Вот цепочка:

коллективная ответственность за результат -> коллективное владение кодом
коллективное владение кодом -> коллективное принятие решений
коллективное принятие решение -> коллективный анализ эффективности
коллективный анализ эффективности -> обоснованность рефакторинга

Это решение только одной проблемы с точки зрения XP. Если вы уберете коллективное владение кодом, то цепочка станет короче и ответить на вопрос обоснованности рефакторинга вы эффективно не сможете, потому что рефакторинг - это улучшение кода, а ваши цепочки не проходят через код. Но это будет скрам. А если у вас нет коллективной ответственности, то это канбан, где все тратят время на ворклоги, а тимлид зашивается, распределяя задачи и анализируя субъективные отчеты. Это будет канбан, даже если у вас есть беэклоги и стендапы.

Внедрение коллективного владения кодом - это исключительно управленческое решение. Но если вы этого не сделали, то чего вы жалуетесь, что у вас рефакторинг ради рефакторинга? Ну так и есть. Ваш коллега считает что пора, а вы нет. Он за свей счет делает рефакторинг, встречает непонимание, снижается мотивация. В итоге более фанатичный TDD зашивается на своем участке внутри команды и уходит, вместо того, что бы поправить дела на остальных участках системы. Каждый артефакт важен и дает синергетический эффект только при использовании вместе с другими.
 
Последнее редактирование:

whirlwind

TDD infected, paranoid
Давайте до конца добьем вопрос рефакторинга. Наверняка многие думают что это много тяжелой работы, много обсуждений и вообще безумно дорого для бизнеса.

Нет, не много и не дорого. Потому что если вы дошли до уровня XP, то у вас код вылизан, TDD тянет за собой SOLID, KISS, TDA, контракты, паттерны, всяческие тесты и прочая прочая. Как следствие - хороший дизайн что с инженерной точки зрения превращает любой рефакторинг из "адски сложно" в "раз плюнуть". А благодаря коллективному владению кодом вам не нужно спорить и обсуждать что то по этому поводу, потому что все уже в курсе и все этот код так или иначе уже видели. Кто то один открывает и напоминает дизайн, а остальные предлагаю способы решения. В итоге выбирается оптимальный по дизайну. На канбан-доске просто появляется новый тикет, который оценивается обычно в 3-5-8 поинтов - стоимость небольшой, хорошо прогнозируемой задачи. В спринте из 100-200 поинтов на команду эти затраты - плюнуть и растереть. Но уберите хоть что то из XP и любой рефакторинг превратится в ад. Так это работает.
 

WMix

герр M:)ller
Партнер клуба

whirlwind

TDD infected, paranoid
@WMix, что не так? В процессе длительной фазы кодирования нельзя уткнуться носом в проблему и сделать рефакторинг или что? Или XP это не аджайл?

PS. Давай предметно по написанному мной, а не о моей персоне. А то скучно.
 

WMix

герр M:)ller
Партнер клуба
грубо
рефакторинг - упрощение кода.
xp - парное программирование.

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

Давай предметно по написанному мной, а не о моей персоне. А то скучно.
ну вот тебе цитата по твоему линку
Инструмент – это то, что используется в качестве средства для выполнения задачи или достижения цели. Процесс – это то, как вы работаете. Scrum и Kanban – это инструменты процесса, они помогают вам работать более эффективно, до определенной степени подсказывая, что делать
а вот твоя цитата
Говорят что скрам, но у них не скрам, а канбан и кое какие термины/практики из скрама
найди отличия
 

whirlwind

TDD infected, paranoid
В первом сообщении на этой странице я оставил ссылку на документ и схему, на которой показана какой подход какое место занимает по отношению по отношению к другим в плане объявленных правил. Там перечислены все специфические артефакты подходов. Можно взять канбан и засунуть его в скрам. Обычно так и бывает. Это работает, потому что сам канбан маленький и решает вполне конкретные задачи: наглядность и конвейерное распределение нагрузки. Это отлично подходит для выявления узких мест. Но не бывает такого, что ты берешь скрам и засовываешь его в канбан. Ну то есть ты можешь попытаться взять любой артефакт из более директивного подхода и пытаться его использовать в любом менее директивном, но ты не получишь что то, что будет работать лучше. Если в неправильной последовательности внедрять артефакты скрама в канбан, или артефакты экстремального программирования в скрам, то получится прямо противоположный эффект.

Насчет рефакторинга, который - упрощение кода и "почемуб не отрефакторить". Я думаю если бы отцы основатели услышали такую формулировку целей, они бы очень расстроились.

refactoring.jpeg

Никому не нужен рефакторинг ради рефакторинга. Улучшение кода - это задача. А цели преследуются совсем другие. И они отлично укладываются в аджайл - поддерживать код готовым для изменений, повышать уровень доверия к коду.
 
Сверху