Не ждешь от Kaiten такой подставы. Я люблю Kaiten, продукт действительно хороший. А статья про жесткий waterfall, который во многих случаях уже не работает. И самое страшное, что через подмену понятий вкладывается совсем другой смысл в спринты. Ужасно. Это будут читать менеджеры, которые потом будут высчитывать сколько же SP брать в спринт, чтобы закрыть все задачи, взятые в спринт. Пост хоть и рекламный, но с уклоном на знания. Не одобряю!
За статью +, но у меня есть вопрос - на какие активности Вы отводите процесс Discovery? Кажется, статья именно про доставку - Delivery, в котом должны вместе работать несколько человек с разной специализацией (аналитик, разработчик и т.д.)
В те, в который собесы проводит фейковый синьер. А для hr можно придумать список неудобных вопросов. Пусть тоже подумает немного. Я, например, часто спрашивал нужен ли команде вообще руководитель, на должность которого Вы меня собеседуете. Ну или такой - а кто раньше работал на этой должности, почему ушел? Давно уже не был на собесах, поэтому над развитием списка неудобных вопросов давно не работал
Согласен, надоели. Но просто не надо в такие компании устраиваться. Собеседование не только для соискателя, но и для работодателя тоже. Кажется, все об этом забыли
Никто никого не ломает. А если и ломает, то заказчик разработчика. В обратную сторону просто не получится. Одно из преимуществ Канбан - совместная работа всех заинтересованных. Для этого нужно выправить процесс и доска тут только инструмент. Поэтому, доска должна быть простая и локаничная. Желательно, одна на всех. В Вашей доске сложно разбираться тем более пользователю
Я бы сказал, что поднять упавший прод больше шансов у того, кто достаточно долго работал с сервисом или системой, которая упала. Хард скилы тут не на первом месте. Никто специально не делает сложных сервисов и не пишет запутанный код. Но в больших сервисах, которые уже долго разрабатывают, этот шанс почти 100%. Поэтому, нужно ценить тех людей, которые работают сейчас. У них есть бесценный опыт, как-бы банально это ни звучало
Если в процессах хаос, то доска никак не поможет. Максимум, что можно будет понять по тикетам - есть проблема. Но это и так известно. Я не против инструментов, чтобы помогать разработке. Я против таск-трекера в роли волшебной таблетки
Если честно, то нет объяснения почему такой подход должен работать. Мне кажется, что для успешной работы команды, инструменты далеко не первый пункт. Когда-то не было трекеров, а успешные проекты были. Т. е. доска совсем не обязательна, можно и без нее работать и не тратить время на ее внедрение
Интересно, а как ведут себя beamforming и MU-MIMO если роутер находится в углу под потолком? Так часто бывает в квартирах. Алгоритмы не сбиваются от сильной интерференции от стен и потолка?
Кейс интересный, но есть несколько "НО": 1. Наличе доски не говорит о том, что используется Kanban. Как любят говорить некоторые канбанисты - в первых применениях Kanban метода, досок не было вовсе. 2. Сама структура мне показалась очень сложной и перегруженной. Как раз из-за наличия большого количества досок. Смотря на доску, сложно определить что в работе или что с конкретным клиентом. Загрузку сотрудников, как и проблемы по перегрузу тоже определить очень сложно. Без сомнений, случай, где хорошо поможет STATIK. 3. После проведения STATIK, есть вероятность что, статусов и досок станет меньше, процесс станет более прозрачный. Уйдут такие статусы, как Приостановлено, потому что это вовсе не статус выполнения задачи. Скорее всего - это блокеры, которые используются не правильно, теряя контекст самой причины блокера.
Ради справедливости, стоит отметить, что Ваш вариант встречается гораздо чаще, чем тот, о котором пишет автор. И проблема исключительно в ЛПР. Люди боятся неизвестного и неконтролируемого. По пути давления и тотального контроля пойти проще. Но все чаще и чаще руководители выстраивают доверительные отношения с разработкой, занимаются приоритетами, а процесс реализации полностью зависит от разработки
Статья получилась очень позитивная. Иногда даже кажется, что в нашем мире такое невозможно. Но, в любом случае, хороший пример как разработчику сделать шаг в сторону бизнеса и пользователей. Очевидно, что компании, в которых поддерживается такой образ мышления на самом деле, а не на бумаге, окажутся в плюсе
Думаю, что в зрелом процесс обязательно должен присутствовать апстим или дискавери, в котором даются ответы на все "зачем". Только после этого можно сделать какие-то предположения по доставке
Информация
В рейтинге
4 043-й
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Не ждешь от Kaiten такой подставы. Я люблю Kaiten, продукт действительно хороший. А статья про жесткий waterfall, который во многих случаях уже не работает. И самое страшное, что через подмену понятий вкладывается совсем другой смысл в спринты. Ужасно. Это будут читать менеджеры, которые потом будут высчитывать сколько же SP брать в спринт, чтобы закрыть все задачи, взятые в спринт. Пост хоть и рекламный, но с уклоном на знания. Не одобряю!
За статью +, но у меня есть вопрос - на какие активности Вы отводите процесс Discovery? Кажется, статья именно про доставку - Delivery, в котом должны вместе работать несколько человек с разной специализацией (аналитик, разработчик и т.д.)
Маркетинг все поглатил. Сюжет "черного зеркала" все ближе......
Если вы единственный пользователь, тогда и вся статья не имеет смысла
В те, в который собесы проводит фейковый синьер. А для hr можно придумать список неудобных вопросов. Пусть тоже подумает немного. Я, например, часто спрашивал нужен ли команде вообще руководитель, на должность которого Вы меня собеседуете. Ну или такой - а кто раньше работал на этой должности, почему ушел? Давно уже не был на собесах, поэтому над развитием списка неудобных вопросов давно не работал
Согласен, надоели. Но просто не надо в такие компании устраиваться. Собеседование не только для соискателя, но и для работодателя тоже. Кажется, все об этом забыли
Никто никого не ломает. А если и ломает, то заказчик разработчика. В обратную сторону просто не получится. Одно из преимуществ Канбан - совместная работа всех заинтересованных. Для этого нужно выправить процесс и доска тут только инструмент. Поэтому, доска должна быть простая и локаничная. Желательно, одна на всех. В Вашей доске сложно разбираться тем более пользователю
Я бы сказал, что поднять упавший прод больше шансов у того, кто достаточно долго работал с сервисом или системой, которая упала. Хард скилы тут не на первом месте. Никто специально не делает сложных сервисов и не пишет запутанный код. Но в больших сервисах, которые уже долго разрабатывают, этот шанс почти 100%. Поэтому, нужно ценить тех людей, которые работают сейчас. У них есть бесценный опыт, как-бы банально это ни звучало
Если в процессах хаос, то доска никак не поможет. Максимум, что можно будет понять по тикетам - есть проблема. Но это и так известно. Я не против инструментов, чтобы помогать разработке. Я против таск-трекера в роли волшебной таблетки
Если честно, то нет объяснения почему такой подход должен работать. Мне кажется, что для успешной работы команды, инструменты далеко не первый пункт. Когда-то не было трекеров, а успешные проекты были. Т. е. доска совсем не обязательна, можно и без нее работать и не тратить время на ее внедрение
Интересно, а как ведут себя beamforming и MU-MIMO если роутер находится в углу под потолком? Так часто бывает в квартирах. Алгоритмы не сбиваются от сильной интерференции от стен и потолка?
Кейс интересный, но есть несколько "НО":
1. Наличе доски не говорит о том, что используется Kanban. Как любят говорить некоторые канбанисты - в первых применениях Kanban метода, досок не было вовсе.
2. Сама структура мне показалась очень сложной и перегруженной. Как раз из-за наличия большого количества досок. Смотря на доску, сложно определить что в работе или что с конкретным клиентом. Загрузку сотрудников, как и проблемы по перегрузу тоже определить очень сложно. Без сомнений, случай, где хорошо поможет STATIK.
3. После проведения STATIK, есть вероятность что, статусов и досок станет меньше, процесс станет более прозрачный. Уйдут такие статусы, как Приостановлено, потому что это вовсе не статус выполнения задачи. Скорее всего - это блокеры, которые используются не правильно, теряя контекст самой причины блокера.
Ради справедливости, стоит отметить, что Ваш вариант встречается гораздо чаще, чем тот, о котором пишет автор. И проблема исключительно в ЛПР. Люди боятся неизвестного и неконтролируемого. По пути давления и тотального контроля пойти проще. Но все чаще и чаще руководители выстраивают доверительные отношения с разработкой, занимаются приоритетами, а процесс реализации полностью зависит от разработки
Статья получилась очень позитивная. Иногда даже кажется, что в нашем мире такое невозможно. Но, в любом случае, хороший пример как разработчику сделать шаг в сторону бизнеса и пользователей. Очевидно, что компании, в которых поддерживается такой образ мышления на самом деле, а не на бумаге, окажутся в плюсе
Думаю, что в зрелом процесс обязательно должен присутствовать апстим или дискавери, в котором даются ответы на все "зачем". Только после этого можно сделать какие-то предположения по доставке