Agile *

Алёша играл в WoW годами. Игра мешала жизни, но бросить было невозможно: усилий воли оказалось недостаточно, а все попытки обмануть себя с помощью смены пароля и удаления аккаунта легко пресекались дружелюбной техподдержкой Blizzard.

Оказалось, что лучший способ бросить игру — продолжить играть в неё, но никогда больше не играть с одной и той же командой. Потому что весь кайф от игры — в сыгранной команде, которая умеет не только нужные кнопки нажимать, но и общаться между собой. Без умения постоянно обсуждать происходящее и согласовывать действия между собой выигрывать практически невозможно. А без побед пропадает удовольствие от игры.



Я работаю в команде YouGile — это таск трекер и корпоративный чат в одном продукте. В процессе работы мы рассмотрели множество систем и изучили кучу материалов про общение команд.

После ката — самые интересные выдержки, обзор систем для общения, сравнение подходов к обсуждению задач, а также попытка ответить на вопрос: “Какое общение делает команды сплоченней, а какое разваливает?”

Проходя собеседование на позицию Product Owner я понял, что у меня серьезный пробел по бизнес метрикам в Agile проекте, т.к. работаю в госструктуре. В русском сегменте информация достаточно скудная. В английском сегменте очень понравилась статья Ashwinee Kalkura. Поэтому решил сделать немного вольный перевод. Оригинал статьи здесь.

Что значат метрики для Agile команд?

Многие пытаются понять, что же такое «лучшая практика» в отрасли, и наложить её на свой продукт, чтобы улучшить свои собственные показатели. Некоторое время я размышлял над тем, существует ли такое универсальное и эффективное решение.

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

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

И как тогда понять, что именно нужно измерить? Для меня ближайший путеводитель — это 7-й принцип в Agile Manifesto — «работающее программное обеспечение — лучший измеритель прогресса». Если Вы можете определить, что является для Вас рабочим программным обеспечением, становится легче измерить прогресс.

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

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

Agile стал требовать от команды самостоятельного принятия решения, непрерывного улучшения. Тут мы и столкнулись с проблемой развития членов команд. В результате у нас постепенно появилось 14 способов развития, про 6 из которых расскажу в этой статье. Часть из этих способов инициировала компания, но большую часть мы придумали сами или подсмотрели и адаптировали под себя.

Всем привет! Самое время переходить на гибкую разработку. Наконец-то найден современный, последовательный подход к решению тех проблем, с которыми сражались целые поколения команд разработчиков. Гибкие команды используют простые понятные практики, эффективность которых в реальных проектах была неоднократно подтверждена. Но, погодите минутку… Если гибкие методологии так хороши, почему на них еще не перешли все без исключения? В реальном мире практика, хорошо работающая в одной команде, создает серьезные проблемы в другой; различия обусловлены образом мышления команд и их подходом к делу. Чтобы разобраться в этом придется погрузиться в гибкую разработку и поменять свое отношение к проектам!

Принципы DevOps плотно проникли в жизнь разработчиков, и, хотя разночтений в понятиях меньше не стало, сообществу нужно отдельное большое мероприятие для обмена опытом. Им станет конференция DevOpsConf Russia.

DevOpsConf Russia состоится 1 и 2 октября в Москве, соберет 500 специалистов и будет логически продолжать серию RootConf. Мы шли к этому перевоплощению несколько лет, и наконец готовы все рассказать.

В 2015 году в рамках фестиваля РИТ++ мы возродили конференцию RootConf, чтобы привлечь интерес к современным инструментам эксплуатации и подходам DevOps.

В первом выпуске видеоблога АйтиХайп мы пришли в гости в Додо Пиццу, где обсудили интеграцию IT и бизнеса, экстремальное программирование, Agile, удаленную работу, архитектуру их систем и особенности найма. Можно пройти под кат и почитать цитаты из интервью и немного истории, а можно сразу перейти к видео.

И снова здравствуйте!

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

Акт третий: “Головокружение от успехов или немецкий орднунг ч. 2”

Октябрь 2017

Итак, я снова вернулся на Кипр. Так как принципиальное согласие на оффер Компании №2 мною было дано, мы кратко обсудили потенциальные сроки моего выхода на работу (начало декабря), и я спокойно начал заниматься подготовкой оставшейся части документов на визу, в то время как компания должна была выслать мне подписанный контракт. Подаваться я планировался в посольстве Германии в Никосии, Кипр, поэтому список документов несколько отличался от того, который запрашивают в Москве или Санкт-Петербурге.

Всем привет!
Меня зовут Денис, мне 27 лет и я работаю Agile Coach в компании N26 (Берлин, Германия) — самом быстрорастущем мобильном банке в Европе.



Прежде чем переехать в Берлин в апреле 2018 года, я провел 9 месяцев в поисках подходящего места работы в Европе. За это время я успел:
— пройти порядка 20 интервью;
— дойти до финального этапа с 8 компаниями*;
— получить 3 оффера.

Для этого мне пришлось совершить порядка 18 перелетов и посетить 3 страны (Германия, Нидерланды, Австрия).

Рассказать о своём опыте меня сподвигло несколько факторов:
1) Высокий интерес к подобным материалам в IT-сообществе при практически полном отсутствии историй “тракторизма” от специалистов в области Agile на просторах сети;
2) Стремление поделиться с сообществом полученными инсайдами о том, как же выглядит «тот самый» Agile в Европе;
3) Желание зафиксировать все пережитое для себя лично, пока краски не потускнели и воспоминания еще живы.

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

Введение
Что такое DoR
Зачем нужен DoR
Где применять DoR
Когда применять DoR
INVEST модель
Заключение
Список литературы

Введение

Наверняка вы не раз слышали, скорее даже использовали с командой артефакт Scrum — Definition of Done далее по тексту — DoD. Возможно, используете его, даже не осознавая этого. О DoD написано много русскоязычных статей. О нём говорят на конференциях, и тренингах. Разобраться для чего нужен этот артефакт, и найти примеры не трудно. DoD определяет критерии, по которой каждый член команды понимает, что задача закрыта. Глубинная цель — синхронизировать понятие Done, между каждым членом команды. Над этими критериями, часто, команда трудится во время ретроспективы. Существует похожий артефакт, о котором почему-то нет упоминания в русскоязычных ресурсах о Scrum, а там где этот артефакт упоминается, не даётся никаких разъяснений что это, зачем нужен, и как использовать.

Скорее всего, в вашей команде звучали фразы наподобие: «Мы завалили цель, потому что неправильно оценили задачу», или «Наш PO опять пришёл с задачей без должного описания». В моей команде, подобные “сигналы” появлялись не один раз, и я долго искал способ, чтобы решить эту проблему.

Всем привет. Я работаю в московском офисе Технологического Центра Дойче Банка. Для тех, кто не знает, — мы занимаемся разработкой приложений для CIB (Corporate and Investment Banking) бизнеса в Нью-Йорке, Лондоне, Франкфурте, Токио, Сингапуре, Чикаго, Сиднее. В России в Техцентре работают более 1000 человек — это примерно 130 команд. Всего в мире таких центров у Дойче Банка четыре: в России (Москва и Санкт-Петербург), США, Румынии и Индии.



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

Фреймворк скрам постепенно осваивают все большие по масштабам команды. Такой опыт есть и у нашей компании. Совместно с 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 пионера.