Как стать автором
Обновить
12
0
Андрей Глазков @Glazz87

Quality Assurance

Отправить сообщение

В конкретной статье вообще не раскрыто, в чем же отличие красной от оранжевой и почему при наличии сильных лидеров в обоих случаях - это разные уровни спирали.

Спасибо за статью, расписано хорошо.

Не очень понятно, что такое "прямой стык в Москве или Санкт-Пе­тер­бур­ге" и как он для региональных операторов заменит их собственные сервера GGC?

Ладно, я думал тут какой-то скрытый смысл (типа Tesla S3XY), но видимо просто шутка на тему однобуквенных брендов (

Точно, сам был в восторге как мой самый первый самый младший Core2Duo E6320 при номинале в 1.86 ГГц гнался до 2.4 ГГц(уровень Core2Duo E6600 который был в 2 раза дороже)! Легендарный проц.
Спасибо. Материал базовый, но хорошо структурированный. Когда увязнешь с решением какой-то конкретной процессной беды у себя в кIT отделе, то бывает очень полезно прочесть такой вот материал обзорный материал, чтобы снова вспомнить о глобальном роадмепе развития компании в целом.
Даже удивительно, как из такой замечательной компании мог кто-то уволиться, да ещё и внезапно, никому ничего не сказав…
Хотя нет, неудивительно.
Актуально и в 19 году!
Спасибо за обзор!
Маленькая поправка: Mountebank написан на NodeJS, а не на Python'e. На python'e наш автотестовый фреймворк, поэтому и примеры были на нём.
Отличная инициатива, мечтаю дожить до момента, когда в России столичный уровень зарплат среди ИТ-специалистов будет не только в столицах.
Расскажите, как ищете лидера офиса? Как проверяете его инициативность и готовность развивать офис в целом, а не только себя как специалиста? Как контролируете его успехи уже в процессе работы?
Отличная статья, спасибо!
Подскажите, какую именно компанию привлекали для реализации проекта?
Как альтернатива CURL'у на винде Postman просто прекрасен. Но для более-менее серьезной автоматизации он слаб. SoapUI мощнее и удобнее в плане тестов, JMeter — король для нагрузочного тестирования.

Ну а уж когда понадобится действительно серьезная автоматизация, то без полноценных coded тестов уже не обойтись ни одним из вышеперечисленных инструментов.

Как живая документация к API Postman слабоват, посмотрите в сторону Swagger.

Но за статью плюс, хорошая, буду рекомендовать своим джунам для знакомства с инструментом.
Известная российская компания VisionLabs с точностью 99,9 % распознает лица покупателей.


Во-первых, о 99.9% не заявляет даже сама VisionLabs. Лучший результат: 99.3% по вашей же ссылке.
Во-вторых, не очень понятно на основе какого эксперимента получены данные результаты. Кто эксперимент проводил и кто проверял, какие датасеты использовались?
В данной области есть один достаточно известный и уважаемый бенчмарк алгоритмов распознавания лица: MegaFace. Проводит его Вашингтонский Университет: megaface.cs.washington.edu

Лучшие результаты на более менее серьезных датасетах — порядка 78%. Там участвует Google, Facebook, Tencent, из наших NTech и Vocord. VisionLabs среди участников нет.
Потому что это первая статья автора.
Идеальная статья чтобы настроиться на рабочий лад после выходных, проведенных за игрой престолов с женой. Москвичи поймут почему.
Что эта статья на хабре делает? 100% гиктаймовская тематика.
Отдельное раздражение вызывает «новая профессия трабл-шутер». Говорите по-русски: «на все руки мастер лишь бы платили».
Самых большая ошибка — пытаться натянуть скрам там, где он не нужен. «Закрытая» компания на гос. заказе? Монопольная отрасль? Не рыночные отношения с заказчиком? Скрам такому бизнесу больше навредит.
А уж привязывать берндаун к запрплате — это верный способ замотивировать команду на обман, но никак не на эффективность.
Откуда вдруг взялся product owner? Тоже сидел в засаде, как партизан?

Product owner должен понимать рынок и транслировать видение продукта в соответствии с ним. У классического проектного менеджера совсем другие компетенции… Скорее уж бизнес-аналитик на это способен.


Смысл моего ответа в том, что этот человек уже есть в компании на момент внедрения скрама. Не важно какая у него должность в трудовой, хоть генеральный директор. В реальности нужно чтобы этот человек отвечал за продукт, грамотно формулировал User Story и выполнял другие обязанности по отношению к команде. Если он видит продукт не так, как хочет заказчик — процесс это вскроет большим количеством переделок на следующих спринтах.

Но встречал я и такого рода высказывания: у нас скрам и 3 скрам-команды — бэк-енд разработчики, фронт-енд разработчики и тестировщики

Распространенная ошибка, да. Практически все скрам-мастера самоучки через это прошли. Прямо нарушается принцип, что команда должна быть способной выдавать законченный business value.

Вот этого личного опыта как раз в статье и не хватает — какие были проблемы, их причины, как второй удалось избежать.

Статей таких тысячи, полезность их примерно как у книги «Мой опыт воспитания ребенка», повторяться не хотелось. Не зря Scrum предпочитают называть framework'ом, а не методологией: принципы одни, а тонкий тюнинг у всех свой.
Цель данной статьи — подсветить моменты, специфичные именно для технического специалиста, поднявшего флаг внедрения скрама.
Не удивлюсь если его C# коллегам быстрее задать вопрос на SO и прочитать там его ответ, чем обращаться напрямую. :)
1

Информация

В рейтинге
Не участвует
Откуда
Зеленоград, Москва и Московская обл., Россия
Зарегистрирован
Активность