Базовый страх понятен, он у всех есть. Но если так подумать, а что может плохого случиться, если задачи из Jira (или даже текст из Confluence) будет загружен в модель? Модель дообучится на ваших задачах и кто-то через промпт потом косвенно сможет воспользоваться секретными разработками? Маловероятно. Тем более что в моделях уже столько информации, что возможно с нуля можно сгенерить еще более интересные задачи, чем находятся в среднем проекте в Jira :)
p.s Важное замечание, конечно пароли, ключи, пути и тп должны быть приватными - это базовая гигиена. И если есть что-то очень секретное из информации, это можно положить в отдельный приватный проект или папку, к которым у моделей не будет доступа (но это и так все умеют делать на уровне базовых прав доступа к информации для обычных сотрудников).
Спасибо что написали, некорректно выразился. Имел ввиду, что попробуй переучи человека с одного инструмента, к которому он привык, на другой. Пусть даже они очень похожи по сути. Я вот как перешел на Claude месяцев 8 назад, уже не представляю, как бы вернулся в ChatGPT - дело не в интерфейсе чат-бота, а в результатах от нейросети, которые мне нужны. А в масштабе отдела или подразделения, где много людей, перевести всех еще сложнее.
Внутри всех чат-ботов есть микрофон, можно надиктовывать, так еще быстрее получится, да. И больше контекста можно наговорить, например, для более корректного создания задач (писать же лень большую портянку).
Здесь согласен, всё очень сильно зависит от контекста. Мы тоже проводим этот тренинг в нашем учебном центре, и обычно вначале всегда у участников бывает сопротивление — это нормально. Эти принципы не внедряются за раз, это происходит постепенно. Почему и говорят "Agile-трансформация компании", потому что меняются не только процессы, но и культура. Сначала в одной команде на пилотном проекте, потом постепенно-постепенно можно оценивать результат и двигаться дальше. Сразу "стать Agile" на уровне всей компании просто нереально.
Вам очень повезло, что вы смогли послушать столько разных мнений. Это, безусловно, одно из преимуществ работы в командах на тренинге. В обсуждении всегда рождается что-то ценное. Со временем участники, как правило, начинают видеть пользу и запускают процесс изменения в своих компаниях.
В госзаказе конечно своя специфика, хотя инода такое бывает и в коммерческой разработке. Тут больше от личности человека зависит, и никакая методика не спасет.
Несмотря на то, что ваша статья выглядит полностью написанной chatGPT, прокомментирую :)
Мир не бывает однобоким, и поэтому Канбан не лучше Скрама, как и наоборот. Это просто два подхода, и вы можете пользоваться любым из них, не пользоваться никаким, или попробовать СкрамБан (хотя это конечно сомнительная практика).
Во многих случаях канбан-метод хорош (вот примеры), но скрам в разработке хорошо помогает научиться поставлять осязаемый результат в короткий промежуток времени.
В общем каждый выбирает себе инструменты под рабочий контекст.
Как показывает практика, в командах всегда есть чуть более ответственные и мотивированные люди и чуть менее. Так вот на первых все и держится. А вторых обычно становится хорошо видно и дальше по ситуации :)
Я бы здесь поспорил немного. Софт с высокой критичностью заставляет нас особенно внимательно подходить к вопросам его качества в плане багов и незадокументированного поведения - это факт. Но давайте возьмем для примеру автопилот на машине. Критично? Очень. Отлит ли код в граните - вряд ли, иначе бы автопилоты не развивались семимильными шагами. А вот процедуры QA такого кода точно супер-формальные и многоступенчатые, иначе никак.
Наверное в любой хорошей идее бывают нюансы при ее реализации :)
Я тоже часто для себя называю agile здравым смыслом. Так проще находить в процессах разработки вещи, которые мы делаем просто потому что так принято, а не потому, что нам кажется это правильным. Поэтому и аппелируем к здравому смыслу.
Самый простой тест - бывает у вас на работе что-то, что вы делаете, но что вам кажется странным? А иногда вообще дичью? :)
Дедлайны ставить очень легко, просто нужно это делать чуть по-другому. Например, договорились что делаем релиз учетной системы 1 мая, значит каждый спринт задаем все вместе (мы и заказчики) себе вопрос: "Мы успеваем 1 мая? Что из важного еще не сделали? На чем правильнее всего в ближайшую неделю сфокусироваться?". И тогда размеры шрифтов автоматически выпадут из рассмотрения, так как есть очевидно более важные вещи.
Все так - весь вопрос в неопределенности. И если добавить сюда еще "мягкость" software, то есть возможность менять что угодно в коде условно достаточно дешево, то мы и получаем ситуацию, когда в любых проектах по разработке ПО разумно применять именно agile подход.
Да, отличное замечание! Недавно я работал с компанией, вот там изменения процессов остановилось на моменте, когда культура начала реально изменяться от авторитарной (все решения принимает директор) к культуре сотрудничества (каждый на своем уровне начинает задавать вопросы - а правильно ли мы делаем, а может лучше сделать вот так?). Директор начал понимать, что теряет привычные ему рычаги управления и просто решил для себя, что это ему не подходит, лучше оставить как было.
Да, вы правы - это специфика крупной огранизации, ее практически невозможно целиком дотащить до уровня крутой продуктовой компании. Главная причина - много руководителей (так как компания огромная), и у каждого свой опыт и свое видение как правильно.
Но как человек, который начинал Agile-движ в МТС в 2015 году, могу вас заверить - тот МТС что есть сейчас и тот, который был 10 лет назад - это просто небо и земля. В разработке было прямо совсем плохо, ровно как и в Сбере того времени.
«уже к финальному релизу предъявлял ту самую кучу новых требований» — у нас была несколько похожая ситуация, как раз в конце статьи я об этом упомянул. Только заказчик не предъявил кучу новых требований, а немного посетовал, что сделали не все, что было у него в голове. В принципе, если это возражение быстро и качественно с аргументами обработать, то получается ок и дальше запускается следующий этап проекта (релиз), уже в рамках нового бюджета.
По поводу сырости и недоработок, на моем опыте такое впечатление заказчика о промежуточных результатах сильно зависит от того, что мы ему показываем. Если показываем сырое, падающее, непонятно как сверстанное — тогда понятно, он будет недоволен. А если показывать небольшими инкрементами функциональности, но зато условно production качества — это уже другой разговор.
Как я уже писал в комментарии выше, мы вместе с заказчиком делаем нужный ему продукт, с максимально возможным набором функций, в рамках бюджета проекта.
Если вы имеете ввиду полностью закрыть ответственность исполнителя договором — ну тут вариант только один, все четко прописать и получить контракт с зафиксированными бюджетом, сроком и скоупом.
Тогда заказчик точно получит то, что просил на старте проекта. Но не то, что ему по факту нужно. И обе стороны будут иметь те же проблемы, от которых хотели уйти :)
В таком случае мы, наверное, будем не очень хорошими исполнителями. Если клиент хотел CRM, то он должен получить CRM.
Весь вопрос в объеме реализованной функциональности, которая постоянно обсуждается нами и заказчиком в течение проекта, но свои основные функции как CRM система должна выполнять.
Иначе да, как в бодишопах, когда у исполнителей нет никакой ответственности за итоговый продукт — продается просто человек, а там будь что будет.
Всегда удивляюсь, почему в описании use cases используют неблагозвучное для русского языка слово Актор.
Ведь аналитика пишется для простых заказчиков и разработчиков, которым гораздо более понятны фразы «Зритель называет номер брони» и «Зритель передает оператору плату за билет», а не «Актор называет номер брони».
Теперь создание проекта (настоящего или тестового) доступно на сервисе Облако проектов (http://projectscloud.ru) — это бесплатный проектный хостинг, в основе которого лежит система управления проектами DEVPROM
В теории да, но у них написано в доке, что пока доступ к их mcp есть только у Claude.
Базовый страх понятен, он у всех есть.
Но если так подумать, а что может плохого случиться, если задачи из Jira (или даже текст из Confluence) будет загружен в модель? Модель дообучится на ваших задачах и кто-то через промпт потом косвенно сможет воспользоваться секретными разработками? Маловероятно. Тем более что в моделях уже столько информации, что возможно с нуля можно сгенерить еще более интересные задачи, чем находятся в среднем проекте в Jira :)
p.s Важное замечание, конечно пароли, ключи, пути и тп должны быть приватными - это базовая гигиена. И если есть что-то очень секретное из информации, это можно положить в отдельный приватный проект или папку, к которым у моделей не будет доступа (но это и так все умеют делать на уровне базовых прав доступа к информации для обычных сотрудников).
Спасибо что написали, некорректно выразился. Имел ввиду, что попробуй переучи человека с одного инструмента, к которому он привык, на другой. Пусть даже они очень похожи по сути.
Я вот как перешел на Claude месяцев 8 назад, уже не представляю, как бы вернулся в ChatGPT - дело не в интерфейсе чат-бота, а в результатах от нейросети, которые мне нужны.
А в масштабе отдела или подразделения, где много людей, перевести всех еще сложнее.
Внутри всех чат-ботов есть микрофон, можно надиктовывать, так еще быстрее получится, да. И больше контекста можно наговорить, например, для более корректного создания задач (писать же лень большую портянку).
Здесь согласен, всё очень сильно зависит от контекста. Мы тоже проводим этот тренинг в нашем учебном центре, и обычно вначале всегда у участников бывает сопротивление — это нормально. Эти принципы не внедряются за раз, это происходит постепенно. Почему и говорят "Agile-трансформация компании", потому что меняются не только процессы, но и культура. Сначала в одной команде на пилотном проекте, потом постепенно-постепенно можно оценивать результат и двигаться дальше. Сразу "стать Agile" на уровне всей компании просто нереально.
Вам очень повезло, что вы смогли послушать столько разных мнений. Это, безусловно, одно из преимуществ работы в командах на тренинге. В обсуждении всегда рождается что-то ценное. Со временем участники, как правило, начинают видеть пользу и запускают процесс изменения в своих компаниях.
В госзаказе конечно своя специфика, хотя инода такое бывает и в коммерческой разработке. Тут больше от личности человека зависит, и никакая методика не спасет.
Несмотря на то, что ваша статья выглядит полностью написанной chatGPT, прокомментирую :)
Мир не бывает однобоким, и поэтому Канбан не лучше Скрама, как и наоборот. Это просто два подхода, и вы можете пользоваться любым из них, не пользоваться никаким, или попробовать СкрамБан (хотя это конечно сомнительная практика).
Во многих случаях канбан-метод хорош (вот примеры), но скрам в разработке хорошо помогает научиться поставлять осязаемый результат в короткий промежуток времени.
В общем каждый выбирает себе инструменты под рабочий контекст.
Как показывает практика, в командах всегда есть чуть более ответственные и мотивированные люди и чуть менее. Так вот на первых все и держится. А вторых обычно становится хорошо видно и дальше по ситуации :)
Я бы здесь поспорил немного.
Софт с высокой критичностью заставляет нас особенно внимательно подходить к вопросам его качества в плане багов и незадокументированного поведения - это факт.
Но давайте возьмем для примеру автопилот на машине. Критично? Очень. Отлит ли код в граните - вряд ли, иначе бы автопилоты не развивались семимильными шагами.
А вот процедуры QA такого кода точно супер-формальные и многоступенчатые, иначе никак.
Золотые слова!
Наверное в любой хорошей идее бывают нюансы при ее реализации :)
Я тоже часто для себя называю agile здравым смыслом. Так проще находить в процессах разработки вещи, которые мы делаем просто потому что так принято, а не потому, что нам кажется это правильным. Поэтому и аппелируем к здравому смыслу.
Самый простой тест - бывает у вас на работе что-то, что вы делаете, но что вам кажется странным? А иногда вообще дичью? :)
Дедлайны ставить очень легко, просто нужно это делать чуть по-другому.
Например, договорились что делаем релиз учетной системы 1 мая, значит каждый спринт задаем все вместе (мы и заказчики) себе вопрос: "Мы успеваем 1 мая? Что из важного еще не сделали? На чем правильнее всего в ближайшую неделю сфокусироваться?".
И тогда размеры шрифтов автоматически выпадут из рассмотрения, так как есть очевидно более важные вещи.
Все так - весь вопрос в неопределенности. И если добавить сюда еще "мягкость" software, то есть возможность менять что угодно в коде условно достаточно дешево, то мы и получаем ситуацию, когда в любых проектах по разработке ПО разумно применять именно agile подход.
Да, отличное замечание! Недавно я работал с компанией, вот там изменения процессов остановилось на моменте, когда культура начала реально изменяться от авторитарной (все решения принимает директор) к культуре сотрудничества (каждый на своем уровне начинает задавать вопросы - а правильно ли мы делаем, а может лучше сделать вот так?).
Директор начал понимать, что теряет привычные ему рычаги управления и просто решил для себя, что это ему не подходит, лучше оставить как было.
Да, вы правы - это специфика крупной огранизации, ее практически невозможно целиком дотащить до уровня крутой продуктовой компании. Главная причина - много руководителей (так как компания огромная), и у каждого свой опыт и свое видение как правильно.
Но как человек, который начинал Agile-движ в МТС в 2015 году, могу вас заверить - тот МТС что есть сейчас и тот, который был 10 лет назад - это просто небо и земля. В разработке было прямо совсем плохо, ровно как и в Сбере того времени.
По поводу сырости и недоработок, на моем опыте такое впечатление заказчика о промежуточных результатах сильно зависит от того, что мы ему показываем. Если показываем сырое, падающее, непонятно как сверстанное — тогда понятно, он будет недоволен. А если показывать небольшими инкрементами функциональности, но зато условно production качества — это уже другой разговор.
Если вы имеете ввиду полностью закрыть ответственность исполнителя договором — ну тут вариант только один, все четко прописать и получить контракт с зафиксированными бюджетом, сроком и скоупом.
Тогда заказчик точно получит то, что просил на старте проекта. Но не то, что ему по факту нужно. И обе стороны будут иметь те же проблемы, от которых хотели уйти :)
Весь вопрос в объеме реализованной функциональности, которая постоянно обсуждается нами и заказчиком в течение проекта, но свои основные функции как CRM система должна выполнять.
Иначе да, как в бодишопах, когда у исполнителей нет никакой ответственности за итоговый продукт — продается просто человек, а там будь что будет.
Ведь аналитика пишется для простых заказчиков и разработчиков, которым гораздо более понятны фразы «Зритель называет номер брони» и «Зритель передает оператору плату за билет», а не «Актор называет номер брони».