Agile *

— За что тебя приняли, за то и уволят. – тяжело вздохнув, сказал Боб. – Слышал такую фразу?

— Нет. – угрюмо ответил Джон.

— Ты помнишь, почему я взял тебя в тимлиды? – Боб отвернулся от Джона и уставился в окно.
Вид с двадцать пятого этажа открывался шикарный, но, похоже, Боб его не видел.

— У меня своя версия. – тихо сказал Джон. – Кажется, дело было в скраме.

— Да, дело было в скраме. – кивнул Боб, все еще глядя в окно. – И я, если честно, уже не могу про него слышать. Не хочу говорить высокопарных слов, но ты меня обманул.

— Я? – недоуменно спросил Джон.

— Ты и скрам. Твой скрам. Твоя инициатива. – Боб повернулся и в упор уставился на Джона. Которая будет стоит мне проекта. И кучи денег.

Сейчас, когда уровень понимания и применения Agile в России вырос, выросли и проблемы, с которыми сталкиваются все Agile энтузиасты при внедрении этой организационной культуры.

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

Пока Agile остаётся в рамках малых команд – всё просто. Поддерживать свободолюбивый дух стартапа или проекта в таком масштабе в принципе несложно, так как для маленькой команды он наиболее органичен. Но как только вы увеличиваете масштаб вы сталкиваетесь с необходимостью трансформации организационной культуры, а это уже сродни подвигам Геракла – эпическая задача.

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

Почему я решил написать эту статью

Очень часто в рабочей среде, на просторах интернета и на собеседованиях можно услышать, например, вот такое:

«С этим Скрамом столько встреч! Когда работать то?!»;
«Хорошо, пусть это будет хоть Скрам, хоть Срам, только отвалите и дайте мне писать код!»;
«У нас тоже этот Скрам навязали, вообще непонятно для чего»;
«Каждый день стендапы минут по сорок, нафига мне на них присутствовать? Хотите знать, что я сделал и над чем работаю сейчас — смотрите Jira, Confluence, Git и т.д.»
«Скрам-мастер вообще шут какой-то, ему бы всё хороводы водить, вместо управления проектом!»;
«Да, Скрам мы использовали: главное, что ретроспективы проводили».

Цель данной статьи показать, что тот негатив, который всё ещё большим потоком льётся в сторону Скрама, на самом деле к нему не относится, и проблему нужно искать в другом месте.

Далее я хотел бы рассказать о типичных случаях, откуда берут своё начало эти проблемы.

За последний месяц я провел 71 обучающий скайп-звонок с самыми разными компаниями. Задачей было внедрить разрабатываемую нами систему управления проектами. Запрос у всех согласившихся на такой формат примерно один и тот же — “Как втянуть команду в систему ведения проектом и в сам проект?”. Или проще говоря: “Как сделать так, чтобы все работали?”.

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



В этой статье — 10 ключевых рекомендаций по затягиванию команды в проект. Все высказанные ниже идеи подходят для работы в любой системе, но некоторые примеры приведены с интерфейсами нашего YouGile.

Важный факт — участники компаний после часового скайпа работали в нашей системе в 8.5 раз активнее в сравнении со средним пользователем. И в 2.3 раза активнее в сравнении с теми, кто согласился на скайп, но позднее отменил мероприятие.

В нашей жизни нет ничего более постоянного, чем изменения. В 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, удаленную работу, архитектуру их систем и особенности найма. Можно пройти под кат и почитать цитаты из интервью и немного истории, а можно сразу перейти к видео.