Pull to refresh

Comments 30

Интересно, а у вас принято использовать во время стендапа маркерные доски, или другие инструменты для визуализации (как схемы приведенные статье) или понимания контекста внутри команды хватает?
да, иногда используются маркерные доски (в офисе достаточно мест, где можно пописать маркером), но обычно какие-то визуальные или архитектурные вопросы откладываются на обсуждения после скрам-митинга
Кстати, уже не раз терял деньги и время из-за непродуманности приложения.
Суть, выбираю такси и в пожеланиях указываю детское кресло. Идет поиск машины и свободных машин нет, с предложением попробовать поискать еще раз. Соглашаюсь и машина находится, вот только повторный поиск идет с пустыми пожеланиями. В итоге приезжает машина без детского кресла и приходится отменять заказ и вызывать заново.
Приветствую! А давайте на примере посмотрим, что пошло не так. Напишите на почту blogs@taxi.yandex.ru с заказом, о котором идёт речь, пожалуйста.
Вы серьезно на таком низком уровне обсуждаете свою работу? Это же противоречит всем бест практикам стендапов. Такие обсуждения обычно очень быстро превращаются в бурные и длительные дискуссии и стендап очень сильно затягивается.
спасибо за вопрос, верно подмечено, у нас в команде есть ограничение в 15 минут на скрам-митинг, в рамках встречи обязательно регулируется время, затраченное на поднятый вопрос и часто его обсуждение откладывается на время после скрама (особенно если это какой-то технически сложный вопрос, например требующий погружения в архитектуру сервиса)

но также скрам-встреча позволяет акцентировать внимание на отдельных моментах проделанной работы (как например вопрос связанный с sql скриптом), если бы вопрос не был поднят — Анна бы и не узнала, что у Вадима есть экспертиза в данном вопросе и скорее всего потратила намного больше времени на раскопки
Немного странно, что Анна случайно это узнала, и что у Вадима случайно оказалась эта экпертиза.
это достаточно частое явление, ведь у всех разработчиков разный опыт и разный путь в IT-индустрии — кто-то мог на предыдущем месте работы столкнуться с точно такой же проблемой, кто-то мог работать с той же СУБД но не касаться описанного случая, а кто-то мог работать с абсолютно другим стеком технологий, поэтому обсуждение (или хотя бы упоминание проблемы) только приветствуется на скрамах
UFO just landed and posted this here
UFO just landed and posted this here
А сколько человек на 15 минут? И есть ли модератор?

как правило в таких митингах участвует ~5 человек, один из которых следит за проведением самого митинга

Если все сидят рядом в опенофисе, то хочешь не хочешь, знаешь и видишь что происходит вокруг.

Вы абсолютно правы, но при этом объявление какого-то значимого рефакторинга или тормозящей проблемы на стендапе 'гарантирует' что эта информация дойдет до каждого члена команды
Всё равно на мой взгляд уровень «детализации» для стэндапа слишком высок. Если в команде 3-5 разрабов и 2-3 тестера, то в 15 минут они никак не уложатся.
И зачем вообще на стэндапе рассказывать каким образом кто-то уже решил какую-то проблему? Если есть проблема и сам не можешь её решить, то это одно. Но если уже сам нашёл решение, то это в лучшем случае информация на какой нибудь DevCop.
я согласен с Вами,
в большинстве случаев задачи обсуждаются на митингах в общих чертах, и лишь в редких случаях задачи разбираются подробно

в примере статьи есть подробные описания задач, их решения, а также итоги по задачам лишь по той простой причине, что читатели находятся вне контекста
зачем люди заменяют слово опыт на слово экспертиза?
А какую задачу решают эти стендапы? Не подумайте, что пытаюсь троллить, действительно интересно. Работал пару лет в компании, где практиковались ежедневные собрания на 15-20 минут, каждый рассказывал, что делал вчера и что собирается делать сегодня. Но вот какой-то реальной пользы от этого так и не заметил — за отведенные 1-3 минуты просто невозможно нормально вникнуть в задачу, а информацию о том, что сотрудник Вася вчера работал над тикетом N и планирует продолжать над ним работать сегодня, обычно все мимо ушей пропускали. И я, каюсь, тоже. Возможно, конечно, что мы что-то делали неправильно… В своей команде я подобную практику отменил — считаю, что 1 собрания раз в неделю вполне достаточно.
Ну у нас основная цель это мониторить укладываемся ли мы более-менее в сроки. И определять наличие проблем из-за которых мы можем в эти самые сроки не уложится и пытаться оперативно найти решение этих проблем.

Примерно половина «проблем» это когда кто-то «зависает» над какой-то задачей и не может сдвинуться с места. И тогда либо кто-то помогает, либо просто задачу передают кому-то другому.
Вторая половина это обычно проблемы «извне» команды, когда кто-то посторонний что-то не сделал вовремя или сделал неправильно. Тогда сениоры и/или ПО идут разруливать ситуацию в «большой мир».

П. С. Всё это в принципе можно и без стендапа, но мы всё равно идём утром всей тимой за «обязательным утренним кофе» и просто совмешаем приятное с полезным.
согласен, что одного собрания достаточно, остальные в рабочем порядке… а то эти ежедневные собрания напоминают поделись своим успехом у саентологов
UFO just landed and posted this here
  1. Сильно ли "Такси" полагается на Python? Или даже так — много ли удается писать на Python, а не на C++?
  2. Если не трудно, можете написать фидбек об использовании asyncio — что понравилось, а что нет и за какой по времени срок.
1. В продуктовой разработке Такси на Python можно писать практически все. Обычно мы даем разработчикам выбор: новые микросервисы можно писать либо на C++ либо на Python (Python3) — как захочет разработчик/команда. На практике примерно 50-70% новых микросервисов пишется на Python в продукте. В инфраструктурной разработке больше C++.
UFO just landed and posted this here

Недавно столкнулся с неприятным случаем — перед заказом iOS-приложение Такси показывало одну стоимость (с учётом скидки от плюса и даже при учете повышенного спроса), а после поездки внезапно обнаружил, что с карты списали более чем в 1.5 раза большую сумму.


Вероятно, это баг, но довольно серьёзный, и не хотелось бы, чтобы такие вещи далее появлялись на продакшне.

У нас в команде следующий подход: если на код-ревью задают вопрос по поводу реализации (просят объяснить алгоритм), то необходимо добавить комментарий. А ещё лучше подумать об этом заранее и добавить его самому.

Есть вариант с тем чтобы переписать так, чтобы код был понятнее? Кажется это должен быть план А, а план Б уже написать комментарий.

Это точно статья про Яндекс? Там же 6-этапные многодневные изнурительные евроинтервью, они же отбирают сливки из лучших из лучших… не могу поверить, что тамошние программеры так могут косячить или не уметь оптимизировать SQL...

видать, лучшие из лучших в итоге не считают Яндекс лучшим X)
Вообще, явно это вопросы стажёров или младших
как и все хорошее, удобство яндекс такси закончилось и его поменяли на деньги.
1. Приезжаю в незнакомый город хочу узнать во сколько встанет поездка вокзал/аэропорт — гостинница/завод. НЕсколько похожих запросов из одной точки и вуаля: когда с выбором определился, цена выше- вы там как определяете повышенный спрос?
2. Приезжаю поездом выхожу, пытаюсь вызвать такси до дома/гостиницы, тариф показывается приемлемый, заказываю жду когда найдется машинка и приедет.Рядом стоят чуть ли не с десяток машин расклеенных Яндекс.Но машина не находится. Повторно тариф повышается. И так может раза три повысится. Если ожидается прибытие курортного поезда или из московского то тариф может меняться, машины брендированные чуть ли не рядом стоят ......(сами можете почитать боцманский словарь идиоматических выражений экспрессивной лексики по данному поводу). Как работает алгоритм если удобство уничтожено желанием таксистов за бешенную сумму везти с вокзала/аэропорта? Получается водители нашли лазейки самим определять цену которую желают?
3. КАк то заявлялось что в приложении водителя есть контроль за безопасностью движения, он есть или эта функция не прижилась?
вот в том и дело, что можно один раз посмотреть, закрыл. снова открыл — цена возросла. Хотя и народа, субъективно, никого нет вокруг. А статья спасибо, знакома.
Sign up to leave a comment.