DP
Игра GetKanban была классной! Спасибо организаторам за организацию, участникам за участие! :)
Size: a a a
2018 November 24
DP
После смог передизайнить доску с задачами, чтобы поток работы двигался в одну сторону. Несколько месяцев этот факт сидел в голове, как заноза, а решение-то на поверхности оказалось. :)
NM
Организаторам еще раз, большое спасибо за игру. Остальным ребята - спасибо за компанию 😀
A
Привет! Я Александр, PM в adru #welcome
s
Привет, я Иван, также ПМ в adru #welcome
MS
Привет! Я Максим, iOS разработчик #welcome
2018 November 26
SF
На моей работе зацепило людей. Потому что методологии использует менеджмент для менеджмента.
SF
Использовал... Отжать из команды максимум за короткие сроки и показать директорам картинку.
CM
Scrum - не Agile. Если буквально понимать его формулировки, то он манифесту противоречит. )))
AM
10 лет в разработке и не одного вменяемого конкретного примера в статье. Я бегло прочитал, может глаз за что-то не зацепился.
Но! Где пруфы!?
Но! Где пруфы!?
AM
Перемешаны стадии формирования команды, стадии проекта (продукта) и взаимодействие между разработчиками разного уровня.
AM
Сергей, о чем хотел подискутировать? В смысле, какую-то конкретную часть статьи или ее целиком? Или как к этому относится? Или кто-то из коллег прочитал, и говорит: "ВОТ! Видишь! Не работает, только хуже будет" :)
CM
Думал будет аргументированная критика Scrum/Agile, но ее в статье нет. От слова совсем.
Просто:
1) Нужно разделять разработку проектов от разработки продуктов. Scrum — это методология для продукта, которая не подходит для проекта.
2) На самом деле, у «бизнес-пользователей», там наверху, свой Agile. Причем в очень жестком варианте. И действительно бывает, что некоторые вещи им нужны срочно и внезапно. Не потому, что они «глупые», а потому, что ситуация изменилась.
3) Как показывает мне мой опыт, результаты работы креативных инженеров с их R&D оставляет желать лучшего. И потом их старшим товарищам приходится разгребать за ними.
4) Лично я не представляю, как можно быть хорошим инженером и не понимать что и для чего ты делаешь. Т. е. хороший инженер понимает бизнес-цель своего бизнес-заказчика. Иначе просто никак.
У Scrum действительно есть значительные недостатки, он действительно применим в достаточно неширокой нише.
Но честно говоря, если человек непризнанный гений, то любая методология, которая будет мешать бестолку тратить деньги работодателя, будет для него плохой. На каких бы принципах она не была построена.
Просто:
1) Нужно разделять разработку проектов от разработки продуктов. Scrum — это методология для продукта, которая не подходит для проекта.
2) На самом деле, у «бизнес-пользователей», там наверху, свой Agile. Причем в очень жестком варианте. И действительно бывает, что некоторые вещи им нужны срочно и внезапно. Не потому, что они «глупые», а потому, что ситуация изменилась.
3) Как показывает мне мой опыт, результаты работы креативных инженеров с их R&D оставляет желать лучшего. И потом их старшим товарищам приходится разгребать за ними.
4) Лично я не представляю, как можно быть хорошим инженером и не понимать что и для чего ты делаешь. Т. е. хороший инженер понимает бизнес-цель своего бизнес-заказчика. Иначе просто никак.
У Scrum действительно есть значительные недостатки, он действительно применим в достаточно неширокой нише.
Но честно говоря, если человек непризнанный гений, то любая методология, которая будет мешать бестолку тратить деньги работодателя, будет для него плохой. На каких бы принципах она не была построена.
SF
Сергей, о чем хотел подискутировать? В смысле, какую-то конкретную часть статьи или ее целиком? Или как к этому относится? Или кто-то из коллег прочитал, и говорит: "ВОТ! Видишь! Не работает, только хуже будет" :)
Что-то вроде "вот, посмотрите, что пишут люди - Скрам - плохо".
SF
В статье много передергиваний и лёгкого НЛП.
Да, нет пруфов, вообще.
НО! Ведь есть же такие компании! Когда Скрам внедряют именно на уровне управленческого аппарата под предлогом ускорения разработки. Хищнический подход в бизнесе - такой же подход к разработчиком. Когда они не партнёры, а тупо исполнители.
Такие были всегда. И если это сложить с гибкими методологиями, особенно с Agile, то разработчиков и впрямь модно доить не по детски...
Да, нет пруфов, вообще.
НО! Ведь есть же такие компании! Когда Скрам внедряют именно на уровне управленческого аппарата под предлогом ускорения разработки. Хищнический подход в бизнесе - такой же подход к разработчиком. Когда они не партнёры, а тупо исполнители.
Такие были всегда. И если это сложить с гибкими методологиями, особенно с Agile, то разработчиков и впрямь модно доить не по детски...
SF
Думал будет аргументированная критика Scrum/Agile, но ее в статье нет. От слова совсем.
Просто:
1) Нужно разделять разработку проектов от разработки продуктов. Scrum — это методология для продукта, которая не подходит для проекта.
2) На самом деле, у «бизнес-пользователей», там наверху, свой Agile. Причем в очень жестком варианте. И действительно бывает, что некоторые вещи им нужны срочно и внезапно. Не потому, что они «глупые», а потому, что ситуация изменилась.
3) Как показывает мне мой опыт, результаты работы креативных инженеров с их R&D оставляет желать лучшего. И потом их старшим товарищам приходится разгребать за ними.
4) Лично я не представляю, как можно быть хорошим инженером и не понимать что и для чего ты делаешь. Т. е. хороший инженер понимает бизнес-цель своего бизнес-заказчика. Иначе просто никак.
У Scrum действительно есть значительные недостатки, он действительно применим в достаточно неширокой нише.
Но честно говоря, если человек непризнанный гений, то любая методология, которая будет мешать бестолку тратить деньги работодателя, будет для него плохой. На каких бы принципах она не была построена.
Просто:
1) Нужно разделять разработку проектов от разработки продуктов. Scrum — это методология для продукта, которая не подходит для проекта.
2) На самом деле, у «бизнес-пользователей», там наверху, свой Agile. Причем в очень жестком варианте. И действительно бывает, что некоторые вещи им нужны срочно и внезапно. Не потому, что они «глупые», а потому, что ситуация изменилась.
3) Как показывает мне мой опыт, результаты работы креативных инженеров с их R&D оставляет желать лучшего. И потом их старшим товарищам приходится разгребать за ними.
4) Лично я не представляю, как можно быть хорошим инженером и не понимать что и для чего ты делаешь. Т. е. хороший инженер понимает бизнес-цель своего бизнес-заказчика. Иначе просто никак.
У Scrum действительно есть значительные недостатки, он действительно применим в достаточно неширокой нише.
Но честно говоря, если человек непризнанный гений, то любая методология, которая будет мешать бестолку тратить деньги работодателя, будет для него плохой. На каких бы принципах она не была построена.
Плюсую. В этом же ключе описал в чате компании.
Инструмент можно использовать по разному.
Инструмент можно использовать по разному.
AM
Эм, так это же вообще мимо agile
Люди и взаимодействие важнее процессов и инструментов
Люди и взаимодействие важнее процессов и инструментов
AM
На мой, сразу скажу делетанский взгляд, чтобы внедрять новую методологию нужно:
* понимать, как сейчас работает команда
* понимать, какой она сейчас приносит результат (желательно в метриках)
* понимать, что не нравится в результате?
* проанализировать, из-за чего получается хороший результат, из-за чего плохой.
* понимать уровень членов команды.
* и понимать уровень организации команды.
* понимать, как сейчас работает команда
* понимать, какой она сейчас приносит результат (желательно в метриках)
* понимать, что не нравится в результате?
* проанализировать, из-за чего получается хороший результат, из-за чего плохой.
* понимать уровень членов команды.
* и понимать уровень организации команды.
AM
Нельзя же просто прийти и сказать, все мы работаем по scrum, по kanban ...