Сообщение Re[20]: эндорфины и stand up от 20.06.2023 13:36
Изменено 20.06.2023 13:44 Pauel
Re[20]: эндорфины и stand up
Здравствуйте, landerhigh, Вы писали:
L>Это уже анекдот про мужиков и японскую бензопилу.
L>Если полно операционной деятельности, которая не дает вести разработку, то нужно поднимать вопрос с менеджментом о реогранизации работы.
Вот смотрите, есть два основных кейса в разработке с т.з. используемых технологий:
1. вы пилите, условно, еще одну приложуху из того класса что пишут везде. Неопределенность минимальна и ограничена почти что исключительно заказчиком, то есть — архитектура, стек, основные проблемы известны еще до старта проекта
2. вы пилите приложение, навроде которого до вас никто еще не писал — здесь у вас риски вообще везде, не считая заказчика, вы не знаете ни примерную архитектуру, ни проблемы, не можете оценить перформанс, издержки на инфраструктуру итд.
В первом случае вы можете начинать прямо со скрама, именно под такие кейсы он и заточен
Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день. Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть. Каждый фейл нужно рассматривать как новый, неизвестный ранее риск для которого нужно понять, как быть — игнорировать, или как то подстраховаться.
Поскольку вы ничего про это не знали, ваш спринт накрылся медным тазом.
Следующий спринт вы получаете тож самое — вы запилили прототип клиента, только собираетесь брать очередной тикет из баклога, а тестировщики прибегают и орут "ужос, клиент не работает, валится стабильно после 8ми вечера"(реальный кейс). Вы бросаете всё и ищете проблему, проблема в том, что есть бага, которая пофиксана только для свежей ос, а поддерживать надо всё, на чем будут потенциальные юзера. Ищете фикс, пока ищете — ваш баклог на паузе. Нашли, только собираетесь взять тикет из баклога, снова прибегает QA и говорит, что клиент валится гарантировано в течение 30 минут(реальный кейс). Снова бросаете всё, ищете проблему. Находите. Только собираетесь брать тикет из баклога, QA прибегает и говорит, что работает только на виртуалке(снова реальный кейс). Вы снова бросаете баклог, ищете проблему. Находите, снова хотите брать чтото из баклога, а QA приходит и говорит что клиент(сервер) не может...
Итого — потрачено куча спринтов, в каждом из которых план ломается прямо на первый-второй день.
В конце, если задачи решаемые, вы найдете примерную архитектуру приложения, только далеко не факт, что бюджета хватит на ваши изыскания.
L>Это уже анекдот про мужиков и японскую бензопилу.
L>Если полно операционной деятельности, которая не дает вести разработку, то нужно поднимать вопрос с менеджментом о реогранизации работы.
Вот смотрите, есть два основных кейса в разработке с т.з. используемых технологий:
1. вы пилите, условно, еще одну приложуху из того класса что пишут везде. Неопределенность минимальна и ограничена почти что исключительно заказчиком, то есть — архитектура, стек, основные проблемы известны еще до старта проекта
2. вы пилите приложение, навроде которого до вас никто еще не писал — здесь у вас риски вообще везде, не считая заказчика, вы не знаете ни примерную архитектуру, ни проблемы, не можете оценить перформанс, издержки на инфраструктуру итд.
В первом случае вы можете начинать прямо со скрама, именно под такие кейсы он и заточен
Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день. Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть. Каждый фейл нужно рассматривать как новый, неизвестный ранее риск для которого нужно понять, как быть — игнорировать, или как то подстраховаться.
Поскольку вы ничего про это не знали, ваш спринт накрылся медным тазом.
Следующий спринт вы получаете тож самое — вы запилили прототип клиента, только собираетесь брать очередной тикет из баклога, а тестировщики прибегают и орут "ужос, клиент не работает, валится стабильно после 8ми вечера"(реальный кейс). Вы бросаете всё и ищете проблему, проблема в том, что есть бага, которая пофиксана только для свежей ос, а поддерживать надо всё, на чем будут потенциальные юзера. Ищете фикс, пока ищете — ваш баклог на паузе. Нашли, только собираетесь взять тикет из баклога, снова прибегает QA и говорит, что клиент валится гарантировано в течение 30 минут(реальный кейс). Снова бросаете всё, ищете проблему. Находите. Только собираетесь брать тикет из баклога, QA прибегает и говорит, что работает только на виртуалке(снова реальный кейс). Вы снова бросаете баклог, ищете проблему. Находите, снова хотите брать чтото из баклога, а QA приходит и говорит что клиент(сервер) не может...
Итого — потрачено куча спринтов, в каждом из которых план ломается прямо на первый-второй день.
В конце, если задачи решаемые, вы найдете примерную архитектуру приложения, только далеко не факт, что бюджета хватит на ваши изыскания.
Re[20]: эндорфины и stand up
Здравствуйте, landerhigh, Вы писали:
L>Это уже анекдот про мужиков и японскую бензопилу.
L>Если полно операционной деятельности, которая не дает вести разработку, то нужно поднимать вопрос с менеджментом о реогранизации работы.
Вот смотрите, есть два основных кейса в разработке с т.з. используемых технологий:
1. вы пилите, условно, еще одну приложуху из того класса что пишут везде. Неопределенность минимальна и ограничена почти что исключительно заказчиком, то есть — архитектура, стек, основные проблемы известны еще до старта проекта. Проблем хватает, но про них почти всегда известно, что "ну, можно и обойти" или "вернемся позже"
2. вы пилите приложение, навроде которого до вас никто еще не писал — здесь у вас риски вообще везде, не считая заказчика, вы не знаете ни примерную архитектуру, ни проблемы, не можете оценить перформанс, издержки на инфраструктуру итд.
В первом случае вы можете начинать прямо со скрама, именно под такие кейсы он и заточен
Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день. Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть. Каждый фейл нужно рассматривать как новый, неизвестный ранее риск для которого нужно понять, как быть — игнорировать, или как то подстраховаться.
Поскольку вы ничего про это не знали, ваш спринт накрылся медным тазом.
Следующий спринт вы получаете тож самое — вы запилили прототип клиента, только собираетесь брать очередной тикет из баклога, а тестировщики прибегают и орут "ужос, клиент не работает, валится стабильно после 8ми вечера"(реальный кейс). Вы бросаете всё и ищете проблему, проблема в том, что есть бага, которая пофиксана только для свежей ос, а поддерживать надо всё, на чем будут потенциальные юзера. Ищете фикс, пока ищете — ваш баклог на паузе. Нашли, только собираетесь взять тикет из баклога, снова прибегает QA и говорит, что клиент валится гарантировано в течение 30 минут(реальный кейс). Снова бросаете всё, ищете проблему. Находите. Только собираетесь брать тикет из баклога, QA прибегает и говорит, что работает только на виртуалке(снова реальный кейс). Вы снова бросаете баклог, ищете проблему. Находите, снова хотите брать чтото из баклога, а QA приходит и говорит что клиент(сервер) не может...
Итого — потрачено куча спринтов, в каждом из которых план ломается прямо на первый-второй день.
В конце, если задачи решаемые, вы найдете примерную архитектуру приложения, только далеко не факт, что бюджета хватит на ваши изыскания.
L>Это уже анекдот про мужиков и японскую бензопилу.
L>Если полно операционной деятельности, которая не дает вести разработку, то нужно поднимать вопрос с менеджментом о реогранизации работы.
Вот смотрите, есть два основных кейса в разработке с т.з. используемых технологий:
1. вы пилите, условно, еще одну приложуху из того класса что пишут везде. Неопределенность минимальна и ограничена почти что исключительно заказчиком, то есть — архитектура, стек, основные проблемы известны еще до старта проекта. Проблем хватает, но про них почти всегда известно, что "ну, можно и обойти" или "вернемся позже"
2. вы пилите приложение, навроде которого до вас никто еще не писал — здесь у вас риски вообще везде, не считая заказчика, вы не знаете ни примерную архитектуру, ни проблемы, не можете оценить перформанс, издержки на инфраструктуру итд.
В первом случае вы можете начинать прямо со скрама, именно под такие кейсы он и заточен
Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день. Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть. Каждый фейл нужно рассматривать как новый, неизвестный ранее риск для которого нужно понять, как быть — игнорировать, или как то подстраховаться.
Поскольку вы ничего про это не знали, ваш спринт накрылся медным тазом.
Следующий спринт вы получаете тож самое — вы запилили прототип клиента, только собираетесь брать очередной тикет из баклога, а тестировщики прибегают и орут "ужос, клиент не работает, валится стабильно после 8ми вечера"(реальный кейс). Вы бросаете всё и ищете проблему, проблема в том, что есть бага, которая пофиксана только для свежей ос, а поддерживать надо всё, на чем будут потенциальные юзера. Ищете фикс, пока ищете — ваш баклог на паузе. Нашли, только собираетесь взять тикет из баклога, снова прибегает QA и говорит, что клиент валится гарантировано в течение 30 минут(реальный кейс). Снова бросаете всё, ищете проблему. Находите. Только собираетесь брать тикет из баклога, QA прибегает и говорит, что работает только на виртуалке(снова реальный кейс). Вы снова бросаете баклог, ищете проблему. Находите, снова хотите брать чтото из баклога, а QA приходит и говорит что клиент(сервер) не может...
Итого — потрачено куча спринтов, в каждом из которых план ломается прямо на первый-второй день.
В конце, если задачи решаемые, вы найдете примерную архитектуру приложения, только далеко не факт, что бюджета хватит на ваши изыскания.