Отнюдь. Мой "эджайл" другой (и больше я люблю перевод "адаптивный подход")
Точнее из моего опыта:
Кроссфункиональность команды!=кроссфункиональность каждого ее члена;
Стабильный состав команды -> важное условие достижения эффективности;
Вовлечение члена команды во все стадии разработки продукта (от идеи до продакшна) -> помогает человеку не быть винтиком и чувствовать свой вклад лучше, чем в традиционных подходах (ака водопад).
Статья во многом интересная, много пищи для размышлений, но некоторые предпосылки мне кажутся ошибочными.
Эджайл про умение адаптироваться, и индиферентен к тому, адаптироваться под повышение маржинальности или под удовлетворении потребности пользователя. Тут выбор за нами.
Спасибо за серию статей, очень интересно знать опыт коллег по счастью/несчастью. У меня есть вопрос насчет системного подчинения — правильно ли я понимаю, что вы имеете ввиду создание механизмов поощрения/порицания, которые воздействуют на объект управления таким образом, что он сам принимает решение о подчинении? (я бы заменил слово на сотрудничество, звучит менее отталкивающе чтоли).
Т.е., для примера, с штрафом за заезд за стоп линию — решение о не заезде принимает сам водитель. Он может и заехать, но это ему дороже (негативное подкрепление)?
В дальнейших статьях вы поделитесь приемами обеспечения системного подчинения(сотрудничества)?
Как вы думаете, есть ли смысл покрывать логику логирования юнит тестами? Врядли каждый вывод в лог стоит текста, а критичные можно попробовать протестировать Е2Е тестами.
Задача имеет некоторый объем, идеальное время исполнения идеальным исполнителем — Вид.
Предположим:
Вид = 20 часов. Тогда, ожидания заказчика неоправданны. Кто должен разрулить эту ситуацию и как с этим поможет TOTE?
Вторая вероятность:
Вид = 10 часов. Ожидания заказчика неоправданны, но исполнитель выполняет задачу дольше, чем идеальное время исполнения. Кто виноват (если есть такие), кто должен разрулить эту ситуацию, и как с этим поможет ТОТЕ?
Я бы переживал не насчет выведения из равновесия, а насчет неявного поощрения «срезания углов» за счет изначально неправильно поставленной задачи. Время выполнения не должно быть критерием успешности, по моему мнению.
[ИМХО] Любой руководитель может прикинуть, сколько займет задача, и иметь это ввиду, но только для того, чтоб знать, когда прояснить статус задачи и предложить помощь.
А разработчик должен сконцентрироваться на главном — самой задаче и качестве ее решения.
Между прогнозом времени и [видимом] временном лимите при постановки задачи есть существенная разница.
Имхо это создает ненужное психологическое давление и отвлекает внимание от важного (т.е. решение поставленной задачи). Я бы оценки делал, но оставлял их при себе — они помогали бы мне достигать все трех поставленных целей, но без лишнего давления на работника.
Ну раз Вы знаете, в каком количестве я имел опыт с «ФП», какое отношение имеет «ФП» к «асинхронщине» и «параллельности», и что нужно знать «прежде всего» — то Вам, конечно, виднее :)
Но в последствии при рефакторинге реальных приложений я много раз использовал именно функциональный подход, где возможно.
В целом это отличный пойнт — у всего есть границы и ниши применимости. Есть вещи, при которых ООП реально более удобен, есть вещи, для которых удобнее функциональный подход, а для некоторых удобнее декларативный.
Мне кажется главный посыл статьи не в том, что бы все всё бросили и стали писать все подряд на Clojure, а что бы люди научились использовать различные подходы и могли выбирать тот, который им кажется более выигрышным в текущей ситуации.
Таким образом due date это такой lead time/эстимация привязанный к дате? Мне стало интересно, как быть тогда при следующих ситуациях:
-Фича нужна бизнесу в продакшне раньше чем due date?
-Разработчик «срезает» углы, чтобы успеть в due date?
Так мы пытаемся избежать ситуации коллективной ответственности: ведь если за что-то отвечают все, значит, де-факто не отвечает никто.
Я не совсем согласен с этим правилом, считаю (надеюсь) оно устарело.
У него есть и обратная сторона — если за задачу ответственен только один человек, то все проблемы этой задачи — только его проблемы. У других и СВОИ задачи есть. Мне кажется это негативно сказывается на командном взаимодействии.
Мне видится более эффективным (хоть и редким, но мне случалось) командная ответственность. Речь идет, конечно, о стабильных и кроссфункциональных командах размером 5-7 человек.
Оптимальное покрытие автотестами — тема на самом деле важная, но сложная для понимания. Единственный ориентир, известный мне (пирамида тестирования) неплох, но несовершенен.
В зависимости от внутреннего устройства приложения необходимость тех или иных типов автотестов варьируется.
Мы хотим делать БОЛЬШЕ unit тестов не потому, что любим их, а потому, что они самые быстрые и точные. Весь функционал, который можно покрыть unit тестами лучше всего ими же и покрыть.
Тем не менее, многие вещи unit тесты покрыть не в состоянии, к примеру — конфигурацию Spring контекста, валидации, аннотации, интеграцию со сторонними либами. Иногда доходило до того, что мне удобнее было написать свой велосипед покрытый юнит тестами, чем корячится и покрывать тот же функционал, реализованный с помощью сторонней библиотеки интеграционным тестом. (пример — собственный маппер для разных классов против готовых мапперов, аля orika)
Многие используют мантру «нельзя все покрыть unit тестами» или «зачем дублировать что-то на уровне unit тестов если можно все сразу проверить с UI». Для того, чтоб разобраться с первым кейсом я рекомендую попробовать ради интереса разработать какую-то фичу используя TDD и добавлять тесты уровнем выше только если это реально необходимо. Со вторым я даже не вижу смысла бороться — нет ничего печальнее и поучительнее чем мучительная поддержка uber-свита тестов на уровне UI :)
у меня есть встречное, возможно лучшее предложение — может вы сделаете рассылку на ваших пользователей с лицензией с вопросом, заинтересованы ли они в версии под Linux и сколько они готовы заплатить. Тогда вы сможете оценить ROI и реальный спрос платежеспособной целевой аудитории.
— Что вы можете посоветовать тем, кто решил начать изучать функциональное программирование?
Вагиф Абилов: Посоветовал бы не относиться к этому выбору как к какому-то серьезному жизненному шагу. Я заметил, что пробовать изменить основной язык у программистов считается каким-то радикальным шагом в отличие, например, от смены базы данных или какого-то фреймворка. Например, разработчики на javascript меняют библиотеки, которыми они пользуются, как перчатки. И это не выглядит каким-то серьезным изменением. Если вы перешли с реляционной базы данных на document-базу, это во многом более серьезный шаг, чем перейти с одного .NET языка на другой.
Спасибо! Я сразу почувствовал серьезный и просчитанный процесс, больше свойственный для традиционных моделей. Если не секрет, насколько вы довольны текущим процессом? Я в последнее время работаю только с гибкими методологиями, и мне очень любопытно узнать, как, в современных условиях, получается делать классный софт по традиционным моделям.
Может быть получится больше понять границы применимости… Все таки, конструкторская работа — еще и стандартизируемая, т.е. чертежи должны оформляться по ГОСТ, и это тоже не способствует использованию Agile. Как вы думаете?
Спасибо за статью, очень интересно знать как коллеги по ремеслу организуют работу в их условиях. Может расскажете еще про подход к разработке (какая модель используется, как работаете с требованиями) и про длительность цикла между версиями?
Я думаю, что тут выдается желаемое за действительное. Мне кажется, что .Net Core был скорее вопросом выживания платформы, а не ее доминирования. Как можно прочесть между строк в самой статье — не кросс платформенные решения уже практически не жизнеспособны.
С другой стороны, странно было бы слышать от идеологов и сторонников технологии «надеюсь теперь не сдохнем» — это вряд ли привлечет новых сторонников :)
Хотя в любом случае, я сторонник здоровой конкуренции — если .Net Core будет объективно лучше Java — выиграют все.
Отнюдь. Мой "эджайл" другой (и больше я люблю перевод "адаптивный подход")
Точнее из моего опыта:
Кроссфункиональность команды!=кроссфункиональность каждого ее члена;
Стабильный состав команды -> важное условие достижения эффективности;
Вовлечение члена команды во все стадии разработки продукта (от идеи до продакшна) -> помогает человеку не быть винтиком и чувствовать свой вклад лучше, чем в традиционных подходах (ака водопад).
Статья во многом интересная, много пищи для размышлений, но некоторые предпосылки мне кажутся ошибочными.
Эджайл про умение адаптироваться, и индиферентен к тому, адаптироваться под повышение маржинальности или под удовлетворении потребности пользователя. Тут выбор за нами.
Т.е., для примера, с штрафом за заезд за стоп линию — решение о не заезде принимает сам водитель. Он может и заехать, но это ему дороже (негативное подкрепление)?
В дальнейших статьях вы поделитесь приемами обеспечения системного подчинения(сотрудничества)?
Спасибо за статью!
Как вы думаете, есть ли смысл покрывать логику логирования юнит тестами? Врядли каждый вывод в лог стоит текста, а критичные можно попробовать протестировать Е2Е тестами.
(время исполнения) Висп: 20 часов
(ожидаемое время) Вож: 2 часа.
Задача имеет некоторый объем, идеальное время исполнения идеальным исполнителем — Вид.
Предположим:
Вид = 20 часов. Тогда, ожидания заказчика неоправданны. Кто должен разрулить эту ситуацию и как с этим поможет TOTE?
Вторая вероятность:
Вид = 10 часов. Ожидания заказчика неоправданны, но исполнитель выполняет задачу дольше, чем идеальное время исполнения. Кто виноват (если есть такие), кто должен разрулить эту ситуацию, и как с этим поможет ТОТЕ?
[ИМХО] Любой руководитель может прикинуть, сколько займет задача, и иметь это ввиду, но только для того, чтоб знать, когда прояснить статус задачи и предложить помощь.
А разработчик должен сконцентрироваться на главном — самой задаче и качестве ее решения.
Имхо это создает ненужное психологическое давление и отвлекает внимание от важного (т.е. решение поставленной задачи). Я бы оценки делал, но оставлял их при себе — они помогали бы мне достигать все трех поставленных целей, но без лишнего давления на работника.
Как считаете?
А в чем сакральный смысл времени, выделенного на подзадачу, и кто его придумывает?
Но в последствии при рефакторинге реальных приложений я много раз использовал именно функциональный подход, где возможно.
В целом это отличный пойнт — у всего есть границы и ниши применимости. Есть вещи, при которых ООП реально более удобен, есть вещи, для которых удобнее функциональный подход, а для некоторых удобнее декларативный.
Мне кажется главный посыл статьи не в том, что бы все всё бросили и стали писать все подряд на Clojure, а что бы люди научились использовать различные подходы и могли выбирать тот, который им кажется более выигрышным в текущей ситуации.
Как считаете?
Я рекомендую каждому попробовать подобное самому, а потом проанализировать удобство чтения, тестирования, написания и отладки кода.
-Фича нужна бизнесу в продакшне раньше чем due date?
-Разработчик «срезает» углы, чтобы успеть в due date?
Я не совсем согласен с этим правилом, считаю (надеюсь) оно устарело.
У него есть и обратная сторона — если за задачу ответственен только один человек, то все проблемы этой задачи — только его проблемы. У других и СВОИ задачи есть. Мне кажется это негативно сказывается на командном взаимодействии.
Мне видится более эффективным (хоть и редким, но мне случалось) командная ответственность. Речь идет, конечно, о стабильных и кроссфункциональных командах размером 5-7 человек.
Спасибо.
В зависимости от внутреннего устройства приложения необходимость тех или иных типов автотестов варьируется.
Мы хотим делать БОЛЬШЕ unit тестов не потому, что любим их, а потому, что они самые быстрые и точные. Весь функционал, который можно покрыть unit тестами лучше всего ими же и покрыть.
Тем не менее, многие вещи unit тесты покрыть не в состоянии, к примеру — конфигурацию Spring контекста, валидации, аннотации, интеграцию со сторонними либами. Иногда доходило до того, что мне удобнее было написать свой велосипед покрытый юнит тестами, чем корячится и покрывать тот же функционал, реализованный с помощью сторонней библиотеки интеграционным тестом. (пример — собственный маппер для разных классов против готовых мапперов, аля orika)
Многие используют мантру «нельзя все покрыть unit тестами» или «зачем дублировать что-то на уровне unit тестов если можно все сразу проверить с UI». Для того, чтоб разобраться с первым кейсом я рекомендую попробовать ради интереса разработать какую-то фичу используя TDD и добавлять тесты уровнем выше только если это реально необходимо. Со вторым я даже не вижу смысла бороться — нет ничего печальнее и поучительнее чем мучительная поддержка uber-свита тестов на уровне UI :)
"На другой руке" (англ. Идиома on the other hand) переводится как "с другой стороны".
А так, спасибо за актуальный перевод полезного отрывка из книги!
Отлично сказано!
Может быть получится больше понять границы применимости… Все таки, конструкторская работа — еще и стандартизируемая, т.е. чертежи должны оформляться по ГОСТ, и это тоже не способствует использованию Agile. Как вы думаете?
С другой стороны, странно было бы слышать от идеологов и сторонников технологии «надеюсь теперь не сдохнем» — это вряд ли привлечет новых сторонников :)
Хотя в любом случае, я сторонник здоровой конкуренции — если .Net Core будет объективно лучше Java — выиграют все.