That said, today’s agile is not the same agile that was discussed at the meeting.
и далее по тексту.
2. Software Craftsmanship Manifesto — конечно о другом, об индивидуальном профессионализме
и профессиональной этике. Это все безусловно важно, но работает уровнем ниже.
Agile это идея для коллектива, Craftsmanship — для отдельно взятого профессионала.
Безусловно, алгоритмы должны быть максимально идентичны.
Конечно это не мое требование, а требование сайта: benchmarksgame.alioth.debian.org/u64q/nbody-description.html#nbody We ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result.
Спасибо за комментарий, но посмотрите на это с другой стороны.
Банить языки программирования позволяющие оптимизации безусловно не нужно,
более того глупо. Однако, если мы будем целенаправленно оптимизировать программы
под задачи и возможности языка, мы получим конкурс программистов — кто лучше оптимизирует, а это совсем другой жанр. То что именно так все и происходит безусловно удручает.
Спасибо за комментарий, я уже начал беспокоиться что никто так и не заступится за erlang :)
С одной стороны вы правы, в решении erlang нет явного читерства, в отличии от Go,
просто исполняющая платформа достаточно умная чтобы понять что на одном ядре
данная программа будет выполнена быстрее. Платформа Erlang в этом смысле достаточно
умная, факт.
Тем не менее другой факт состоит в том что вся логика была выполнена на одном
процессорном ядре, таким образом мы ничего не узнали о том какие накладные расходы
в Erlang на взаимодействие между физическими процессорами.
А ведь именно это и интересно.
Все дело в том что задача сформулирована плохо, а именно она не подразумевает
никакого выгоды от параллельного ее решения на нескольких ядрах процессора,
наоборот — оптимальное решение выполнить все на одном физическом ядре с
минимумом накладных расходов. Erlang отработал именно так, но в результате мы
не узнали про Erlang то что хотели — как там реальные межпроцессорные коммуникации.
Было бы правильно изменить условие задачи, например сказав что по кольцу нужно крутить
5-ть сообщений, с шагом в 101. Тогда появился бы практический смысл утилизировать
все процессорные ядра.
— Что касается задачи с деревьями, там другая ситуация. Java работает быстро в частности
потому что там сборка мосора идет параллельно, в отличии от решений на C, например.
Однако, разрыв между Java и C слишком велик и даже если бы в Java был указан
однопоточный сборщик мусора, решение все равно отработало бы быстрее. Просто потому
что в любых однопоточных алгоритмах накладные расходы всегда меньше чем в
распределенных.
Таким образом, в задаче с деревом по Java можно говорить что однопоточное решение
будет практически таким же быстрым как и с параллельной сборкой мусора, по этому
я считаю что такое решение можно засчитать. А в erlang мы так и не увидели накладные
расходы на межроцессорную коммуникацию, соответственно было бы неправильно
экстраполировать что решение на Erlang для нескольких процессорных ядер будет
работать также быстро.
Спасибо за комментарий. Согласен, выражение «попала в опалу» не совсем корректно,
правильнее было бы сказать «энтузиазм к кибернетике был потерян».
Что касается САУ, согласитесь, есть некоторая качественная разница между механизмом
выпуска избыточного пара и программой которая может обыграть чемпиона мира по шахматам.
Любопытный комикс, но немного «устаревший». Описанная история представляет
модель так называемых Экспертных Систем, т.е. систем требующих программирования.
Сейчас, используя Нейронные Сети и прочие техники Машинного Обучения,
комикс мог бы завершиться примерно так: кот сидит перед роботом и чистит картошку,
одну за одно и так две тонны. В результате в какой то момент робот сам соображает
как же нужно чистить картошку. Ничего не нужно программировать, в этом суть изменения.
Спасибо за комментарий и основательную аргументацию, но я постараюсь вам возразить.
Существенное повышение производительности труда за счет внедрения тех или иных технологий, как 18-м веке, ваш пример, так и в 19-м и 20-м, да и в первой половине 21-го века
хоть и приводят приводят к полной замене ручного труда в определенных отраслях,
как вы говорите, в ткачестве, но при этом все еще остается множество других профессий
где можно применить себя и множество рынков для расширения сбыта.
Вы называете три способа использовать дополнительную прибыль, но если в 18 веке
возможность реализовать их в масштабе были ограничены техническими средствами,
то сейчас, как показывает Форд, таких ограничений больше нет.
Что если вам удастся расширить производство чтобы покрыть весь мировой спрос на пальто, при том что в прочих отраслях происходит то же самое.
Спасибо за комментарий. В 2015 году Министерство Труда Германии выпустило
любопытный документ Green Paper Work 4.0, в частности там довольно подробно
разбирается тема сокращения длительности рабочего дня и частичной занятости. Любопытное чтение.
Большое спасибо за детальный комментарий.
Согласен с вам, не смотря на то что некоторые главы откровенно устарели,
в целом книга вполне актуальна. Мы продолжаем сталкиваться с теми же проблемами
и совершать те же ошибки.
надо ли врать заказчику при оценке проекта я не пишу, поскольку очевидно, что врать
А вы тоже используете две джиры, одну для разработчиков, другую для заказчиков? ;)
А если серьезно, следующее все же не соответствует действительности.
У Брукса на подобные вопросы дан какой-либо ответ.
Книга Брукса это список проблем нежели решений, более того, сам Брукс систематизировал их в список из двух сотен утверждений требующих критики.
Более того, сам Брукс сетует что получил слишком мало критики на свою книгу.
Спасибо за подробный комментарий! Я не совсем уверен, спорите ли вы со мной или дополняете, тем не менее, один момент кажется мне очень важным.
Ожидать же от бизнеса понимания в данной ситуации — все равно что ожидать...
1. Безусловно многие из нас делают ошибки путая достаточно определенные и предсказуемые работы и новые, непредсказуемые, для которые оценки основанные на предыдущем опыте не работают.
2. Тем не менее, часто мы вполне понимаем что ступаем на terra incognita, и в лучшем случае мы можем оценить сроки и бюджет с ошибкой в 6-10 раз.
3. Я ни в коем случае не пытаюсь апеллировать к тому чтобы бизнес «понял» и «простил» разработку, и «предоставил столько времени и ресурсов сколько разработчики захотят» — во первых такое отношение было бы снисходительным, а во вторых — так дела не делаются.
4. Однако, неопределенность сроков сама по себе никуда не денется, вне зависимости от того кто берет на себя ответственность за соблюдение сроков которые невозможно гарантировать.
5. Это проблема, и со стороны бизнеса можно ее игнорировать, а можно пойти навстречу разработке.
Спасибо за комментарий, но пожалуй я вам возражу. Одна из идей которую я хотел
раскрыть состоит в том что не имеет значения «тип» проекта, как вы говорите.
Возможность или невозможность осуществить предсказуемое планирование
определяется тем, — выполняются ли для того необходимые условия.
Более того, решение многих задач для профессионалов может быть вполне рутинной,
планируемой работой. Однако, если лично вы не обладаете необходимой экспертизой
и работа, по какой то причине, досталась лично вам — вы попадаете в область непредсказуемого, соответственно и планирование становится невозможным.
KPI (Key Performance Indicators) — инструмент для улучшения процесса (производительности).
OKR (Objectives & Key Results) — инструмент для достижения целей (проектов).
(надеюсь так отличие достаточно наглядно.)
Теперь что касается OKR+Scrum vs KPI+Scrum.
В теории KPI+Scrum вполне себе вариант, но с точки зрения управления бизнесом
это более слабый инструмент управления, поскольку он позволяет требовать
только улучшения конкретных метрик.
С другой стороны, OKR+Scrum это более сильный инструмент, поскольку он
позволяет ставить цели уровня бизнеса а не только метрики уровня бизнеса.
Почему OKR хорошо совместимы со с Scrum — очевидно, они не навязывают
способ достижения цели (впрочем как и KPI не навязывают способ улучшения процесса).
2. Kanban это мелкий тактический инструмент, и далеко не главная часть системы Lean.
Kanban не конкурент Scrum просто потому что это тактический инструмент огранизации
процесса передачи работы и все. Это не методология.
1. Позиция Robert C. Martin относительно Agile высказан им прямо в статье:
techbeacon.com/uncle-bob-martin-agile-manifesto-15-years-later
и далее по тексту.
2. Software Craftsmanship Manifesto — конечно о другом, об индивидуальном профессионализме
и профессиональной этике. Это все безусловно важно, но работает уровнем ниже.
Agile это идея для коллектива, Craftsmanship — для отдельно взятого профессионала.
Конечно это не мое требование, а требование сайта: benchmarksgame.alioth.debian.org/u64q/nbody-description.html#nbody
We ask that contributed programs not only give the correct result, but also use the same algorithm to calculate that result.
Банить языки программирования позволяющие оптимизации безусловно не нужно,
более того глупо. Однако, если мы будем целенаправленно оптимизировать программы
под задачи и возможности языка, мы получим конкурс программистов — кто лучше оптимизирует, а это совсем другой жанр. То что именно так все и происходит безусловно удручает.
С одной стороны вы правы, в решении erlang нет явного читерства, в отличии от Go,
просто исполняющая платформа достаточно умная чтобы понять что на одном ядре
данная программа будет выполнена быстрее. Платформа Erlang в этом смысле достаточно
умная, факт.
Тем не менее другой факт состоит в том что вся логика была выполнена на одном
процессорном ядре, таким образом мы ничего не узнали о том какие накладные расходы
в Erlang на взаимодействие между физическими процессорами.
А ведь именно это и интересно.
Все дело в том что задача сформулирована плохо, а именно она не подразумевает
никакого выгоды от параллельного ее решения на нескольких ядрах процессора,
наоборот — оптимальное решение выполнить все на одном физическом ядре с
минимумом накладных расходов. Erlang отработал именно так, но в результате мы
не узнали про Erlang то что хотели — как там реальные межпроцессорные коммуникации.
Было бы правильно изменить условие задачи, например сказав что по кольцу нужно крутить
5-ть сообщений, с шагом в 101. Тогда появился бы практический смысл утилизировать
все процессорные ядра.
— Что касается задачи с деревьями, там другая ситуация. Java работает быстро в частности
потому что там сборка мосора идет параллельно, в отличии от решений на C, например.
Однако, разрыв между Java и C слишком велик и даже если бы в Java был указан
однопоточный сборщик мусора, решение все равно отработало бы быстрее. Просто потому
что в любых однопоточных алгоритмах накладные расходы всегда меньше чем в
распределенных.
Таким образом, в задаче с деревом по Java можно говорить что однопоточное решение
будет практически таким же быстрым как и с параллельной сборкой мусора, по этому
я считаю что такое решение можно засчитать. А в erlang мы так и не увидели накладные
расходы на межроцессорную коммуникацию, соответственно было бы неправильно
экстраполировать что решение на Erlang для нескольких процессорных ядер будет
работать также быстро.
правильнее было бы сказать «энтузиазм к кибернетике был потерян».
Что касается САУ, согласитесь, есть некоторая качественная разница между механизмом
выпуска избыточного пара и программой которая может обыграть чемпиона мира по шахматам.
модель так называемых Экспертных Систем, т.е. систем требующих программирования.
Сейчас, используя Нейронные Сети и прочие техники Машинного Обучения,
комикс мог бы завершиться примерно так: кот сидит перед роботом и чистит картошку,
одну за одно и так две тонны. В результате в какой то момент робот сам соображает
как же нужно чистить картошку. Ничего не нужно программировать, в этом суть изменения.
Существенное повышение производительности труда за счет внедрения тех или иных технологий, как 18-м веке, ваш пример, так и в 19-м и 20-м, да и в первой половине 21-го века
хоть и приводят приводят к полной замене ручного труда в определенных отраслях,
как вы говорите, в ткачестве, но при этом все еще остается множество других профессий
где можно применить себя и множество рынков для расширения сбыта.
Вы называете три способа использовать дополнительную прибыль, но если в 18 веке
возможность реализовать их в масштабе были ограничены техническими средствами,
то сейчас, как показывает Форд, таких ограничений больше нет.
Что если вам удастся расширить производство чтобы покрыть весь мировой спрос на пальто, при том что в прочих отраслях происходит то же самое.
любопытный документ Green Paper Work 4.0, в частности там довольно подробно
разбирается тема сокращения длительности рабочего дня и частичной занятости. Любопытное чтение.
Согласен с вам, не смотря на то что некоторые главы откровенно устарели,
в целом книга вполне актуальна. Мы продолжаем сталкиваться с теми же проблемами
и совершать те же ошибки.
А вы тоже используете две джиры, одну для разработчиков, другую для заказчиков? ;)
А если серьезно, следующее все же не соответствует действительности.
Книга Брукса это список проблем нежели решений, более того, сам Брукс систематизировал их в список из двух сотен утверждений требующих критики.
Более того, сам Брукс сетует что получил слишком мало критики на свою книгу.
1. Безусловно многие из нас делают ошибки путая достаточно определенные и предсказуемые работы и новые, непредсказуемые, для которые оценки основанные на предыдущем опыте не работают.
2. Тем не менее, часто мы вполне понимаем что ступаем на terra incognita, и в лучшем случае мы можем оценить сроки и бюджет с ошибкой в 6-10 раз.
3. Я ни в коем случае не пытаюсь апеллировать к тому чтобы бизнес «понял» и «простил» разработку, и «предоставил столько времени и ресурсов сколько разработчики захотят» — во первых такое отношение было бы снисходительным, а во вторых — так дела не делаются.
4. Однако, неопределенность сроков сама по себе никуда не денется, вне зависимости от того кто берет на себя ответственность за соблюдение сроков которые невозможно гарантировать.
5. Это проблема, и со стороны бизнеса можно ее игнорировать, а можно пойти навстречу разработке.
раскрыть состоит в том что не имеет значения «тип» проекта, как вы говорите.
Возможность или невозможность осуществить предсказуемое планирование
определяется тем, — выполняются ли для того необходимые условия.
Более того, решение многих задач для профессионалов может быть вполне рутинной,
планируемой работой. Однако, если лично вы не обладаете необходимой экспертизой
и работа, по какой то причине, досталась лично вам — вы попадаете в область непредсказуемого, соответственно и планирование становится невозможным.
Вы утрируете.
но он поможет эти проблемы найти.
Решить проблемы можете только вы.
KPI (Key Performance Indicators) — инструмент для улучшения процесса (производительности).
OKR (Objectives & Key Results) — инструмент для достижения целей (проектов).
(надеюсь так отличие достаточно наглядно.)
Теперь что касается OKR+Scrum vs KPI+Scrum.
В теории KPI+Scrum вполне себе вариант, но с точки зрения управления бизнесом
это более слабый инструмент управления, поскольку он позволяет требовать
только улучшения конкретных метрик.
С другой стороны, OKR+Scrum это более сильный инструмент, поскольку он
позволяет ставить цели уровня бизнеса а не только метрики уровня бизнеса.
Почему OKR хорошо совместимы со с Scrum — очевидно, они не навязывают
способ достижения цели (впрочем как и KPI не навязывают способ улучшения процесса).