Agile *

Фреймворк скрам постепенно осваивают все большие по масштабам команды. Такой опыт есть и у нашей компании. Совместно с Unusual Concepts мы планируем поделиться своими наработками со всеми желающими в рамках дня Large-Scale Scrum — LeSS Day 2018, который пройдет 16 июля в офисе Comcity в Москве.

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

В рецензии книга Сэма Руби и др. в основном сравнивается с другой книгой по Rails (первой версии), статьей из английской Википедии, содержанием официального веб-сайта фреймворка, а также еще одной статьей, уже из русской Википедии.

Как следует из названия, это продолжение серии статей про роли в scrum (часть 1 и часть 2). Сегодня рассмотрим следующую роль – scrum master. Как это ни парадоксально, успешность scrum во многом зависит от scrum мастера. Поэтому хочется снова призвать силу воображения и привести метафору (дисклеймер: пример никоим образом не должен оскорбить чьих-либо чувств). Есть культура, у которой есть свой культ, свои обряды, есть служители этого культа. Служителей можно разделить на различные классы:

• те, кто со своей культурой предпочитают быть один на один — отшельники, затворники, просветленные;
• те, кто выучили все правила, нашли лазейки, понимают, что и как делать, и используют культ в корыстных целях, наживаясь на людях, их страхах и предубеждениях;
• фанатики, которые пытаются насадить свою культуру к месту и не к месту. Для которых кроме их знаний, всё остальное ересь;
• те, кто искренне верит, чувствует и пытается поделиться, помочь и подарить это чудо людям; они рассказывают и объясняют, слушают и пытаются помочь.

Со Scrum и SM-ами, мне кажется, происходит очень похожая история. Попробуйте посмотреть на знакомых вам SM через такую призму. С какими SM вам бы хотелось работать?

Давайте разберемся, какие тревожные симптомы могут быть у SM.

В первой части мы рассмотрели тревожные симптомы и возможные способы «лечения» Product Owner в «механическом» scrum. Продолжим разбор ролей и следующая на очереди – команда.
Все же знают мантру, что команда должна быть самоорганизованной и кросс-функциональной, это выглядит как самая простая часть scrum: берем людей с нужными компетенциями, говорим им: «вы команда», и полетели! Но на деле все несколько сложнее.

Я больше 10 лет работаю с / в / для agile в сфере web-разработки. Из них больше всего пришлось иметь дело с самым популярным agile фреймворком — scrum (по данным VersionOne). Хочу поделиться с вами накопленными наблюдениями и выводами.

Начну с метафоры, так как иногда приходилось видеть внедрение scrum по такому сценарию:

• До scrum: «разработка» как младенец — она целеустремленна, но не умеет нормально ходить, а очень хочет научиться, чтобы добираться до цели.
• Внедрение: приходит учитель (scrum тренинги, курсы, agile coach и т.п.) и показывает, как ходить. Малыш счастлив, он двигается шагами! Топ-топ-топ. У нас спринты — мы ходим!
• После внедрения: терпеливые стейкхолдеры говорят: «Окей, погнали к цели», на что получают «не давите на команду, мы ходим!». Разработка выписывает интересные траектории и получает удовольствие от процесса, но цель забыта.
• Scrum-но: дальше пилюля правды от бизнеса, scrum «мутирует» и позволяет бизнесу получать какой-никакой продукт от разработки. И, к сожалению, формально ставится галочка «мы работаем по scrum», а реальный потенциал команды разработки так и не раскрыт, да и кругом говорят «scrum ненастоящий».

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

Внимательный читатель листает ленту и задает вопрос: «Что, опять текст про agile?». Ага.

Эта статья — о процессах, технических аспектах и немного о том, как agile живет и внедряется в Яндекс.Деньгах. Если вы прошли хотя бы половину пути до настоящего agile, какие-то вещи могут показаться вам очевидными, и это нормально.

Под катом про тестовые стенды, запирание людей в переговорках и про то, как управлять отделом, когда все разбрелись по командам и наслаждаются жизнью.

А еще внимательный читатель спросит: «Почему „Темная сторона"? Тут что, про Дарта Вейдера?» Увы, нет, речь пойдет о темной стороне Луны, которая была неизвестна человечеству, пока туда не прилетел аппарат, чтобы сфотографировать и показать ее всем.

Когда внедряете agile, вы составляете проект освоения Луны, не зная,
что на другой стороне

Все начинается с попытки внедрить новые процессы разработки.

Мечты, мечты

Холодными осенними вечерами мы с разработчиками приложений 3D визуализации собирались на кухне… пили кофе… и думали о ней… об эталонной организации разработки.

— У меня знакомые по agile работают: спринты, стори поинты, все дела…
— Да нам бы хотя бы ревью…

Когда речь заходит о роли аналитика в IT, то всегда приходится добавлять кучу уточнений. Бизнес или системный аналитик? Анализ в продуктовой разработке или в проектной, как это, например, часто бывает в консалтинге? На внутренней разработке или на заказной?.. Заказчика государственного или негосударственного? И так далее.

До прихода в Туту.ру я работала в IT-консалтинге на ERP-проектах и в заказной продуктовой разработке, здесь же я занимаюсь системным анализом во внутреннем продукте «Авиа». Отдел системного анализа у нас состоит из 9 аналитиков и 1 технического писателя. Далее на своем опыте я расскажу, что меняется в голове специалиста и в рабочих процессах при смене формата деятельности на внутреннюю продуктовую разработку с точки зрения анализа, а заодно поделюсь, как устроен процесс в целом у нас в Туту.ру.

Отношение к конференциям в ИТ-среде неоднозначно: одни в кипящей атмосфере собраний чувствуют себя как рыба в воде, других скорее раздражает, поскольку ничего путного или нового для работы не услышишь.

И все же конференции – полезны, а участие в них позволяет обмениваться знаниями и узнавать, чем дышит и в какую сторону двигается отрасль. А если конференция проходит в другом городе или стране, это еще и прекрасный повод посмотреть мир. Главное, чтобы участие не превратилось в «академический туризм», спонсируемый работодателем.

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

Когда на предприятии затевается внедрение информационной системы, особенно силами внешнего подрядчика, то почти всегда говорится: самое большое препятствие – это люди. Сама система, кодирование нового функционала, обучение – это просто трудозатраты. А вот преодолеть саботаж внедрения, переломить мышление, особенно руководителей, заставить выйти из зоны комфорта старой системы (даже если она ужасна) – это действительно трудно. Причем, внедренцы обычно говорят: основная работа по «изменению людей» должна лежать и лежит на заказчике.

Реальную необходимость во внедрении системы оставим в стороне, она не является предметом обсуждения данного материала – считаем, что система действительно нужна. Внедрение идет по всем канонам, с техническим заданием, функциональными требованиями, планом-графиком и т.д. Ключевой критерий успешности проекта – реализация всех требований заказчика. Такой критерий вполне вписывается в методику оценки качества, которое есть степень соответствия требованиям потребителя. И вот система внедрена.

Ввиду блокировок телеграма, актуально было бы написать про Atlassian Stride, как мы на него перешли, и с какими прелестями решения от любимого Atlassian столкнулись.

Atlassian Stride был запущен в ноябре 2017, как замена облачному HipChat. Де-факто, основной конкурент, это, конечно же, Slack. Я постараюсь сравнивать Stride со Slack, и Telegram со стороны текстовой переписки.

Плюсы

Встраивание в Экосистему Atlassian, контроль за пользователями

Самый большой плюс, это, безусловно, бесшовная интеграция в экосистему Atlassian. Есть у вас jira, confluence — и единый аккаунт у пользователя, где вы можете управлять доступом к разным кускам и возможностям этих двух приложений. А теперь у вас есть третье приложение — Stride, и управление пользователями чатика доступно из той же админки.

Надежда Мецкер, Senior QA, DataArt

Я расскажу, как повысить эффективность команды в сложном проекте за счет гибкого подхода к разработке, с которым наша команда благополучно живет уже третий год. Собственно, реальный проект из области здравоохранения и будет служить мне примером. Я думаю, о теории Scrum и Agile рассуждать относительно легко, какие-то из использованных нами решений даже могут показаться очевидными. Но я уверена, что личный опыт и опробованные в ответственном проекте методы могут пригодиться многим.

Первое, о чем я расскажу, это Feature Demo — процесс, в ходе которого мы демонстрируем новый функционал приложения внутри своей же команды. Мы рассматриваем, как именно он был сделан, что получилось особенно удачно, а где можно было сделать лучше. Уже после общего рассмотрения и окончательного одобрения функционал может уходить в продакшн.

Под катом обзор и выводы с ретроспективы MeetUp-а про командную работу и рефлексию, который 3 апреля провела Елена Литвинова.

Для меня он стал демонстрацией как обычная команда (далее команда 1.0), отличается от подготовленной (команда 2.0).

Подготовленная означает, что большинство членов команды не просто знакомы с практиками и ценностями Agile, но владеют ими.

Всем привет!

Сегодня у нас на связи agile-коуч Василий Савунов. Немного поговорим об организации работы команды по системе Scrum, а также получим ценные рекомендации по обучению Scrum и Kanban.

Какой «золотой молоток» пытаются применить к разработке инновационных продуктов в российских крупных компаниях? В последние 5 лет на рынке существует тренд на внутреннее корпоративное предпринимательство (Inner Corporate Venture, далее ICV), и большинство крупных компаний бесстрашно начинают внедрять новые подходы к ведению бизнеса и создают специально для этого инновационные лаборатории, команды и подразделения. В обиход входят такие понятия как MVP (Minimum Viable Product — минимально жизнеспособный продукт), Lean Startup (бережливый стартап) и др.

Мы запускаем новое направление Университетов DataLine — семинары по поддержке интернет-проектов и взаимодействию разработки и эксплуатации.

Новым будет и формат — теперь мы будем вести онлайн-трансляции со всех наших семинаров!

Дата: 22 марта в Москве.
Тема: «Разработка vs Эксплуатация. Почему ни Agile, ни DevOps – это не волшебная пилюля, и как с этим жить.»
Ведущий курса: Алексей Приставко, директор по веб-проектам DataLine.

Осталось всего несколько мест, будем рады видеть ИТ-директоров, руководителей и инженеров команд разработки и эксплуатации, менеджеров и руководителей веб-проектов и всех тех, кто отвечает за производительность и работу крупных сайтов.

UPD от 18-08-2018: обновил и упростил текст статьи

Agile — это концепция управления проектами, которая базируется на гибкости и максимальной адптивности к изменениям. Можно сказать, что суть аджайла заключается в принципе «проверять и адаптироваться». Можно и нужно как можно чаще внедрять небольшие готовые вехи продукта, чтобы понимать, создается ли именно то, что нужно рынку и потребителю — вот к чему призывает аджайл. Аналитика рынка и потребностей потребителя проводится часто, чтобы подкорректировать планы по развитию проекта. Программисты пишут проект короткими итерациями, что позволяет владельцам бизнеса проверить «на бою» свои бизнес-идеи. Учитывая, что некоторые фичи были нужны еще вчера, а взятые на прошлой неделе требования уже устарели, то каждый участник проекта должен быть всегда готов к изменениям. Разработчики, как и владельцы продукта, в идеале понимают весь процесс поставки продукта потребителю и ту выгоду, которую он решает. Многие говорят, что аджайл работает, некоторые считают, что он собрал просто лучшие практики разработки ПО, не создав ничего нового, однако нельзя отрицать, что аджайл работает. Это доказывают истории компаний [1]

Всем привет!

Приближаемся к запуску нового нашего курса: «Автоматизатор в тестировании». Сегодня вот последний открытый урок, потом день открытых дверей и в бой.

На прошлых двух таких мероприятиях не раз задавался вопрос о связи Agile и автоматизации. Вот, нашёлся в закромах неплохой и не сильно большой материал, которым с вами и делимся.

Поехали.



Тестирование программного обеспечения, следующее принципам agile-разработки, называется Agile Тестированием (Agile Testing). Agile — итеративная методология разработки, при использовании которой требования развиваются в ходе сотрудничества между клиентом и самоорганизующимися командами и гибкого согласования с потребностями клиента.

Когда существуют варианты – важно не ошибиться и изучить все детали и возможности, чтобы остановиться на лучшем. Выбирать между методами управления разработкой не всегда просто, особенно если это Scrum и Kanban.