Agile *

В нашей жизни нет ничего более постоянного, чем изменения. В Mars IS инструментом регистрации и управления всеми изменениями в ИТ-инфраструктуре является программа «Управление изменениями и релизами» на платформе ServiceNow. В 2017 году успешно проведено около 12 тысяч полезных изменений с минимальными прерываниями в оказании ИТ-услуг бизнесу.

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

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

Спросите любую пару со стажем и они скажут, что конечно же важно делать другу другу романтические вечера и дарить цветы, но не все делают это регулярно и своевременно (давайте будем откровенны). И только 14 февраля все об этом вспоминают и волей не волей зажигаются свечи и достаются вазы. Так и с обратной связью, пока культуры давать ее регулярно и вовремя нет, нужны специальные дни недели, места, где люди могут дать друг другу эту самую обратную связь.

Вот такое мероприятие мы с командой и провели.

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

Нам пишут:
«Хм, а дайте плиз совет.

Реальный кейс, три разработчика, один разработчик работает 100% времени удаленно, второй разработчик — шеф/соучредитель, третий — немного офигевающий новоприбывший.

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

Есть ли способы как-то улучшить ситуацию?»

У нас юбилей — на хабраблог Яндекс.Денег подписалось 500 человек. В честь этого запускаем экспериментальную рубрику — берём вопрос одного из читателей, связанный с рабочей ситуацией, и бережно передаём его коллегам из Яндекс.Денег, которые знают жизнь. О сегодняшнем вопросе некоторые подумали, что я их разыгрываю и специально придумал такую странную ситуацию. Удивительно, но нет.

Привет. Меня зовут Сергей, последние пять лет я работаю в Яндексе. За это время участвовал в разработке одиннадцати проектов. Писал код на JavaScript, Python и C++. Некоторые проекты делал в одиночку, другие разрабатывал в группе из восьми человек. Но в каждой команде, на всех проектах, вне зависимости от языка программирования я использовал код-ревью.

С помощью код-ревью я постоянно узнаю что-то новое. Иногда, глядя на чужой код, хочется воскликнуть: "А что, так тоже можно?". В чужом коде я нахожу интересные приёмы и беру их себе на вооружение. Много новых знаний черпаю из комментариев к моему коду. Для меня стало открытием, что люди любят делиться своим опытом. Даже когда я разрабатываю проект в одиночку, то прошу ребят из другой команды посмотреть мои пулреквесты. Это мотивирует писать красивый и понятный код.

Но так было не всегда. Когда-то ревью было для меня наказанием. Я мог неделю с вдохновением писать код, вкладывая в него все силы. Отправлял пулреквест, трижды пинговал ревьювера, а в ответ получал сухое "вроде ок" или, что ещё хуже, десятки комментариев не по существу.

Мне на ревью приходили пулы из пяти тысяч строк. Я часами пытался разобраться в коде, по сотне раз скроллил от функции к тесту и обратно. Писал десятки бесполезных комментариев о пропущенной точке с запятой. Всё это жутко меня раздражало. Часто откладывал ревью на потом, и у меня накапливались десятки непросмотренных пулов.

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

В век просвещённого аджайла негоже уже даже употреблять такие слова, как «график проекта». И хотя многие проджект менеджеры могут высоко поднять бровь, я всё-таки скажу:
График проекта не нужен, вреден, опасен и чреват!

А теперь, сделав, такое эпатажное заявление, я постараюсь объясниться и доказать вам, что все графики проекта должны быть заменены на бэклоги везде, где это возможно, а возможно это везде.

Какой вообще смысл в этих ретроспективах?

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

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

Это просто.

Смысл работы скрам-мастера (или Agile-коуча) в создании и развитии эффективной команды. Причем основным развиваемым качеством команды должна быть самоорганизация.
По сути для проведения успешных ретроспектив вы как скрам-мастер должны знать две вещи:

В репрессивной модели управления лидер будет, как правило, подбирать сотрудников либо глупее себя, либо таких, которых он может «загипнотизировать» или шантажировать тем или иным образом. Тут ищут «псов», которыми легко управлять и которыми легко травить. Спускаемые сверху идиотские указания будут без изменений проксироваться вниз и те, кто сможет проксировать их ниже — выживают, остальные лопаются. habr.com/post/124716

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

Конфликты интересов частая ситуация в рабочих коллективах и не только в программистских. И зачастую нет правых и виноватых, есть столкновение опыта и видений. Как раскрыть потенциал всех сотрудников и получить синергию, когда 1+1 = 11, а не 2.

Навеяло после футбольного чемпионата мира по футболу. История вывода на колею скрама. Все события вымышлены, все совпадения случайны. Обобщенная и сильно упрощенная ситуация.

Как перестать ловить яйца в спешке, попутно роняя дедлайны? Какой тулчейн выбрать, чтоб уничтожать по несколько тасков за раз? Все это раскроем в нашей статье.

Привет, Хабр! Меня зовут Максим Лютцау, в Промсвязьбанке я работаю product owner’ом. Почти год разработка нового интернет-банка «Мой бизнес» у нас идет по фреймворку Scrum, и в связи с этим я уже успел набить шишек. В этом посте я хотел бы рассказать о самых болезненных из них, а также о том, какие средства нам в итоге помогли. Чтобы вы смогли избежать подобных неприятностей.

Алёша играл в 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 команд. Всего в мире таких центров у Дойче Банка четыре: в России (Москва и Санкт-Петербург), США, Румынии и Индии.



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