взял открытый проект, доработал его для моего клиента и передал ему с соблюдением лицензии открытого проекта, то о каких нарушениях может идти речь. Являюсь ли я при этом разработчиком открытого ПО?
По моему мнению, открытое ПО должно быть доступным для всех. Если взяли открытое ПО, доработали, но при этом не сделали его доступных для всех, то это использование открытого ПО для разработки закрытого ПО.
Оценка 360 градусов — это комплексный метод оценки, при котором собирается обратная связь о сотруднике со всех сторон: от руководителей, коллег, подчиненных и даже внешних партнеров
И в следующем разделе
Оценка 540 градусов включает в себя обратную связь от всех сторон, как и оценка 360 градусов, но добавляет к этому внешнюю оценку от клиентов, партнеров или других внешних стейкхолдеров
Очередная статья написанная с помощью нейронки? Потому что ChatGPT мне примерно такое же описание сгенерировал, даже примеры похожи.
Спасибо за статью, не знал об этом фреймворке. Но не совсем понимаю, в чём преимущество такого подхода вместо обычного jdbc + SQL. Из того что я вижу, просто код из Java перекочевал в XML. Да, мапперы иногда можно не писать и ещё пару нюансов, но глобально преимуществ мало с первого взгляда.
Это задача, которую надо оценить. Страдают ли от этого конечные пользователи? Как себя чувствует вызываемый сервис под нагрузкой? Плохо ли разработчикам? Ну и делать в зависимости от ответов.
Не могу не согласиться с комментарием. Но уж очень заманчива для меня идея с единым бэклогом. И да, оценивать такие задачи очень сложно в деньгах, ощущение даже, что на оценку будет уходить больше времени, чем на разработку.
Соглашусь, важно достигать компромисса между технической частью и бизнес-ценностью.
По поводу несознательного техдолга, то ситуации бывают разные, дело необязательно в компетенциях. И не стоит забывать о естественном техдолге: проходит несколько лет, и вот нам уже надо обновлять Java 17 до 21.
Немного поясню. Я попытался разобраться в том, что такое техдолг, но в сообществе много разных мнений. Поэтому я решил исходить из своей практики и посмотреть, что же люди относят к техдолгу по тем или иным соображениям.
Заголовок подразумевает, что не нужно выделять техдолг как отдельный класс задач, а стоит доносить их ценность до бизнеса и делать в соответствии с приоритетами.
Никто не говорит, что техдолг не появляется сам собой. Из моих типов сюда относятся и рефакторинг, и обновить версию чего-то, и переезд на новую технологию.
Пункт про "не создавать техдолг" был про сознательное создание техдолга. Например: тесты написать не успели, напишем когда-нибудь потом. Но да, это не отменяет "естественного" техдолга.
Поэтому техдолг есть и будет всегда, но его нужно не бояться, а уметь с ним работать.
Я пытался донести, что с техдолгом надо работать как и с любой другой задачей, у которой есть определённая бизнес-ценность. Возможно где-то недосказал или возникло недопонимание.
Тех долг возникает, потому что у нас уже сделан продукт, покрыт тестами и т.п. и тут бизнес решает, что что-то нужно сделать по другому, что прямо не вписывается в архитектуру.
Но ведь это только один из видов техдолга. Данная история по классификации из статьи может быть отнесена к рефакторингу.
А потом в какой-то момент люди уже не могут пилить новые сложные фичи, потому что у них сломается костыль, на который завязано еще 10 костылей.
Именно поэтому я говорю, что бизнесу необходимо доносить, почему необходимо делать ту или иную задачу, даже если изначально кажется, что на бизнес какой-то там рефакторинг совершенно не влияет. Здесь очевидно, что чем дольше мы не рефакторим, тем больше становится наше время поставки (в крайнем случае упираемся в бесконечность - невозможность поставки новых фич без рефакторинга)
Но погодите, ведь hr тоже нет в скраме. Там есть ПО, разработчик и скрам-мастер.
Мне кажется, что ситуация, когда все равны, возможна в условной команде где все "синьоры" с примерно одинаковым опытом работы. Тогда у них примерно одинаковые навыки, знания о продукте и никто им не нужен.
Но в реальном мире существуют джуны, мидлы, новички. Им нужен онбординг, нужен более тщательный присмотр в каких-то аспектах, нужно как-то строить их план развития. Да даже синьорам нужно развитие и его должен кто-то направлять.
И как не назови человека, который будет этим заниматься, его уже нет в скраме.
При упоминании KPI, мне всегда вспоминается закон черных метрик из Дорофеева - для любого KPI, существует такая стратегия B, что KPI находится в зелёной зоне, а проект летит через ж* в неизвестность.
Картинка
Безаварийность
У разработчика появляется страх совершать ошибки, и он будет делать только самый безопасный минимум.
Попадание в оценку
Всегда завышаем оценку. Если успеваем раньше, специально затягиваем разработку.
Оформление задачи
Бюрократия как она есть. Можно сделать примерно ничего, зато красиво всё описать.
ИМХО, самым важным показателем, является обратная связь от тех, с кем человек работает. Вышеперечисленные показатели важны и на них стоит смотреть, но сами по себе они ничего не показывают.
Не претендую на истинность в последней инстанции, говорю с позиции разработчика.
Возможно я не дипломированный специалист по Agile и процессам, но всё это напоминает какой-то обычный scrum/less. Если это очередная модификация, то я не понимаю отличий.
PI-планирование — это регулярная встреча всех команд проекта и его стейкхолдеров.
Тут важно сказать, что PI-планирование идет от бэклога. То есть на этой встрече мы не пополняем нашу доску задачами. Всё это — предварительная работа.
Прямо как на планировании из скрама
Срочные задачи идут в ближайший, а менее горящие мы сделаем позже. Но важно, что сделаем именно в этом PI-периоде. У нас это полтора месяца.
Я не могу без гугла или без IDE. В питоне вот можно просто print(dict), в Java, уже сложнее, надо в цикле пробежаться по мапе. Сигнатуру for я знаю. Какой метод у Map? getEntries()? entries()? И вот я открыл IDE, оказалось, что метод называется entrySet(). Должен ли я это знать наизусть?
Кому станет легче жить, если я начну учить наизусть у какого класса какие методы? Люди специально придумали поисковики, подсказки в IDE, чтобы не держать эти знания в своей голове. Если мне приходит задача одного и того же типа раз в год, мне лучше знать как найти информацию о том, как её сделать, чем целый год держать бесполезные знания об этом у себя в голове.
И то что я некоторые нюансы языков или алгоритмы не знаю наизусть, не означает, что я не могу закрывать потребности бизнеса в срок.
Я написал себе довольно специфичного телеграм-бота - справочник биологических добавок. Кидаешь в бота список добавок, а он говорит, описание, какие побочки, что безопасно.
Застрял в итоге на сборе данных, потому что хотелось краткую выжимку по каждому элементу а не целиком страницы из инета. Наверное теперь это можно автоматизировать через chatgpt какой-нибудь, но руки не доходят, да и имеющейся базы хватает в целом.
Имею на телефоне целую горсть магазинов приложений, в том числе и rustore. С задачей "установить - обновить" он справляется. Пользоваться или нет - уже каждый сам для себя решит.
В Java ошибки обрабатываются с помощью исключений. В Rust исключений нет. Вместо них используется тип Result<T, E>
На самом деле в Java никто не запрещает вместо исключений использовать return-based подход к ошибкам. Например, с помощью Either из vavr.io, или можно самим написать класс-обёртку для возвращаемых значений.
Ситуация, конечно, плохая. Но в мире опенсурса решаемая - можно сделать форк. Это геморно и неприятно, однако возможно, в отличии от проприетарного ПО.
По моему мнению, открытое ПО должно быть доступным для всех. Если взяли открытое ПО, доработали, но при этом не сделали его доступных для всех, то это использование открытого ПО для разработки закрытого ПО.
И в следующем разделе
Очередная статья написанная с помощью нейронки? Потому что ChatGPT мне примерно такое же описание сгенерировал, даже примеры похожи.
Спасибо за статью, не знал об этом фреймворке. Но не совсем понимаю, в чём преимущество такого подхода вместо обычного jdbc + SQL. Из того что я вижу, просто код из Java перекочевал в XML. Да, мапперы иногда можно не писать и ещё пару нюансов, но глобально преимуществ мало с первого взгляда.
Значит сейчас её скорее всего делать смысла нет. Но главное - периодически приоритезировать, на случай если ответы поменяются.
Это задача, которую надо оценить. Страдают ли от этого конечные пользователи? Как себя чувствует вызываемый сервис под нагрузкой? Плохо ли разработчикам? Ну и делать в зависимости от ответов.
Не могу не согласиться с комментарием. Но уж очень заманчива для меня идея с единым бэклогом. И да, оценивать такие задачи очень сложно в деньгах, ощущение даже, что на оценку будет уходить больше времени, чем на разработку.
Соглашусь, важно достигать компромисса между технической частью и бизнес-ценностью.
По поводу несознательного техдолга, то ситуации бывают разные, дело необязательно в компетенциях. И не стоит забывать о естественном техдолге: проходит несколько лет, и вот нам уже надо обновлять Java 17 до 21.
Немного поясню. Я попытался разобраться в том, что такое техдолг, но в сообществе много разных мнений. Поэтому я решил исходить из своей практики и посмотреть, что же люди относят к техдолгу по тем или иным соображениям.
Заголовок подразумевает, что не нужно выделять техдолг как отдельный класс задач, а стоит доносить их ценность до бизнеса и делать в соответствии с приоритетами.
Никто не говорит, что техдолг не появляется сам собой. Из моих типов сюда относятся и рефакторинг, и обновить версию чего-то, и переезд на новую технологию.
Пункт про "не создавать техдолг" был про сознательное создание техдолга. Например: тесты написать не успели, напишем когда-нибудь потом. Но да, это не отменяет "естественного" техдолга.
Я пытался донести, что с техдолгом надо работать как и с любой другой задачей, у которой есть определённая бизнес-ценность. Возможно где-то недосказал или возникло недопонимание.
Но ведь это только один из видов техдолга. Данная история по классификации из статьи может быть отнесена к рефакторингу.
Именно поэтому я говорю, что бизнесу необходимо доносить, почему необходимо делать ту или иную задачу, даже если изначально кажется, что на бизнес какой-то там рефакторинг совершенно не влияет. Здесь очевидно, что чем дольше мы не рефакторим, тем больше становится наше время поставки (в крайнем случае упираемся в бесконечность - невозможность поставки новых фич без рефакторинга)
Я понимаю, что это перевод. Но ощущение, что текст был сгенерирован нейронкой, а человек к нему даже не прикасался.
Максимально общие фразы и никакого практического смысла.
Но погодите, ведь hr тоже нет в скраме. Там есть ПО, разработчик и скрам-мастер.
Мне кажется, что ситуация, когда все равны, возможна в условной команде где все "синьоры" с примерно одинаковым опытом работы. Тогда у них примерно одинаковые навыки, знания о продукте и никто им не нужен.
Но в реальном мире существуют джуны, мидлы, новички. Им нужен онбординг, нужен более тщательный присмотр в каких-то аспектах, нужно как-то строить их план развития. Да даже синьорам нужно развитие и его должен кто-то направлять.
И как не назови человека, который будет этим заниматься, его уже нет в скраме.
При упоминании KPI, мне всегда вспоминается закон черных метрик из Дорофеева - для любого KPI, существует такая стратегия B, что KPI находится в зелёной зоне, а проект летит через ж* в неизвестность.
Картинка
У разработчика появляется страх совершать ошибки, и он будет делать только самый безопасный минимум.
Всегда завышаем оценку. Если успеваем раньше, специально затягиваем разработку.
Бюрократия как она есть. Можно сделать примерно ничего, зато красиво всё описать.
ИМХО, самым важным показателем, является обратная связь от тех, с кем человек работает. Вышеперечисленные показатели важны и на них стоит смотреть, но сами по себе они ничего не показывают.
Не претендую на истинность в последней инстанции, говорю с позиции разработчика.
Возможно я не дипломированный специалист по Agile и процессам, но всё это напоминает какой-то обычный scrum/less. Если это очередная модификация, то я не понимаю отличий.
Прямо как на планировании из скрама
Звучит как спринт (просто длинный)
Я не могу без гугла или без IDE. В питоне вот можно просто print(dict), в Java, уже сложнее, надо в цикле пробежаться по мапе. Сигнатуру for я знаю. Какой метод у Map? getEntries()? entries()? И вот я открыл IDE, оказалось, что метод называется entrySet(). Должен ли я это знать наизусть?
Кому станет легче жить, если я начну учить наизусть у какого класса какие методы? Люди специально придумали поисковики, подсказки в IDE, чтобы не держать эти знания в своей голове. Если мне приходит задача одного и того же типа раз в год, мне лучше знать как найти информацию о том, как её сделать, чем целый год держать бесполезные знания об этом у себя в голове.
И то что я некоторые нюансы языков или алгоритмы не знаю наизусть, не означает, что я не могу закрывать потребности бизнеса в срок.
Я написал себе довольно специфичного телеграм-бота - справочник биологических добавок. Кидаешь в бота список добавок, а он говорит, описание, какие побочки, что безопасно.
Застрял в итоге на сборе данных, потому что хотелось краткую выжимку по каждому элементу а не целиком страницы из инета. Наверное теперь это можно автоматизировать через chatgpt какой-нибудь, но руки не доходят, да и имеющейся базы хватает в целом.
Имею на телефоне целую горсть магазинов приложений, в том числе и rustore. С задачей "установить - обновить" он справляется. Пользоваться или нет - уже каждый сам для себя решит.
На самом деле в Java никто не запрещает вместо исключений использовать return-based подход к ошибкам. Например, с помощью Either из vavr.io, или можно самим написать класс-обёртку для возвращаемых значений.
И я считаю, что это прекрасно.
Ситуация, конечно, плохая. Но в мире опенсурса решаемая - можно сделать форк. Это геморно и неприятно, однако возможно, в отличии от проприетарного ПО.