Теперь понял суть претензии, спасибо. Я согласен, что негативная сторона этой медали встречается часто и в разных отраслях. А вот позитивная в ITшке встречается чаще чем где либо. Потому что спецы слишком ценные и текучка сильно вреднее для бизнеса чем среди продавцов в Пятерочке. Ну или мне так кажется просто. Когда я пришел в свою вторую IT компанию для меня стало открытием, что меня на рабочем месте может держать что-то кроме денег и лени искать другое место работы.
С моей стороны будет глупо и нечестно говорить, что статья - исключительно абстрактное теоретизирование. Но это больше прогноз и предостережение, куда можно скатиться. Даже при всем желании делать как лучше.
А что не так с аджайлом? Для меня аджайл про итеративный подход по сравнению с вотерфольными этапами от начала и до конца. Которые потом всё равно заканчиваются итерациями. Только длинными и из-за этого менее эффективными.
А сертификации скрам-мастеров я сильно не люблю, только они к аджайлу относятся примерно как астрология к астрономии.
А за какой срок у вас проходит весь процесс ревью? Не сталкивались с тем, на бумаге каждая стадия ревью должна происходить в рамках одной недели, но систематически занимает около или больше месяца? Если сталкивались то какие выявили причины и как боролись/боретесь?
Во-первых, за плюсик спасибо. А сейчас будет многабукаф про то как я не собираюсь меняться.
Но ведь могут и не быть?
Нет, по моему мнению не могут.
Имеется ввиду, что они должны быть где-то зафиксированы? И структурированы по секундам?
Имеется ввиду, что идей улучшения проекта больше одной у каждого участника проекта и они реализуются гораздо медленнее чем появляются.
Предполагается, что только те идеи, которые будут взяты в работу должны пройти некий путь? А если идея не берется в работу - нам нужно о ней вообще знать и фиксировать ее? А если нет - нужно ли об этом писать?
"Сырая" идея - давайте приделаем к нашему проекту авторизацию через Гугл. Таких идей возникают сотни за цикл.
Приготовленная идея будет содержать описание проблемы, описание решения, потенциальные риски и способы рисков избежать - таких идей будут десятки за цикл
Потом из приготовленных идей выбираются в реализацию наиболее важные, интересные и т.д. - таких идей будут единицы.
И как же, собственно, готовность определяется через "четко сформулированной" проблеме?
Автором, на этапе оформления идеи, или ЛПРами на этапе выбора идей под реализацию. И там и там субъективно, как чуйка подскажет достаточно или недостаточно четко сформулированно.
А если проблемы нет - идея никогда не будет "готова"?
Да. Если нет проблемы, то для чего решение? Вы не в гос. секторе работаете случайно? Необнаруженную боль никто целенаправленно не будет лечить и вылечиться она сможет только как побочный эффект каких-то других действий
Отдельно от чего? И какие места - места чего? Офиса? Проблем? Четкого описания?
Места предлагаемого решения. Отдельно от описания решения.
"сроки могут неконтролируемо съехать" - а бывает контролируемый съезд сроков?
Да. Когда на проекте понимают, что не успевают выпустить заявленный функционал к дедлайну, то начинается поиск углов которые можно срезать и решений которые можно "временно" закостылить. Когда такой маневр помогает успеть к дедлайну это контролируемый съезд сроков. Когда ничего не помогло то съезд был неконтролируемый.
Так у нас же уже есть идея, которая заведомо будет взята в работу?
Никто заранее не может гарантировать что идея будет взята в работу, идея придумывается, прорабатывается и потом её выбирают или не выбирают чтобы взять в реализацию.
Идеи не просто важны, а очень важны? Но не описаны просто важные концепций, в сравнении с которыми эти две прям очень важны.
Тут скорее стоило сказать о том что эти концепции отсутствуют в других воплощениях Agile, с которыми я сталкивался.
Я не осилил статью до конца, поэтому не могу знать - описан ли ниже способ определения готовности и т.д.
Всё намного хуже у меня ещё 2 статьи с описанием отдельных шагов процесса. Но в данном случае, думаю, лучше с оригиналом ознакомиться. ОригиналПеревод на русский
Краткость - сестра таланта.
А мне нравится так писать. Ну и судя по количеству вопросов к первым абзацам я был слишком краток)))
Сколько человек в твоей команде и какого размера проект? Насколько критично чтобы не падал прод из-за "Can't get property X of undefined"? Приходилось ли писать тесты на отлавливание возможных undefined в коде? Приходилось ли на ревью пропускать ошибки такого типа? Приходилось ли лезть разбираться в какой-то кусок логики с мыслью "Что за хрень этот код пытается сделать? А какие аргументы должна принимать эта функция? А точно только с такими её вызывают или кто-то особо одаренный поменял внутреннюю логику, но не прошёлся по местам использования?"
И вот об этих вопросах на 98% можно забыть с TS - этим он оправдывает свою избыточность. Остальные 2% Это случаи возвращения к "заветам предков", т.е. наплевательства на type safety.
Мы задеплоили very-аджайл процесс эдитинга этого артикла, вместе с нашим Хэд-оф-ПиАр и Синьор Бизнес-аналитиком. По всем KPI статья ресивнула оценку "тотал саксесс"
Удачи в написании следующих статей и отслеживании новинок проджект-менеджмента.
Спасибо
Наверное, цель публикаций является просветительской, поэтому хотелось бы видеть пояснения для уровня ниже вашего
Если человек не знает и не сталкивался с таким явлением как бэклог, то даже если ему разъяснить это понятие, опыт работы с ним не появится и сравнение будет впустую. Такое авторское видение у меня пока)
Поправил, вроде понятнее должно было стать. Спасибо, не заметил при вычитке. Бэклог и кулдаун понятны в 2022 году должны быть по моему мнению.
На том турнире БратОК сам говорил, что повезло, что вообще с зергами не пришлось по сетке столкнуться. Но он тогда реально поступью Терминатора прошёлся по тоссам и терранам. Чем произвёл на меня неизгладимое впечатление
Теперь понял суть претензии, спасибо.
Я согласен, что негативная сторона этой медали встречается часто и в разных отраслях. А вот позитивная в ITшке встречается чаще чем где либо. Потому что спецы слишком ценные и текучка сильно вреднее для бизнеса чем среди продавцов в Пятерочке. Ну или мне так кажется просто.
Когда я пришел в свою вторую IT компанию для меня стало открытием, что меня на рабочем месте может держать что-то кроме денег и лени искать другое место работы.
Спасибо за конструктивный ответ!
С моей стороны будет глупо и нечестно говорить, что статья - исключительно абстрактное теоретизирование. Но это больше прогноз и предостережение, куда можно скатиться. Даже при всем желании делать как лучше.
А что не так с аджайлом? Для меня аджайл про итеративный подход по сравнению с вотерфольными этапами от начала и до конца. Которые потом всё равно заканчиваются итерациями. Только длинными и из-за этого менее эффективными.
А сертификации скрам-мастеров я сильно не люблю, только они к аджайлу относятся примерно как астрология к астрономии.
У компании, которой плевать на сотрудников текучка будет выше чем у такой же, которой не плевать. Так или нет?
Не наплевательское отношение в конечном счете стоит бизнесу денег, как и повышенная текучка. Так или нет?
Я считаю, что оба утверждения выше верны и дальше компании оптимизируют соотношение этих двух факторов для максимальной прибыли.
Или я не понял суть претензии?
А за какой срок у вас проходит весь процесс ревью? Не сталкивались с тем, на бумаге каждая стадия ревью должна происходить в рамках одной недели, но систематически занимает около или больше месяца? Если сталкивались то какие выявили причины и как боролись/боретесь?
Во-первых, за плюсик спасибо. А сейчас будет многабукаф про то как я не собираюсь меняться.
Нет, по моему мнению не могут.
Имеется ввиду, что идей улучшения проекта больше одной у каждого участника проекта и они реализуются гораздо медленнее чем появляются.
"Сырая" идея - давайте приделаем к нашему проекту авторизацию через Гугл. Таких идей возникают сотни за цикл.
Приготовленная идея будет содержать описание проблемы, описание решения, потенциальные риски и способы рисков избежать - таких идей будут десятки за цикл
Потом из приготовленных идей выбираются в реализацию наиболее важные, интересные и т.д. - таких идей будут единицы.
Автором, на этапе оформления идеи, или ЛПРами на этапе выбора идей под реализацию. И там и там субъективно, как чуйка подскажет достаточно или недостаточно четко сформулированно.
Да. Если нет проблемы, то для чего решение? Вы не в гос. секторе работаете случайно? Необнаруженную боль никто целенаправленно не будет лечить и вылечиться она сможет только как побочный эффект каких-то других действий
Места предлагаемого решения. Отдельно от описания решения.
Да. Когда на проекте понимают, что не успевают выпустить заявленный функционал к дедлайну, то начинается поиск углов которые можно срезать и решений которые можно "временно" закостылить. Когда такой маневр помогает успеть к дедлайну это контролируемый съезд сроков. Когда ничего не помогло то съезд был неконтролируемый.
Никто заранее не может гарантировать что идея будет взята в работу, идея придумывается, прорабатывается и потом её выбирают или не выбирают чтобы взять в реализацию.
Тут скорее стоило сказать о том что эти концепции отсутствуют в других воплощениях Agile, с которыми я сталкивался.
Всё намного хуже у меня ещё 2 статьи с описанием отдельных шагов процесса. Но в данном случае, думаю, лучше с оригиналом ознакомиться. Оригинал Перевод на русский
А мне нравится так писать. Ну и судя по количеству вопросов к первым абзацам я был слишком краток)))
и этим всё сказано)))
Сколько человек в твоей команде и какого размера проект? Насколько критично чтобы не падал прод из-за "Can't get property X of undefined"? Приходилось ли писать тесты на отлавливание возможных undefined в коде? Приходилось ли на ревью пропускать ошибки такого типа? Приходилось ли лезть разбираться в какой-то кусок логики с мыслью "Что за хрень этот код пытается сделать? А какие аргументы должна принимать эта функция? А точно только с такими её вызывают или кто-то особо одаренный поменял внутреннюю логику, но не прошёлся по местам использования?"
И вот об этих вопросах на 98% можно забыть с TS - этим он оправдывает свою избыточность. Остальные 2% Это случаи возвращения к "заветам предков", т.е. наплевательства на type safety.
Мы задеплоили very-аджайл процесс эдитинга этого артикла, вместе с нашим Хэд-оф-ПиАр и Синьор Бизнес-аналитиком. По всем KPI статья ресивнула оценку "тотал саксесс"
Спасибо
Если человек не знает и не сталкивался с таким явлением как бэклог, то даже если ему разъяснить это понятие, опыт работы с ним не появится и сравнение будет впустую. Такое авторское видение у меня пока)
Поправил, вроде понятнее должно было стать. Спасибо, не заметил при вычитке. Бэклог и кулдаун понятны в 2022 году должны быть по моему мнению.
На том турнире БратОК сам говорил, что повезло, что вообще с зергами не пришлось по сетке столкнуться. Но он тогда реально поступью Терминатора прошёлся по тоссам и терранам. Чем произвёл на меня неизгладимое впечатление