Мне нравятся подобные комментарии. Вроде как правильная мысль но совершенно бесполезная.
Лучше объясните каким образом в 90% ситуаций скрам используется исключительно для предоставления контрольных точек менеджменту а не, собственно, для того зачем он нужен.
То есть вы сразу пишете все тесты, а потом всю реализацию?
Вы правильно заметили на тему "мужественности". Но все же от "все тесты" это все очень далеко. Я как-то общался с человеком которому не нравилось TDD потому что он месяц тесты писал и только потом писал реализацию. Сами понимаете как это не эффективно.
На тему же "мужественности" — для простых задач можно сразу накидать несколько тест кейсов (триангуляция, в терминах Кента Бэка) и потом реализовывать код. И чаще всего вы врядли захотите двигаться совсем уж маленькими шагами. А вот если вы написали несколько тестов и не можете написать код — всегда можно убрать пару тестов и двигаться более маленькими шажками. Тут все очень субъективно. По сути основной момент — насколько вы уверены. Не уверены — сокращайте длину итераций.
Вы уверены, что стоит тратить рабочее время на подбор такого намеренно дефективного алгоритма?
Возможно VolCh меня поправит, но мне кажется речь идет о ситуации когда изменения вносятся в код, который писался давно и как следствие разработчику лучше разобраться почему то поведение которого вроде бы небыло (иначе зачем тест) — работает.
да, довольно часто это все избыточно (опять же смотрим про уверенность), но если уверенности нет — имеет смысл.
Правда я не соглашусь с тем что бы заставлять людей так делать, в большинстве случаев это действительно избыточно.
Ну, что-то он тестирует. А то ли он тестирует?
Мутационные тесты хорошо подходят для определения качества вашей тест сюиты. Да, долго, но зато потом можно лучше понимать в чем проблемы тестов.
Вы что-то путаете. symfony/console самодостаточный пакет который по умолчанию не тянет ничего дополнительно.
Ну и опять же — простая логика. Если вам нужно текст раскрасить в CLI приложение, кто скорее всего нужно будет и аргументы распарсить, и в целом почему бы и нет.
Вывод — первая имплементация неверная, в первом требовании ничего про исключения нет, а мы их бросаем.
Опять же, на примерах функции деления плохо просматривается суть зачем так делать. Ну я к тому что если разработчик чувствует уверенность он может существенно увеличить длину итерации (написать сразу 2-3 теста, скипнуть часть про "всегда должен быть красный тест" и т.д.) Ну и обычно уверенность уменьшается пропорционально сложности задачи.
Словом, Кент Бэк все это придумывал что бы регулируя длину итераций чувствовать себя уверенно в коде. Кому-то это для уверенноси не нужно, а кому-то — недостаточно только этого.
Тем что реализация не влияет на процесс формализации требований, и от того меньше технических деталей в эти требования проникает. Как следствие, поскольку речь идет о юнит тестах, больше шансов спроектировать более изолированные контракты.
Когда разработчики, особенно те кто только начинают писать тесты, пишут тесты после реализации, чаще всего эти тесты тупо дублируют реализацию.
Что именно является способом борьбы со страхом внесения изменений?
Все вместе, а дальше зависит от человека и того на что он будет ставить акцент. Опять же, TDD не универсальный инструмент, есть категория людей которым это все не помогает либо не нужно (просто могут менять код и их это не особо пугает).
Но как это может обеспечить достаточное покрытие хотя бы классов эквивалентности?
оно не призвано ее обеспечивать. TDD это не про тесты, тесты тут только инструмент, а суть больше в проектировании интерфейсов и модулей с низкой связанностью. Ну и никто не запрещает вам прогнать мутационные тесты и узнать реальное состояние дел с покрытием.
Какая ж она бесплатная, если вы на их написание требуется время и силы?
потому в кавычках. Опять же, тесты до имплементации занимают меньше времени чем после. Вне зависимости от уровня разработчика эти тесты будут качественно лучше, опять же модули будут более изолированы.
Тут стоит сделать ремарку — если вы УЖЕ можете делать более изолированные модули, вы УЖЕ умеете писать тесты неплохо, вы понимаете как определять их качество и т.д. то ценности от TDD для вас возможно нет.
Причём есть гипотеза, что писать тесты на отсутствующий код несравнимо сложнее, чем на существующий.
Кент Бэк в своей книге (опять же нет под рукой, не могу дать точную отсылку) писал о маленьком исследовании где эта гипотиза по сути опровергается. Там типа ставился эксперемент в духе пишем одно и то же приложение 10 раз (что-то простенькое, консольная симуляция игры в боулинг например), половина тесты до, половина тесты после, засекаем время и т.д.
Опять же — я не смог нагуглить полноценных исследований на эту тему. Но в целом (во всяком случае на основании моих опытов) я могу объяснить это за счет того, что в случае TDD у нас этап написания тестов и этап формализации требований (а он есть всегда вне зависимости от подхода) — один и тот же этап, что позволяет меньше переключать контекст. Ну и еще одно интересное наблюдение — писать тесты после реализации обычно скучнее (опять же судить могу только по себе и людям с которыми когда-то эти темы обсуждал).
В большинстве случаев проще и дешевле переписать заново
это никогда не проще и не дешевле, поскольку на момент "переписывания" требования будут продолжать меняться, а фризить функционал на пол года никто не будет.
Постепенно переписывать — можно, так или иначе придется. А вот с нуля — никогда не окупится.
> У неизменяемого объекта лучше уж вообще не делать таких методов, чтобы не вводить в заблуждение.
Ну заблуждени тут из ваших личных привычек. Лично меня подобное не смущает. Ну и опять же вопрос в том что имутабельность это хорошо (потому что можно всегда вывести типы и отследить стэйт не запуская код) но получать новые значения все еще нужно. И проще клонировать объект при изменениях (можно частично если эти части не меняются).
Ну и если вы все еще считаете что «это не очевидно» и т.д. предлагаю вам не личные субъективные ощущения (или мои) использовать, а провести полноценное исследование данного вопроса. Тогда можно будет делать выводы.
он не получает фидбэк, потому в целом какая разница? В этом же собственно основная проблема ватерфола, а не в том что «нет спринов». Нет фидбэка — приоритизация происходит на основе «я так вижу». А при таком раскладе можно и более ватерфольные штуки использовать (FDD то же)
Ну и опять же — если у оунера есть готовность слить результаты работы в унитаз — не понятно зачем так детально это прорабатывать.
Не ну если вы не заинтересованы — то зачем тратить время?
Мысль очень простая — скрам это не про то как вы дружно там дэйлики проводите, и спринты планируете. Это все в общем то инструменты. А основная штука в приоритизации задач, выделении важных вещей, анализе фидбэка после каждой итерации (опять же для приоритизации). А потому я и спросил — с введением в команде скрама процесс формирования бэклога хоть как-то поменялся? или в целом что там что там есть некий человек который просто говорит что делать? Ну мол, есть скоуп работы скажем на квартал и вы просто пилите от спринта к спринту или все же спринтам привязываются цели?
В больших компаниях как правило процесс формирования бэклога никак не меняется от введения скрама в дев командах. От того толку от этого скрама там не много, хоть десять коучей наймите. Ну и опять же, если вся компания представлена одной маленькой скрам командой с продукт оунером, то скорее всего эта команда будет пытаться деливерить то что важно (ибо на то что не важно обычно нет денег). И тут скрам помогает.
Уж извините за скомканность мысли, но в целом мысль простая — скрам работает там, где людям важно максимально ценность для пользователя деливерить а не максимум фич (отсюда важны все эти цели спринтов, фидбэк луп и прочее). Ну и в нем нет смысла если вы и так прекрасно представляете что вам нужно заделиверить и нет нужды в эксперементах.
В каждом первом проекте по скраму получается одно из двух
Заметили ли вы что обычно когда все идет хорошо процессы хвалят те кто их внедрял, а в случае неудачи ругают те кто по ним работал? Если да — тогда наша статистика в целом совпадает (такая же у меня например в случае с kanban)
Но все же, повторюсь. Описанная вами ситуация будет воспроизводиться и в случае с каким-нибудь RUP, как минимум потому что речь идет о проблема коммуникаций между людьми в рамках одной задачи. Ну то есть я не понимаю почему для вас спросить на дэйли у человека в чем проблема и как ему помочь — это мокнуть его перед командой.
можно будет объяснять успешные результаты
главное не попасться в классическую ошибку выжевшего.
p.s. если что, я не особо люблю скрам, в основном потому что обычно его применяют бездумно и просто так, мне больше по душе какой-нибудь канбан или FDD. Но менеджмент обычно даже не вкурсе про существование чего-бы то ни было еще помимо скрама.
> Вам лучше бы было как-то более явно выразить свою мысль
Мысли не было — был вопрос на который вы не ответили. От ответа на него будет зависеть то как я буду раскрывать мысль дальше.
От того откуда приходят требования и как происходит проверка эффективности фич (и происходит ли вообще) зависит взлетит скрам или нет. Причем тут речь не только про скрам — любой итеративный подход.
Ссылки же были к другой части вашего комментария (и там было согласие с мыслью что все эти scrum сертификации и треннинги это просто отдельная индустрия сама в себе).
Я обычно наблюдаю чуть другое. Вот услышал кто-то из менеджеров про скрам (потому что в целом, если быть честными, про другие фреймворки как-то не очень слышно, если не искать), прочитал пару статей про то как скрам позволяет делать больше теми же силами и решил что «ништяк, надо вводить!»
Вот только основной момент — принятие решений на основе фидбэка после каждой итерации, этого как-то нет. То есть когда менеджмент слышит «делать больше теми же силами» в их головах это волшебство и магия которая просто будет позволять лучше планировать, контролировать и деливерить больше фич. Тогда как в реальности под этой фразой подразумевается обратное — резать фичи, приоритизировать, обрабатывать фидбэк от пользователей после каждой итерации, что позволит теми же силами доставлять пользователям больше пользы (пускай фич будет меньше даже чем обычно). Ну там объясняется это все законом Парето и прочими эмпирическими наблюдениями.
ну то есть если компания вводит аджайл — она часто вводит его весьма избирательно. То что вся эта хрень с короткими итерациями и быстрым фидбэком для минимизации рисков (мы инвестируем чуть-чуть в разработку самого ценного из фичи что бы быстро узнать стоит ли продолжать и будут ли фичей пользоваться), и что это подразумевает кординальные изменения на уровне всей организации.
Особенно радуют аутсорс компании которые практикуют скрам. Как правило у них SoW подписан на пол года работы, фиксированный бюджет и коммитменты по функционалу, но всем говорят что они аджайл.
Простите, а чего вы ожидали? Скрам — это вам не детально проработанный процесс, это фреймворк на базе которого вы должны выстраивать свои процессы. Он вам дает основу для ведения итеративной разработки. Дальше уж извольте додумывать процессы самостоятельно, для этого вам даются ретроспективы. Хотите инструмент для выявления проблем — добавьте к скраму канбан (ограничения на колонки) и многие проблемы будут вылазить сами по себе. Опять же если команда будет соблюдать выбранные ограничения.
Ну и опять же — у вас поквартальное планирование, вы не собираете фидбэк после каждой итерации, вы не анализируете приносит ли функционал ценности? Может вам вовсе не нужен скрам?
Описанная же вами ситуация — это исключительно про взаимодействие людей в команде. Ибо в целом так смысла в дэйли нету, если все вопросы можно тэт-а-тэт порешать. Скрам у вас, XP, FDD или RUP — проблема остается.
Если вы спросите у Васи на дэйли в чем проблема, то это ни сколечки не «обмакнет» его в глазах команды. Всегда будут люди, которые будут до последнего пытаться решить проблемы своими силами. Скрам или не скрам — климат вы выстраиваете тот который выстраиваете, выбранный фреймворк для ваших процессов на это не влияет (не должен влиять)
Так это же сборка, причем тут сама библиотека. Собирайте на CI, дистрибьютте итоговый бинарник.
докер, ансиблы и прочие штуки которые позволят вам иметь одинаковое окружение
Ты присядешь или не являешься собой?
complimentary это еще и приветственный. Ну так...
Лучше объясните каким образом в 90% ситуаций скрам используется исключительно для предоставления контрольных точек менеджменту а не, собственно, для того зачем он нужен.
Вы правильно заметили на тему "мужественности". Но все же от "все тесты" это все очень далеко. Я как-то общался с человеком которому не нравилось TDD потому что он месяц тесты писал и только потом писал реализацию. Сами понимаете как это не эффективно.
На тему же "мужественности" — для простых задач можно сразу накидать несколько тест кейсов (триангуляция, в терминах Кента Бэка) и потом реализовывать код. И чаще всего вы врядли захотите двигаться совсем уж маленькими шагами. А вот если вы написали несколько тестов и не можете написать код — всегда можно убрать пару тестов и двигаться более маленькими шажками. Тут все очень субъективно. По сути основной момент — насколько вы уверены. Не уверены — сокращайте длину итераций.
Возможно VolCh меня поправит, но мне кажется речь идет о ситуации когда изменения вносятся в код, который писался давно и как следствие разработчику лучше разобраться почему то поведение которого вроде бы небыло (иначе зачем тест) — работает.
да, довольно часто это все избыточно (опять же смотрим про уверенность), но если уверенности нет — имеет смысл.
Правда я не соглашусь с тем что бы заставлять людей так делать, в большинстве случаев это действительно избыточно.
Мутационные тесты хорошо подходят для определения качества вашей тест сюиты. Да, долго, но зато потом можно лучше понимать в чем проблемы тестов.
на фоне того что вы в консоль синхронно пишите? э не.
Вы что-то путаете.
symfony/console
самодостаточный пакет который по умолчанию не тянет ничего дополнительно.Ну и опять же — простая логика. Если вам нужно текст раскрасить в CLI приложение, кто скорее всего нужно будет и аргументы распарсить, и в целом почему бы и нет.
Опять же, на примерах функции деления плохо просматривается суть зачем так делать. Ну я к тому что если разработчик чувствует уверенность он может существенно увеличить длину итерации (написать сразу 2-3 теста, скипнуть часть про "всегда должен быть красный тест" и т.д.) Ну и обычно уверенность уменьшается пропорционально сложности задачи.
Словом, Кент Бэк все это придумывал что бы регулируя длину итераций чувствовать себя уверенно в коде. Кому-то это для уверенноси не нужно, а кому-то — недостаточно только этого.
Тем что реализация не влияет на процесс формализации требований, и от того меньше технических деталей в эти требования проникает. Как следствие, поскольку речь идет о юнит тестах, больше шансов спроектировать более изолированные контракты.
Когда разработчики, особенно те кто только начинают писать тесты, пишут тесты после реализации, чаще всего эти тесты тупо дублируют реализацию.
Все вместе, а дальше зависит от человека и того на что он будет ставить акцент. Опять же, TDD не универсальный инструмент, есть категория людей которым это все не помогает либо не нужно (просто могут менять код и их это не особо пугает).
оно не призвано ее обеспечивать. TDD это не про тесты, тесты тут только инструмент, а суть больше в проектировании интерфейсов и модулей с низкой связанностью. Ну и никто не запрещает вам прогнать мутационные тесты и узнать реальное состояние дел с покрытием.
потому в кавычках. Опять же, тесты до имплементации занимают меньше времени чем после. Вне зависимости от уровня разработчика эти тесты будут качественно лучше, опять же модули будут более изолированы.
Тут стоит сделать ремарку — если вы УЖЕ можете делать более изолированные модули, вы УЖЕ умеете писать тесты неплохо, вы понимаете как определять их качество и т.д. то ценности от TDD для вас возможно нет.
Кент Бэк в своей книге (опять же нет под рукой, не могу дать точную отсылку) писал о маленьком исследовании где эта гипотиза по сути опровергается. Там типа ставился эксперемент в духе пишем одно и то же приложение 10 раз (что-то простенькое, консольная симуляция игры в боулинг например), половина тесты до, половина тесты после, засекаем время и т.д.
Опять же — я не смог нагуглить полноценных исследований на эту тему. Но в целом (во всяком случае на основании моих опытов) я могу объяснить это за счет того, что в случае TDD у нас этап написания тестов и этап формализации требований (а он есть всегда вне зависимости от подхода) — один и тот же этап, что позволяет меньше переключать контекст. Ну и еще одно интересное наблюдение — писать тесты после реализации обычно скучнее (опять же судить могу только по себе и людям с которыми когда-то эти темы обсуждал).
это никогда не проще и не дешевле, поскольку на момент "переписывания" требования будут продолжать меняться, а фризить функционал на пол года никто не будет.
Постепенно переписывать — можно, так или иначе придется. А вот с нуля — никогда не окупится.
Ну заблуждени тут из ваших личных привычек. Лично меня подобное не смущает. Ну и опять же вопрос в том что имутабельность это хорошо (потому что можно всегда вывести типы и отследить стэйт не запуская код) но получать новые значения все еще нужно. И проще клонировать объект при изменениях (можно частично если эти части не меняются).
Ну и если вы все еще считаете что «это не очевидно» и т.д. предлагаю вам не личные субъективные ощущения (или мои) использовать, а провести полноценное исследование данного вопроса. Тогда можно будет делать выводы.
он не получает фидбэк, потому в целом какая разница? В этом же собственно основная проблема ватерфола, а не в том что «нет спринов». Нет фидбэка — приоритизация происходит на основе «я так вижу». А при таком раскладе можно и более ватерфольные штуки использовать (FDD то же)
Ну и опять же — если у оунера есть готовность слить результаты работы в унитаз — не понятно зачем так детально это прорабатывать.
Мысль очень простая — скрам это не про то как вы дружно там дэйлики проводите, и спринты планируете. Это все в общем то инструменты. А основная штука в приоритизации задач, выделении важных вещей, анализе фидбэка после каждой итерации (опять же для приоритизации). А потому я и спросил — с введением в команде скрама процесс формирования бэклога хоть как-то поменялся? или в целом что там что там есть некий человек который просто говорит что делать? Ну мол, есть скоуп работы скажем на квартал и вы просто пилите от спринта к спринту или все же спринтам привязываются цели?
В больших компаниях как правило процесс формирования бэклога никак не меняется от введения скрама в дев командах. От того толку от этого скрама там не много, хоть десять коучей наймите. Ну и опять же, если вся компания представлена одной маленькой скрам командой с продукт оунером, то скорее всего эта команда будет пытаться деливерить то что важно (ибо на то что не важно обычно нет денег). И тут скрам помогает.
Уж извините за скомканность мысли, но в целом мысль простая — скрам работает там, где людям важно максимально ценность для пользователя деливерить а не максимум фич (отсюда важны все эти цели спринтов, фидбэк луп и прочее). Ну и в нем нет смысла если вы и так прекрасно представляете что вам нужно заделиверить и нет нужды в эксперементах.
Заметили ли вы что обычно когда все идет хорошо процессы хвалят те кто их внедрял, а в случае неудачи ругают те кто по ним работал? Если да — тогда наша статистика в целом совпадает (такая же у меня например в случае с kanban)
Но все же, повторюсь. Описанная вами ситуация будет воспроизводиться и в случае с каким-нибудь RUP, как минимум потому что речь идет о проблема коммуникаций между людьми в рамках одной задачи. Ну то есть я не понимаю почему для вас спросить на дэйли у человека в чем проблема и как ему помочь — это мокнуть его перед командой.
главное не попасться в классическую ошибку выжевшего.
p.s. если что, я не особо люблю скрам, в основном потому что обычно его применяют бездумно и просто так, мне больше по душе какой-нибудь канбан или FDD. Но менеджмент обычно даже не вкурсе про существование чего-бы то ни было еще помимо скрама.
Мысли не было — был вопрос на который вы не ответили. От ответа на него будет зависеть то как я буду раскрывать мысль дальше.
От того откуда приходят требования и как происходит проверка эффективности фич (и происходит ли вообще) зависит взлетит скрам или нет. Причем тут речь не только про скрам — любой итеративный подход.
Ссылки же были к другой части вашего комментария (и там было согласие с мыслью что все эти scrum сертификации и треннинги это просто отдельная индустрия сама в себе).
Пока из всего что мною было прочитано и просмотрено лидирует вот это: Surviving Your Inevitable Agile Transition — J.B. Rainsberger — сухо, никакого популизма.
Что до Холуба — мне версия Дэйва Томаса нравится больше.
Меняется ли для команды процесс формирования бэклога?
У Дэйва Томаса (один из авторов agile manifesto) есть доклад на эту тему — Agile is dead. Ну и есть очень неплохая постановка на тему типичных скрам коучей: A Retake on the Agile Manifesto • Humble, Thomas, Badiceanu, Fowler & Kirk
Вот только основной момент — принятие решений на основе фидбэка после каждой итерации, этого как-то нет. То есть когда менеджмент слышит «делать больше теми же силами» в их головах это волшебство и магия которая просто будет позволять лучше планировать, контролировать и деливерить больше фич. Тогда как в реальности под этой фразой подразумевается обратное — резать фичи, приоритизировать, обрабатывать фидбэк от пользователей после каждой итерации, что позволит теми же силами доставлять пользователям больше пользы (пускай фич будет меньше даже чем обычно). Ну там объясняется это все законом Парето и прочими эмпирическими наблюдениями.
ну то есть если компания вводит аджайл — она часто вводит его весьма избирательно. То что вся эта хрень с короткими итерациями и быстрым фидбэком для минимизации рисков (мы инвестируем чуть-чуть в разработку самого ценного из фичи что бы быстро узнать стоит ли продолжать и будут ли фичей пользоваться), и что это подразумевает кординальные изменения на уровне всей организации.
Особенно радуют аутсорс компании которые практикуют скрам. Как правило у них SoW подписан на пол года работы, фиксированный бюджет и коммитменты по функционалу, но всем говорят что они аджайл.
Простите, а чего вы ожидали? Скрам — это вам не детально проработанный процесс, это фреймворк на базе которого вы должны выстраивать свои процессы. Он вам дает основу для ведения итеративной разработки. Дальше уж извольте додумывать процессы самостоятельно, для этого вам даются ретроспективы. Хотите инструмент для выявления проблем — добавьте к скраму канбан (ограничения на колонки) и многие проблемы будут вылазить сами по себе. Опять же если команда будет соблюдать выбранные ограничения.
Ну и опять же — у вас поквартальное планирование, вы не собираете фидбэк после каждой итерации, вы не анализируете приносит ли функционал ценности? Может вам вовсе не нужен скрам?
Описанная же вами ситуация — это исключительно про взаимодействие людей в команде. Ибо в целом так смысла в дэйли нету, если все вопросы можно тэт-а-тэт порешать. Скрам у вас, XP, FDD или RUP — проблема остается.
Если вы спросите у Васи на дэйли в чем проблема, то это ни сколечки не «обмакнет» его в глазах команды. Всегда будут люди, которые будут до последнего пытаться решить проблемы своими силами. Скрам или не скрам — климат вы выстраиваете тот который выстраиваете, выбранный фреймворк для ваших процессов на это не влияет (не должен влиять)