Если в поисковике попытаться найти моббинг или Mobbing, то значительная часть результатов будет про «психологическое насилие над людьми». Потому лучше сразу искать «mob programming». В топ-10 результатов Яндекса на данный момент (27.02.2019) есть лишь одна статья на русском языке (и та — перевод), но много статей на английском. Если посмотреть их бегло, то большинство из них — теория, а не разбор какого-либо практического кейса. Все говорят, что он поможет команде стать эффективнее, локально распространить экспертизу по проекту, и развить в людях soft skills. Я и сам опробовал моббинг на практике во время одного из скрам-тренингов, и был, честно говоря, в восторге! Посоветовавшись с командой, мы решили провести свою тестовую сессию моббинга.

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

Я, как и некоторые другие программисты, не большой любитель митингов. Порой, надоедают все эти sprint refinement, sprint review, retrospective сессии.


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

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

Регулярные ретроспективы вызывающие изменения снизу — важнейший признак организовавшейся живой команды.

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

Для проведения ретроспективы желателен опытный фасилитатор. Особенно это важно в стартующих командах.

Если вы такой человек и хотите углубить ретро, в статье вы найдете советы и оригинальный взляд на эту встречу с т.ч. работы мозга и цели стимуляции личностного роста участников.

Цель

Распространено мнение, что цель ретроспективы — улучшить работу. Это упускает ключевую деталь — самостоятельность. Считаю, цель ретроспективы — чтобы команда сама улучшила свою работу.

А значит цель — изменение людей. Т.е. ретроспектива, это чуть-чуть психотерапия. Нужно создать новые привычки, изменить взгляд на что-то, продать всем изменения, а не просто придумать новые инструкции.

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

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

У онлайн-платформы разработки Eclipse Che выдался отличный год. В начале 2018 года была выпущена Eclipse Che 6.0, которая получила ряд новых функций для команд разработчиков, заинтересованных в создании cloud-native applications, а на конференции CheConf 18.1 было анонсировано начало следующего этапа в развитии – Eclipse Che 7.



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

Все, кто хоть немного знаком со Scrum, наверняка знают три его коротких характеристики:

• компактный;
• простой для понимания;
• трудный для освоения в совершенстве.

Работая Scrum Мастером в Hubber, я постоянно открываю для себя новые грани последней характеристики.

Хабр, привет! Меня зовут Антон, я руководитель YouGile (система управления проектами). Самое полезное, что я делаю в компании — это общаюсь с клиентами на тему того, как вести проекты и как связывать отделы в системе управления.

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

Две хорошие практики планирования на год на Agile-доске в небольшой команде:

— Что для тебя Программирование?
> Программирование? Я не могу ответить.
— Почему?
> Даже не знаю…
— Ты учился когда-нибудь?
> Конечно, но это было давно.
— Работу по найму Любишь?
> Сейчас уже нет.
— Зачем ты стал Предпринимателем, и неужели ты проработал более 17 лет «программистом» и «аналитиком» в ИТ-компаниях?


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

---

С завтрашнего дня начинаем жить по-новому. Будет у нас Скрам и будет счастье. Полная демократия: никаких начальников, команда сама решает, что ей делать, бюрократия отменяется, главное – сделать заказчику хорошо.

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

Ну-ну. Поживём-увидим.

---

Начинаем новый проект. Ну, слава богу!

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

Эджайл то, эджайл сё. Про эджайл сейчас не говорит только ленивый. Да и ленивый говорит. Все говорят. Из каждого утюга, даже выключенного из сети, топят за эджайл. Такое ощущение, что просто эпидемия какая-то разразилась. И не подумайте, что я только про ИТ. Коучи учат неофитов проводить стендапы с ретроспективами и жить по спринтам в любых бизнес-сферах: от булочных до парикмахерских. А некоторые менеджеры, наслушавшись коучей, так увлекаются, что забывают о природе данного явления, заставляя внедрять гибкие методологии негибкими методами: «Так, с завтрашнего дня мы все становимся гибкими. Что за «хихи»? Гибкими я сказал, а то всех нагну!». Так в чем же природа эджайл, на чем он зиждется?

Привет, Хабр! Меня зовут Женя. Я системный аналитик компании «НОРБИТ» и начинающий Scrum-мастер. Я давно присматривалась к Scrum с целью изучить, попробовать и оценить его возможности в нашей команде аналитиков. И вот, после легкого пинка воодушевляющего разговора с РП я поняла: хватит думать, пора делать.

В этой статье я расскажу о нашем опыте подготовки к использованию ограниченного Scrum от лица Scrum-мастера: что мы сделали, чтобы запуститься. На момент написания статьи завершен 15-й спринт. Полет нормальный!

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

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



Как раз об этом расшифровка доклада Евгения Федореева на TeamLead Conf. В докладе Евгений поэтапно описал процесс организации эффективной команды разработки в Banki.ru: про найм, общение, обмен знаниями и развитие разработчиков и тестировщиков внутри коллектива и отдела.


О спикере: Евгений Федореев (hardj) занимается веб-разработкой 15 лет, их них 6 — в позиции тимлида, а сейчас руководит направлением разработки новых проектов Banki.ru.

От переводчика: это инструкция DIB Guide: Detecting Agile BS (версия 0.4), которую Комитет по инновациям Министерства обороны США (DIB) опубликовал в открытом доступе 9 октября 2018 года.

Agile — модное словечко в разработке ПО, так что все софтверные проекты Минобороны теперь почти по умолчанию объявлены «гибкими». Настоящий документ поможет руководителям программ и специалистам Минобороны отличить софтверные проекты с действительно гибкой методологией от проектов, которые под маской Agile просто используют «водопад» или «спираль» (“agile-scrum-fall”).

Иногда так не хватает подсказок по ходу выполнения миссии ИТ-проекта – «жми W, чтобы двигаться вперёд». Чтобы хоть как-то помочь тем, кто оказался на месте функционального заказчика (от него очень многое зависит на проекте), мы собрали топ-10 подсказок, которые помогут успешно выполнить миссию под кодовым названием «внедрение автоматизированной системы».

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

По-моему мнению в статье “Боссы-кровососы в контексте …” не была раскрыта причина распада самоуправляемых команд, а причина именно в низкой скорости распространения требований к продукту, и непонимании того, что руководитель всегда является частью команды.

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

I Вступление

Будку надо переносить! Сезона не бывает, чтоб пару-тройку не шандарахнуло.
То с туалетом путают, то с пляжной кабинкой…
(х/ф Особенности национальной рыбалки)

Конец года, подведение итогов, заполнение анкет и прочая предпраздничная мишура ИТ функционеров. Мне уже в который раз попадается на глаза итоговые опросники ИТ фирм, призванные выявить тренды в подходах к разработке продуктов. И каждый раз возникает ощущение какого-то подвоха, когда отвечаешь на вопросы типа: «Вы все еще пользуетесь методом Waterfall (водопадная модель), или Вы все-таки (как и все передовое человечество) практикуете Agile (гибкие методологии)». Когда же начинаешь выяснять у автора сего опроса, а что он понимает под Agile, его разъяснения как-то не сильно ложатся в канву манифеста (Agile Manifesto). О многих принципах он реально задумываются впервые и эти самые принципы прямо-таки ставят его в тупик. Но после небольшого замешательства, в ход идет тяжелая артиллерия с железобетонным обоснованием своей позиции: «Мы же не по Водопаду работаем, значит по Agile».

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

Давайте вместе, еще раз “ударим анализом” по теме Гибких методологий, попытаемся разложить основные артефакты и принципы по полочкам и отделить, тот сакральный смысл, который закладывали в это понятие изначально, от того, во что его превращают отдельные нерадивые популисты. Так же сравним подходы Agile с другими методиками для более точного понимания той грани, что их разделяет или наоборот – объединяет. Заодно попробуем выяснить, где использование принципов Agile наиболее целесообразно, а где не совсем уместно?

Что такое SAFe?

Что такое Agile многие знают. Еще большее количество людей, причастных к IT используют терминологию. Еще больше тех, кто слышал об Agile.

Далеко не все, кто уверенно использует термин Agile для общения, критики, для того; чтобы представить свою комманду или компанию в лучшем свете понимают, например, в чем отличие между SCRUM и Agile; и часто ставят между этими двумя разными понятиями знак равенства. Но вот не так давно в 2015 году появился еще и SAFe. Что это и зачем он нужен?

Приглашаем на Рождественский Scrum Meetup, который состоится 20 декабря на площадке Райффайзенбанка в Нагатино.

Мы в Промсвязьбанке активно переходим от вотерфол-канальных команд к эджайл-продуктовым. Где-то обошлось парой шишек, где-то уже можно менять грабли… но в результате мы накопили немало опыта, связанного c эджайл-трансформацией. В этом посте мы хотим поделиться опытом — вдруг вы откроете для себя что-нибудь новое.

Всем добрый день!

До конца года осталось уже почти всего ничего, но всё же несколько новинок в курсах у нас будет. Один из таких новый курсов — «Agile Delivery Manager», который создала Марина Арефьева. По традиции подготовили для вас открытые уроки и интересные материалы. Сегодня познакомимся о виденье, что же такое Delivert Manager и с чем его едят.

Поехали.

Рич Льюис (Rich Lewis) — лучший, с кем я когда-либо работал. Когда я только встретил его, он был бизнес аналитиком и скрам-мастером небольшой команды. Он справлялся со своей работой, но явно был способен на большее. Я предложил ему должность Delivery Manager в программе, которой занимался в то время.

О роли Delivery Manager мы говорим не часто. Конечно, это не часть “семьи” Agile, где доминирует терминология Scrum. Владелец Продукта; Скрам-мастер; Все остальные с ярлыком “Разработчик”. Вот, пожалуй, и все.

Тем не менее, название должности — Delivery Manager, существует. Например, в The Government Digital Service (GDS) в Великобритании и все большем количестве компаний в США.

Продолжаем про нюансы гибкой разработки (Agile), которые случаются на практике. Как понять, правильно ли внедрен Agile, какая практика годится для какой задачи и отрасли, кто в компании должен переводить работу на «Agile-рельсы»? Своим опытом с редакцией блога Mail.Ru Cloud Solutions продолжает делиться Agile-коуч ScrumTrek Василий Савунов.

В прошлый раз Василий рассказал, что такое Agile, какие он включает методологии и какие вокруг него сформировались стереотипы. Теперь поговорим о его внедрении.