Привет! На связи Родион Цалкин, продакт IaaS-сервисов в MWS Cloud Platform.
Спасибо за подробный обзор — нам важна обратная связь от сообщества.
Вы правы, что подавляющее большинство сервисов находятся в стадии Preview, и мы сознательно просим относиться к ним именно как к ранней версии продукта. Нам важно получить обратную связь как можно раньше, чтобы лучше понимать потребности реальных пользователей.
Некоторые функции у нас есть уже сейчас — например, назначение внешнего IP, автоматическое шифрование дисков, выбор операционных систем, загрузка больших объектов в объектное хранилище. Если при тестировании они остались незамеченными, это для нас сигнал: будем делать интерфейс и документацию ещё понятнее и удобнее.
При этом мы понимаем ваши ожидания в отношении тех фич платформы, которых действительно не хватает. Команда непрерывно работает над новой функциональностью сервисов, поэтому мы будем рады вашей обратной связи после выхода в general availability.
Если у вас возникнут любые вопросы, у нас есть сообщество в Telegram, где команда оперативно отвечает и помогает. Там же можно следить за анонсами новой функциональности.
Скрам это лекарство от всех болезней, однако оно не помогает, если его неправильно принимать.
Наверное, в совсем наивных компаниях (командах) Scrum - это лекарство от всего, однако сейчас люди все же понимают, что Agile != Scrum, и что методологий множество, начиная с банального Kanaban.
RnD задачи не вписываются в спринты
Важно разделять этап Discovery и Delivery фичи. На этапе Discovery продакт (или другой стейхолодер) изучает и описывает фичу, а разработчик (техлид, CTO) анализирует ее техническую реализуемость. И да, задачи на RnD можно тоже декомпозировать. И даже оценить. Потому что брать в работу задачу даже анализ которой займет месяц не всегда имеет смысл.
Однако ловкие продавцы церемоний усвоили только часть:
процесс важнее всего
В стартапе на 20 человек можно прекрасно жить без единого процесса, однако когда в разработке у тебя 100-150 человек, то процессы придется строить. Как минимум потому что иначе это перестает быть управляемым.
И чем крупнее организация, тем более единообразными хочется делать эти процессы.
Инструменты Kanban, такие как проиретизация задач и WIP limit, дают возможность управлять потоком работы, не прерывая сам рабочий процесс.
А у нас WiP limit измеряется кол-вом задач или все же с поправкой на их размер? Потому что если не опираться на размер задачи, то WiP всегда должен быть =1, иначе большие задачи будут висеть на разработчике очень и очень долго.
А что же скрам, пора отправить его на свалку? Вовсе нет, есть сферы, где он отлично работает. Там, где задачи легки в оценке, а количество неизвестного и нового довольно низко - например, проекты поддержки и сопровождения.
Как раз такие проекты отлично ложатся на Kanban, когда нам нужно выполнять определенным кол-вом людей (=пропускная способность команды) определенный объем задач.
Привет! На связи Родион Цалкин, продакт IaaS-сервисов в MWS Cloud Platform.
Спасибо за подробный обзор — нам важна обратная связь от сообщества.
Вы правы, что подавляющее большинство сервисов находятся в стадии Preview, и мы сознательно просим относиться к ним именно как к ранней версии продукта. Нам важно получить обратную связь как можно раньше, чтобы лучше понимать потребности реальных пользователей.
Некоторые функции у нас есть уже сейчас — например, назначение внешнего IP, автоматическое шифрование дисков, выбор операционных систем, загрузка больших объектов в объектное хранилище. Если при тестировании они остались незамеченными, это для нас сигнал: будем делать интерфейс и документацию ещё понятнее и удобнее.
При этом мы понимаем ваши ожидания в отношении тех фич платформы, которых действительно не хватает. Команда непрерывно работает над новой функциональностью сервисов, поэтому мы будем рады вашей обратной связи после выхода в general availability.
Если у вас возникнут любые вопросы, у нас есть сообщество в Telegram, где команда оперативно отвечает и помогает. Там же можно следить за анонсами новой функциональности.
Наверное, в совсем наивных компаниях (командах) Scrum - это лекарство от всего, однако сейчас люди все же понимают, что Agile != Scrum, и что методологий множество, начиная с банального Kanaban.
Важно разделять этап Discovery и Delivery фичи. На этапе Discovery продакт (или другой стейхолодер) изучает и описывает фичу, а разработчик (техлид, CTO) анализирует ее техническую реализуемость. И да, задачи на RnD можно тоже декомпозировать. И даже оценить. Потому что брать в работу задачу даже анализ которой займет месяц не всегда имеет смысл.
В стартапе на 20 человек можно прекрасно жить без единого процесса, однако когда в разработке у тебя 100-150 человек, то процессы придется строить. Как минимум потому что иначе это перестает быть управляемым.
И чем крупнее организация, тем более единообразными хочется делать эти процессы.
А у нас WiP limit измеряется кол-вом задач или все же с поправкой на их размер? Потому что если не опираться на размер задачи, то WiP всегда должен быть =1, иначе большие задачи будут висеть на разработчике очень и очень долго.
Как раз такие проекты отлично ложатся на Kanban, когда нам нужно выполнять определенным кол-вом людей (=пропускная способность команды) определенный объем задач.