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

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

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

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

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

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

Начальные условия

Наш эксперимент по ускорению работы программистов мы проводили в следующих условиях:

• это было территориально распределенное производственное предприятие;
• в эксперименте приняли участие 4 программиста 1С и я, их руководитель;
• мы – штатные программисты по поддержке комплекса конфигураций;
• нам стало скучно, и мы решили развиваться.

В первую очередь, желание развиваться возникло после того, как нам на глаза попалась книжка Джеффа Сазерленда про Scrum. Про эту методику вы уже наверняка много знаете, поэтому я на ней останавливаться не буду. Основная часть статьи будет не про Scrum.

Страшный сон команды разработчиков — это когда до начала разработки надо «нырнуть» в неизвестную предметную область и «проэстимейтить» half-baked idea. При этом нужно буквально «подписаться кровью» за результат в назначенный срок за фиксированные деньги.

На деле дать точную оценку неточных требований нереально. Типичный путь в проектном менеджменте — составить подробнейшее ТЗ перед началом разработки. А затем реализовать весь функционал одним большим куском. Но такой "вотерфольный" подход грозит уже другими рисками: запуском проекта в стиле «большого взрыва» — когда ты получаешь первый результат в самом конце проекта. И он может оказаться очень далек от реальных бизнес целей и нужд пользователей.

Зачем так рисковать, если можно пойти совершенно другим путем?

Зачем SCRUM

Когда при ознакомлении с проектом есть понимание «мы знаем, что мы этого не знаем» и даже «мы не знаем, где границы того, чего мы не знаем», выручает SCRUM



Специфика SCRUM может отпугнуть, если никогда не работал с этим фреймворком, тем, что на старте еще не известна длина пути, который предстоит пройти, чтобы получить работающий проект и удовлетворяющий на 100%.

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

Какая главная проблема в разработке программного обеспечения (а может и вообще в любой работе)? Когда я задавал вопрос коллегам, получал разные ответы: изменения требований, несоответствия ожиданий, качество кода, взаимодействие с другими командами… суммируя для себя — коммуникация является одной из самых важных проблем.

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

Пытаясь решать эту проблему, люди пишут детальное ТЗ. Но решает ли это проблему? Те же вопросы, как мне видится, задавали Боб Мартин и Мартин Фаулер вместе со своими коллегами, когда писали Agile Manifest в феврале 2001 года. Попробуем разобраться вместе в этом вопросе, да и в самом Agile манифесте.

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

Со всей страны собрались любители внедрить эджайл, а за ним канбан; они на кухнях обычно делятся сакральным знаньем по вечерам. Вы догадались уже, наверное, к чему до ката весь этот текст. В Яндекс.Деньгах провели «Пиэмную», где не осталось свободных мест.

Зачем быть продактом (или проджектом), секрет успеха крутых команд, о жизни бизнеса были очерки, и как разруливать местный ад — для тех, кто не был, всё-всё записано, там знаний с опытом прям гора. Включайте фоном, как в телевизоре.

Если в поисковике попытаться найти моббинг или 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 подсказок, которые помогут успешно выполнить миссию под кодовым названием «внедрение автоматизированной системы».

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

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

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