Там не написано, что нельзя создать нового пользователя, написано, что нельзя зарегистрировать его через сайт (firebase?). В оригинале статьи так же написано, т.ч. это не кривой перевод.
Могу предположить, что уязвимость была как раз в реализации мультитенанси. И с учётной для одной компании можно было получить доступ к чужим данным. И очень может быть, что учётку можно получить через покупку сервиса у Chattr.ai
Самое смешное, это что как раз согласно принципам Scrum - по результатам инспекции провели адаптацию и изменили длительность спринта.
Scrum guide не декларирует спринты в 2 недели. Более того, рекомендует следующий критерий выбора оптимальной продолжительности спринта: она должна позволять выпустить продакт инкремент как результат спринта (передаю смысл, а не цитирую).
Возьмите для примера историю VK или любой другой успешной "социальной сети" с многомиллионной аудиторией. Чем оно было на старте и чем стало сейчас в плане архитектуры?
Да, инкрементальная и итеративная разработка появились до Agile, но последний как раз лучше подходит для продуктовой разработки и развитие в динамике с высокой неопределенностью в направлениях изменений.
Есть издержки на переделку архитектуры. Но компания их несет, уже зарабатывая с сервиса.
Сколько бы заняло написание требований, проектирование и реализация VK в текущем виде? Какой бюджет на это потребовался бы? А сколько бы стоило вписать в эти требования мобилки, которых на старте не было?
Здравствуйте! Спасибо за обзор, но с какой целью продукты разных назначений представлены как системы управления проектами? Согласно классификации Gartner Jira относится к Enterprise Agile Planning, а не Project Management (PPM).
Мой интерес как раз в альтернативах Jira как средства управления продуктовой разработкой, а не управления проектами.
Отдельно взятого человека, который занимался бы только тем, что следит за соблюдением инженерных практик, я за более чем 20 лет работы ни разу не встречал.
А Вам приходилось внедрять безопасную разработку (SSDLC)? Или сертифицироваться по ISO 27001?
Наоборот, я, как инженер "старой школы", выступаю за максимальную формализацию процесса разработки, вплодь до написания ТЗ.
У меня есть печальный опыт согласования Т.З. с заказчиком на протяжении 22 месяцев. Саму доработку мы оценили в 6 человеко-месяцев (и 4 месяца по срокам).
Скрам стал востребован в эпоху дот-комов, когда выпустить сайт или приложение и посмотреть на реакцию пользователей оказалось быстрее и эффективнее, чем написать Т.З.и пройти по стандартной модели SDLC.
VK - как пример (изначально LAMP, который решал проблемы масштабирования и производительности по мере появления пользователей.
А вот начали бы с Т.З. под текущую аудиторию, до сих пор писали бы.
Я верю в идею командной работы и верю в идею коллективной ответственности, хоть и не до конца их понимаю. Я лишь заявляю что скрам - не является инструментом их построения.
С этим я не согласен, он как раз является инструментом построения эффективного взаимодействия для команды профессионалов, которые разделяют ценности скрама.
Он является лишь стандартом описывающим черты команд которые смогли это построить раньше в своих условиях.
Все верно, авторы скрама как раз где-то писали, что обощали опыт сложившихся успешных команд.
Но скрам-гайд не описывает трансформацию, т.е. переход от иерархической структуры к скраму. И ничего не говорит про методологию разработки ПО или инженерные практики.
А как это, разделять ценности? Как мне определить разделяю ли я их, каков критерий? Как тому кто хочет научиться уважению перейти от декларативного концепта уважения к процедурной последовательности действий сливающейся в проявление уважения?
Ценности - это из области Ваших внутренних убеждений. Разделять ценности - принимать решения и действовать в соответствии с ними. Например, если с планирования спринта Вы уходите с мыслью "мне за спринт надо реализовать такую-то фичу в моем компоненте", а не "мы за спринт должны достичь такой-то цели", то приверженность - это не про Вас. Уважение - признать, что коллега имеет право на свое собственное мнение, право его высказывать, право на поддержку, право совершить ошибку в той же мере, что и Вы.
А откуда у вас взялась мысль о том что я не уважал своих коллег?
Я сразу написал, что это не более, чем предположения. Но в статье не упоминается, что Вы демострировали желание работать над общими задачами или обсуждать с командой проблемы скрам на ретро, фраза про тим-лида, компетенции которого никуда не делись, косвенно говорит, что у остальных членов команды компетенции развиты слабее.
Скрам это не инструмент достижения цели а рамки ограничиющие выход за пределы некоторой области внутри которой предположительно находится решение.
Для меня скрам - это способ решения проблем, например, избавление от "функциональных колодцев". Или обеспечение прозрачности статуса в долгосрочных проектах (через спринты).
С тем, что он не явлвется методологией (или универсальным инструментом), я не спорю.
Для того чтобы реально помогать он должен быть ещё и менеджером и/или инженером.
Это Ваш опыт, я его не оспариваю. Работа скрам-мастера не в том, чтобы предложить лучшее решение проблемы и защитить его, а в том, чтобы собрать нужных людей и провести встречу так, чтобы в результате появилось решение. Нужен ли для этого инженерный опыт? Сомневаюсь. Скрам-мастер не принимает решения, агрументы должны быть понятны команде, а не ему.
Но скажу честно, на практике не сталкивался со скрам-мастерами без технического бэкграунда.
Он может только выполнять ритуалы.
Ритуалы на начальном этапе - это Сю в Сю-Ха-Ри. Проверенный на протяжении веков путь к мастерству. Я видел многих, которые начинали с Ри и фейлились.
Автор, а Вы ценности scrum разделяете? Приверженность, сфокусированность, открытость, уважение и смелость?
В частности, между строк читается, что своих коллег вы не уважали и совместно работать с ними над общими задачами были не готовы. Я прав?
В этом случае опытный скрам-мастер не стал бы включать Вас в скрам-команду, а использовал как внешний сервис.
Но в одном Вы правы, скрам не является методологией разработки ПО (или описанным SDLC).
И авторы скрама предполагают, что скрам команда самостоятельно создаст такую методологию, пользуясь принципами. А вот осилить это могут только достаточно зрелые компании.
Если по результатам дейли вы не готовы отложить свою задачу и переключиться на помощь коллеге - дейли (а значит и скрам) вам не нужны.
Если по результатам спринта у вас нет готового к продакшину инкремента - скрам вам не нужен.
Если план команды разработки расписан на кварталы вперед и не пересматривается при получении обратной связи - скрам вам не подходит.
К сожалению, авторы скрама не описали его область применения. И большинство скрам-коучей этого не делают. Поэтому очень часто его внедряют там, где он не подходит для продукта и/или команды. Т.ч.на счет карго-культа Вы правы.
P.S.
Роль скрам-мастера - научить команду правильно взаимодействовать (внутри себя, с владельцем продукта, с заказчиками и прочими заинтересованными лицами). И если брать аналогию с тренером, то задача тренера как раз сделать из отдельных игроков команду и подобрать для них оптимальную тактику на игру. "Порядок бьет класс".
А я с большинством тезисов автора в общем-то согласен.
Он не написал, где работал до переезда, но в 2016 я наблюдал в крупной российской компании, когда "крутостью" разработчика считалось написание именно сложного (а потому и не поддерживаемого остальной командой) кода.
Т.ч. на самом деле все зависит от зрелости компании, думаю, что все еще полно мест с "уникальными" разработчиками, в коде которых могут разобраться только они сами.
Скорее ушли те, кто саму постановку вопроса «не нравится — можете уходить» счел для себя неприемлемой.
Это как в том анекдоте, когда полицейский остановил машину и отоварил дубинкой сначала водителя, а потом пассажира.
Пассажир:
-А меня-то за что?
Полицейский:
— Чтобы не думал «попробовал бы он так со мной поступить».
Руководство компании открыто заявило об изменении корпоративной культуры.
Причем, заявление гораздо шире, чем запрет на обсуждении «политики» в рабочих чатах.
Они выразили несогласие с этими изменениями.
Придумывать ничего не надо.
И за что человека заминусовали?
Я мечтаю о временах, когда в России на заявление руководства компании «кому не нравится — можете уйти» треть сотрудников встанет и уйдет… А еще лучше — все встанут и уйдут.
Кстати, в заявлении Джейсона Фрида было несколько пунктов об изменении корпоративной культуры в целом, включая процесс оценки сотрудников и схему принятия решений. Почему все привязались к «полите» в корпоративных чатах?
Вы же свои расчеты не привели…
Если Вы платили за helpdesk по 10 тыс. руб. в месяц на человека, то это сомнительный повод писать свое решение.
Про то, что количество инженеров поддержки удалось сократить в полтора раза, Вы тоже не написали.
С моей точки зрения, при решении бизнес задач, основной критерием изящества является оптимальность решения по сложности и трудоемкости поставленной задаче.
В книге про тестирование в гугле про это хорошо написано.
Когда изначально проект развивается как старт-ап, с минимальными требованиями к процессу разработки. И если в нем видят потенциал, начинают инвестировать в качество.
Это и есть управление качеством.
Очень часто техническим долгом становятся как раз изящные решения, т.к. кроме автора их поддерживать никто не может.
Опять же, к техническому долгу надо относиться как к долгу или кредитам — занимаем сейчас, отдаем в будущем. Все сводится к контролю на этим самым долгом.
Там не написано, что нельзя создать нового пользователя, написано, что нельзя зарегистрировать его через сайт (firebase?). В оригинале статьи так же написано, т.ч. это не кривой перевод.
Могу предположить, что уязвимость была как раз в реализации мультитенанси. И с учётной для одной компании можно было получить доступ к чужим данным. И очень может быть, что учётку можно получить через покупку сервиса у Chattr.ai
Самое смешное, это что как раз согласно принципам Scrum - по результатам инспекции провели адаптацию и изменили длительность спринта.
Scrum guide не декларирует спринты в 2 недели. Более того, рекомендует следующий критерий выбора оптимальной продолжительности спринта: она должна позволять выпустить продакт инкремент как результат спринта (передаю смысл, а не цитирую).
Agile mnifesto ничего не говорит про спринты.
Спринты фиксированной длительности - это про Scrum, почему оно именно так, объясняется в scrum guide.
Если компания выбрала Scum как подходящий для ее задач фреймворк, то приняла его правила игры.
"Давайте продлим спринт на 2 дня, потому что я не успел сделать задачу" - это не про ту гибкость, которая заложена в философию Agile.
Возьмите для примера историю VK или любой другой успешной "социальной сети" с многомиллионной аудиторией. Чем оно было на старте и чем стало сейчас в плане архитектуры?
Да, инкрементальная и итеративная разработка появились до Agile, но последний как раз лучше подходит для продуктовой разработки и развитие в динамике с высокой неопределенностью в направлениях изменений.
Есть издержки на переделку архитектуры. Но компания их несет, уже зарабатывая с сервиса.
Сколько бы заняло написание требований, проектирование и реализация VK в текущем виде? Какой бюджет на это потребовался бы? А сколько бы стоило вписать в эти требования мобилки, которых на старте не было?
Здравствуйте! Спасибо за обзор, но с какой целью продукты разных назначений представлены как системы управления проектами? Согласно классификации Gartner Jira относится к Enterprise Agile Planning, а не Project Management (PPM).
Мой интерес как раз в альтернативах Jira как средства управления продуктовой разработкой, а не управления проектами.
Спасибо!
Добрый день!
Возникла аналогичная задача, и поэтому несколько вопросов:
Не нашлось ли лучшее решение за это время, чем собственные макросы? Например, плагины к JIRA?
Не выложены ли случайно макросы в публичный репозиторий :-)
JIRA key сохраняли в кастомном поле?
Отслеживалось ли заведение подзадач в JIRA или первоисточником был только MS Project?
Подтягивались ли трудозатраты из JIRA? Или отслеживались только статусы задач?
Была ли связь между ресурсами в ms project и исполнителями в JIRA?
Мог ли в JIRA появиться новый исполнитель? Как обрабатывалась ситуация?
Спасибо!
А Вам приходилось внедрять безопасную разработку (SSDLC)? Или сертифицироваться по ISO 27001?
У меня есть печальный опыт согласования Т.З. с заказчиком на протяжении 22 месяцев. Саму доработку мы оценили в 6 человеко-месяцев (и 4 месяца по срокам).
Скрам стал востребован в эпоху дот-комов, когда выпустить сайт или приложение и посмотреть на реакцию пользователей оказалось быстрее и эффективнее, чем написать Т.З.и пройти по стандартной модели SDLC.
VK - как пример (изначально LAMP, который решал проблемы масштабирования и производительности по мере появления пользователей.
А вот начали бы с Т.З. под текущую аудиторию, до сих пор писали бы.
С этим я не согласен, он как раз является инструментом построения эффективного взаимодействия для команды профессионалов, которые разделяют ценности скрама.
Все верно, авторы скрама как раз где-то писали, что обощали опыт сложившихся успешных команд.
Но скрам-гайд не описывает трансформацию, т.е. переход от иерархической структуры к скраму. И ничего не говорит про методологию разработки ПО или инженерные практики.
Ценности - это из области Ваших внутренних убеждений. Разделять ценности - принимать решения и действовать в соответствии с ними. Например, если с планирования спринта Вы уходите с мыслью "мне за спринт надо реализовать такую-то фичу в моем компоненте", а не "мы за спринт должны достичь такой-то цели", то приверженность - это не про Вас. Уважение - признать, что коллега имеет право на свое собственное мнение, право его высказывать, право на поддержку, право совершить ошибку в той же мере, что и Вы.
Я сразу написал, что это не более, чем предположения. Но в статье не упоминается, что Вы демострировали желание работать над общими задачами или обсуждать с командой проблемы скрам на ретро, фраза про тим-лида, компетенции которого никуда не делись, косвенно говорит, что у остальных членов команды компетенции развиты слабее.
Для меня скрам - это способ решения проблем, например, избавление от "функциональных колодцев". Или обеспечение прозрачности статуса в долгосрочных проектах (через спринты).
С тем, что он не явлвется методологией (или универсальным инструментом), я не спорю.
Это Ваш опыт, я его не оспариваю. Работа скрам-мастера не в том, чтобы предложить лучшее решение проблемы и защитить его, а в том, чтобы собрать нужных людей и провести встречу так, чтобы в результате появилось решение. Нужен ли для этого инженерный опыт? Сомневаюсь. Скрам-мастер не принимает решения, агрументы должны быть понятны команде, а не ему.
Но скажу честно, на практике не сталкивался со скрам-мастерами без технического бэкграунда.
Ритуалы на начальном этапе - это Сю в Сю-Ха-Ри. Проверенный на протяжении веков путь к мастерству. Я видел многих, которые начинали с Ри и фейлились.
Автор, а Вы ценности scrum разделяете? Приверженность, сфокусированность, открытость, уважение и смелость?
В частности, между строк читается, что своих коллег вы не уважали и совместно работать с ними над общими задачами были не готовы. Я прав?
В этом случае опытный скрам-мастер не стал бы включать Вас в скрам-команду, а использовал как внешний сервис.
Но в одном Вы правы, скрам не является методологией разработки ПО (или описанным SDLC).
И авторы скрама предполагают, что скрам команда самостоятельно создаст такую методологию, пользуясь принципами. А вот осилить это могут только достаточно зрелые компании.
Если по результатам дейли вы не готовы отложить свою задачу и переключиться на помощь коллеге - дейли (а значит и скрам) вам не нужны.
Если по результатам спринта у вас нет готового к продакшину инкремента - скрам вам не нужен.
Если план команды разработки расписан на кварталы вперед и не пересматривается при получении обратной связи - скрам вам не подходит.
К сожалению, авторы скрама не описали его область применения. И большинство скрам-коучей этого не делают. Поэтому очень часто его внедряют там, где он не подходит для продукта и/или команды. Т.ч.на счет карго-культа Вы правы.
P.S.
Роль скрам-мастера - научить команду правильно взаимодействовать (внутри себя, с владельцем продукта, с заказчиками и прочими заинтересованными лицами). И если брать аналогию с тренером, то задача тренера как раз сделать из отдельных игроков команду и подобрать для них оптимальную тактику на игру. "Порядок бьет класс".
А я с большинством тезисов автора в общем-то согласен.
Он не написал, где работал до переезда, но в 2016 я наблюдал в крупной российской компании, когда "крутостью" разработчика считалось написание именно сложного (а потому и не поддерживаемого остальной командой) кода.
Т.ч. на самом деле все зависит от зрелости компании, думаю, что все еще полно мест с "уникальными" разработчиками, в коде которых могут разобраться только они сами.
92 миллиона строк — это с дампами баз для нагрузочного тестирования?
Это как в том анекдоте, когда полицейский остановил машину и отоварил дубинкой сначала водителя, а потом пассажира.
Пассажир:
-А меня-то за что?
Полицейский:
— Чтобы не думал «попробовал бы он так со мной поступить».
Причем, заявление гораздо шире, чем запрет на обсуждении «политики» в рабочих чатах.
Они выразили несогласие с этими изменениями.
Придумывать ничего не надо.
Я мечтаю о временах, когда в России на заявление руководства компании «кому не нравится — можете уйти» треть сотрудников встанет и уйдет… А еще лучше — все встанут и уйдут.
Кстати, в заявлении Джейсона Фрида было несколько пунктов об изменении корпоративной культуры в целом, включая процесс оценки сотрудников и схему принятия решений. Почему все привязались к «полите» в корпоративных чатах?
Если Вы платили за helpdesk по 10 тыс. руб. в месяц на человека, то это сомнительный повод писать свое решение.
Про то, что количество инженеров поддержки удалось сократить в полтора раза, Вы тоже не написали.
В книге про тестирование в гугле про это хорошо написано.
Когда изначально проект развивается как старт-ап, с минимальными требованиями к процессу разработки. И если в нем видят потенциал, начинают инвестировать в качество.
Это и есть управление качеством.
В успешность работников, которые не могут объяснить, над чем и зачем они работают, я не верю.
Уж извините.
Выводы делаются на основании личного опыта.
Опять же, к техническому долгу надо относиться как к долгу или кредитам — занимаем сейчас, отдаем в будущем. Все сводится к контролю на этим самым долгом.