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