Agile

Кого вы пытаетесь впечатлить своими дедлайнами?

Перевод

Подсказка: явно не ваших пользователей.
Поднимите руку те, чья компания провозгласила «Клиентоориентированность» как одну из своих корпоративных ценностей. Для тех из вас, кто читает этот текст на Хабре и не видит аудиторию: почти весь зал поднял руку, кроме пары человек сзади.
Они работают в Oracle.
Удовлетворенность клиентов является одной из корпоративных ценностей компании Oracle. Но корпоративные ценности — они как абонемент в спортзал — недостаточно их просто иметь.
Одержимость клиентами — полезная вещь, но есть ещё одна вещь, которой одержимы многие компании — это сроки. Дедлайны — это хорошо. «Будет готово, когда я закончу» может быть отличной (или даже рекомендованной) стратегией для двух человек работающих над одним приложением. Но когда вы работаете в компании с более чем двумя сотнями сотрудников, вам требуется некоторое понимание того, что происходит; примерное представление о том, когда ваши пользователи смогут использовать ваши новые свистелки и перделки.
Смею утверждать, что жестко установленные сроки — это плохие сроки, и если у вашей компании такие есть, возможно следует пойти еще дальше, и убрать пункт об «клиентоориентированности» из списка корпоративных ценностей. Потому что, хотите верьте, хотите нет, пользователям плевать на заваленные спринты.
Дедлайны нужны в первую очередь не клиентам, а менеджменту.

История зарождения Agile

Изначально термин Agile относился к ИТ-индустрии и употреблялся в контексте гибких методологий разработки программного обеспечения: экстремального программирования (XP), Crystal Clear, DSDM, Feature driven development (FDD), Scrum, Adaptive software development, Pragmatic Programming, быстрая разработка приложений (RAD) и других адаптивных методов, суть которых состоит в ускорении процессов создания продукта путем микропланирования, коротких производственных циклов и оперативного реагирования на изменения. Ключевой смысл этих Agile-практик отражен в манифесте гибкой разработки программного обеспечения (Agile Manifesto), который был выпущен инициативной группой программистов в феврале 2001 года в американском штате Юта . Эта дата считается началом повсеместного распространения эджайл как практики управления проектами и организации бизнес-процессов не только в ИТ-отрасли, но и в других прикладных областях. Дополнительным драйвером развития Agile-подходов является микросервисная архитектура приложений, когда весь проект состоит из набора независимых слабосвязанных модулей, которые взаимодействуют друг с другом через открытые API-интерфейсы . Популярность облачных технологий (SaaS-, PaaS-, IaaS- и других сервисных моделей) также стимулирует распространение эджайл.

Редизайн приложения — взгляд изнутри

Из песочницы

Mobius bike — это сервис по прокату велосипедов и самокатов, разработанный для Таллина (на данный момент запланировано расширение географии). Ключевые экраны приложения Mobius bike до редизайна
Одной из первых моих задач в качестве продуктового дизайнера, была подготовка макетов для внедрения нового вида транспорта — электросамокатов. Закончив с макетами, я решил внести некоторые изменения в дизайн и UX приложения и сделать небольшой концепт редизайна. Показал новые макеты команде. Получил фидбэк: ребята давали советы и делились своим мнением. В итоге набралось некоторое количество ключевых экранов.

Сравнение сертификаций по Agile, часть 1 — ICAgile, Scrum.org, ScrumAlliance и PMI

Некоторое время назад, я перешел из компании, которая жила в мире жесткого Waterfall и суровых планов в MS Project на несколько тысяч строк, в компанию, которая живет в мире Agile — ценности, которую несут продукты уделяется больше внимания чем следованию плану, фокус в разработке сделан на скорость и качество, разработка здесь идет итеративно, для помощи командам есть коучи и скрам-мастера, MS Project используется крайне редко, а про Oracle Primavera никто и не слышал.
Не то что бы для меня это было в новинку, я и раньше работал в компании, которая активно использовала лучшие практики из Scrum и XP, но на таком высоком уровне опыта у меня не было. Тогда я задумался о том, как бы мне прокачаться в гибких методологиях, а также, как понять насколько ты прокачан? После беглого изучения вопроса, я и узнал о том, что в мире Agile, кроме специализированных курсов существуют еще и сертификации — компании, которые задают тренд на рынке, проводят специальные обучение и тесты, по результатам которых можно примерно сказать, какая квалификация есть (или нет) у того или иного специалиста.

Как мы делали SCRUM

Страшный сон команды разработчиков — это когда до начала разработки надо «нырнуть» в неизвестную предметную область и «проэстимейтить» half-baked idea. При этом нужно буквально «подписаться кровью» за результат в назначенный срок за фиксированные деньги.
На деле дать точную оценку неточных требований нереально. Типичный путь в проектном менеджменте — составить подробнейшее ТЗ перед началом разработки. А затем реализовать весь функционал одним большим куском. Но такой «вотерфольный» подход грозит уже другими рисками: запуском проекта в стиле «большого взрыва» — когда ты получаешь первый результат в самом конце проекта. И он может оказаться очень далек от реальных бизнес целей и нужд пользователей.
Зачем так рисковать, если можно пойти совершенно другим путем?

Зачем SCRUM

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

Как внедрить Agile?

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

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

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

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

Если вам удастся справиться, процессы станут заметно эффективнее, а качество работы — выше. Главное, никогда не забывайте четыре основных ценности Agile, с которых начинается «Манифест гибкой разработки»:

Agile

Следование им и поможет на этапе внедрения, и будет подспорьем в процессе работы.

Лучше познакомиться с Agile и другими современными методологиями, применяемыми от IT до медиа и маркетинга, а также погрузиться в построенные на их основе процессы, вы сможете, пройдя курс «Управление digital-проектами» от Skillbox.

Курс «Управление Digital-проектами»

Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.

  • Живая обратная связь с преподавателями
  • Неограниченный доступ к материалам курса
  • Стажировка в компаниях-партнёрах
  • Дипломный проект от реального заказчика
  • Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Один в поле не воин. Путь до эффективной командной работы

Команда — это группа людей, которые вместе двигаются к общей цели, распределяют между собой задачи и ответственность за конкретный результат. Команды создаются, чтобы решать задачи, которые один человек выполнить не сможет. Эффективная команда достигает цели за минимальный срок с минимальными затратами.
Собрать несколько человек и сказать: «Теперь вы команда, ждем от вас результата», не получится. Людей нужно организовать, дать им вменяемую цель, мотивацию и решать возникающие проблемы.
Как раз об этом расшифровка доклада Евгения Федореева на TeamLead Conf. В докладе Евгений поэтапно описал процесс организации эффективной команды разработки в Banki.ru: про найм, общение, обмен знаниями и развитие разработчиков и тестировщиков внутри коллектива и отдела.

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

Деньги решают. «У нас три разработчика, но мы не умеем работать»

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

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

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

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

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

Дневник разработчика или Плохие решения

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

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

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

Удалённая работа 2.0. Надежда Юринова, директор по маркетингу Bookmate

Многие мечтают о хорошей работе из дома, будь то фриланс, удалённое место работы или что-то иное, порою даже гибридное. Однако, далеко не все представляют себе все сложности, возникающие в подобном режиме, равно как и склонны идеализировать потенциальные преимущества.
Жизнь, как это часто бывает, расставляет реальные ориентиры где-то между и, для того, чтобы не вести гипотетические рассуждения, я стал искать человека, обладающего подобным опытом, чтобы узнать обо всех особенностях удалённой работы из первых уст.
И такой человек нашёлся — это Надежда Юринова, директор по маркетингу в компании Bookmate. Надежда, как многие из нас, долго время работа в Москве, но в какой-то момент собственной жизни решила переехать в Берлин не меняя место работы.
О работе на новом месте, удалённом от старого на, примерно, 1800 километров мы и пообщались.Спойлер: в конце публикации всех дочитавших ждёт небольшой сюрприз.Первый вопрос – достаточно простой: почему ты начала работать удаленно?
Так получилось потому, что я хотела пожить в другом городе, и им стал Берлин. Я не ожидала, что мою роль можно полноценно исполнять вне офиса. Потому что директор по маркетингу – это не только стратег, но и team lead, который подбирает самых лучших ребят, объединяет их друг с другом, запускает процессы, чтобы они вместе системно работали и время от времени что-то им подкидывает и где-то их контролирует. Конечно же, это проще делать, когда ты с ними находишься рядом.

Как сделать курс по Аджайл на принципах Аджайл

Во вторник, 28 апреля мы провели первый ознакомительный вебинар Вечерней школы Слёрма по Аджайл. Зарегистрировалось на курс 1700 человек. Курс открытый и полностью бесплатный — мы приняли решение помочь управленцам, владельцам бизнеса и скрам-мастерам в это непростое время.

Мы сделали то, что никогда ещё не пробовали. У нас получилось создать курс за 1 неделю — придумать идею, проверить гипотезу, найти ценность для участников, подготовить программу, улучшить её несколько раз, выбрать аппаратуру и инструменты для удобной трансляции и тесного взаимодействия с участниками. Всё же Аджайл в первую очередь — это командная работа, даже если все сидят в самоизоляции.

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

На первом вебинаре мы разбирали преимущества Аджайл во время кризиса. Преподаватели показали на примерах российских и зарубежных компаний, как Аджайл может помочь в ситуации неопределённости и экономической рецессии — и поделились практическим опытом и советами.

Изменение требований к проекту — ключевая проблема разработки ПО

Перевод

Шаги по разработке большой компьютерной программы для доставки заказчику
Иллюстрация выше — из статьи д-ра Уинстона Ройса «Управление разработкой больших программных систем» 1970 года. Считается, что это первое в программной инженерии описание модели водопада. Диаграммы д-ра Ройса разошлись по сотням учебников и статей. Но часто забывают тот факт, что изобретатель водопада сразу написал: «Эта конкретная реализация рискованна и влечёт за собой неудачу».
Мы разрабатываем программное обеспечение, чтобы удовлетворить потребности какого-либо клиента, пользователя или рынка. Задача программной инженерии как области компьютерных наук — сделать эту разработку предсказуемой и экономически эффективной.
Прошло уже более 50-ти лет с момента проведения первой конференции IFIP по программной инженерии, и за это время предложено немало различных методик, процессов и моделей, призванных помочь разработчикам достичь этого предсказуемого и экономически эффективного процесса. Но и через полвека у нас те же проблемы, что и всегда: опоздания, неудовлетворительные результаты и полные провалы проектов.

Райффайзенбанк начинает второй набор в Java-школу

Скрам, смузи, эджайл, блокчейн, биг дата, «в каком отделении карту оформляли, туда и идите». Ну, в общем, все мы слышали, что сейчас в тренде в банковской сфере.
Где можно в это втянуться и набрать критическую массу знаний молодому разработчику? В Java-школе Райффайзенбанка: здесь быстро всему научат, расскажут, покажут, да ещё и заплатят.
Что из себя представляет наша Java-школа? Это трехмесячная оплачиваемая стажировка в одном из крупнейших банков России для студентов последних курсов бакалавриата и магистров. В короткие сроки вы научитесь работать в команде по методологии SCRUM, получите/отточите свои навыки в Enterprise девелопменте, повысите ораторские способности, споткнетесь обо все подводные камни командной работы над одним проектом с применением систем контроля версий и поспорите с командой, что же лучше, GIT или Subversion.

Далее — рассказ очевидца. Из первых, так сказать, рук.

Проектные технологии при внедрении биллинговых систем у корпоративных клиентов (часть 2)

Работаем с рисками на глобальном уровне

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

Aнглийский для демо (структура, фразы, Q&A, грамматика, советы)

Демо в конце спринта (будь то внутреннее, заказчику или крупному клиенту) — это настоящая проверка знания английского для не носителя языка, так как эта небольшая презентация показывает:

  • беглость речи (fluency)
  • точность (accuracy) — много или немного ошибок в речи в целом
  • спонтанность языка (особенно, когда задают вопросы)
  • произношение
  • владение грамматикой
  • богатство или бедность лексики
  • насколько правильно человек умеет составлять предложения (структуры русского и английского предложения отличаются)
  • умение структурировать речь с помощью связующих слов (linking devices: e.g. firstly, secondly, finally, in addition, what concerns, etc.).

Похороны скрам-доски

— Ты служила нам верой и правдой. – грустно и торжественно произнес Джон, стоя рядом со скрам-доской. – Но мы не в силах больше сохранять тебе жизнь. Прости.
— Джонни, ты чего? – весело спросила Ребекка.
— Сегодня скорбный и торжественный день. – обернулся к веселой, молодой, хоть и малоопытной девушке-программисту Джон. – Подойти, сестра!
Ребекка встала со стула, и вприпрыжку кинулась к Джону.
— Сделай грустное лицо. – строго сказал Джон. – Ну, давай.
Ребекка, как могла, изобразила грусть. Хватило ее на пару секунд – не тот характер, чтобы долго пребывать в плохом настроении – и снова улыбнулась.
— Что происходит, Джон? – спросила она.
— Все. Конец. И мне, и скрам-доске. – серьезно ответил командир.

Основные заблуждения о SCRUM

Из песочницы

SCRUM? Какой SCRUM?

Впервые подход SCRUM (англ. scrum «схватка вокруг мяча») описали Хиротака Такэути и Икудзиро Нонака, которые заметили, что небольшие команды (5 — 9 человек), укомплектованные разнопрофильными специалистами, дают лучшие результаты. Наиболее полное описание SCRUM впервые представил в своей книге Джефф Сазерланд. Книга так и называется — SCRUM. Джефф начинал свою карьеру как военный летчик, во время войны во Вьетнаме выполнивший более ста боевых вылетов. Затем Джефф занимался наукой, но мир его запомнит как одного из родоначальников SCRUM. Книга начинается с реальной истории из жизни ФБР, тратившего миллионы долларов на разработку автоматизированной системы, предназначенной для поиска и отслеживания преступников. Проблема заключалась в том, что по истечении сроков проекта подрядчики демонстрировали ФБР абсолютно нерабочий продукт. Это означало лишь одно — американские налогоплательщики потратили миллионы впустую. Ситуация казалась безвыходной до тех пор, пока руководство ФБР не обратилось к тогда еще зарождавшемуся методу управления проектами SCRUM. Этот метод описан доступным языком в вышеупомянутой книге, которая, кстати, переведена на русский язык. Далее в статье рассмотрены основные заблуждения и мифы, которые могут отпугнуть топ менеджеров, задумавших внедрить SCRUM в свои проекты.

Мотивация каратистов: как перестать беспокоиться о неэффективных сотрудниках?

  • Tutorial

Я уже давно хочу поделиться уникальной мотивацией для разработчиков, которую создал и внедрил. Постараюсь рассказать без воды, кратко и по делу.
Данная мотивация позволит не заставлять сотрудников работать, если они этого не хотят. А так же быстро выявить неэффективных сотрудников, которые тянут команду к дну.
Наша команда работает in-house в Москве и Воронеже и удалено по разным городам России. Эта мотивация применима для всех, кто работает в компании full-time, в независимости от местонахождения. Отдельно хочу отметить высокую эффективность в случае работы с удаленными сотрудниками.
На текущий момент, в компании работает больше 10 разработчиков. У нас 10 купонных сервисов, 2 мобильных приложения, агрегатор kupon.ru, ERP-система, рассыльщик, который рассылает более 8 миллионов писем в день, и, совместный проект, аналитический сервис gtmix.ru. Каждый разработчик участвует в 2 и более проектах. Работает it-отдел по SCRUM в Trello. Ежедневные митинги разделены по проектам и проходят в точно назначенное время.
Эффективность разработчика измеряется в баллах. Для удобства сбора результатов, мы используем плагин для trello: Scrum for Trello. Балл формируется из коэффициента скорости команды и времени, затраченного на задачу. Есть простая, наглядная табличка:

Из практического опыта, оптимальный коэффициент скорости команды составляет 1,6. Чтобы вы понимали, это 5 часов работы сотрудника в день или 1 балл. 1 человек/час — это время потраченное на написание кода и обмозгование задачи. Время затраченное на чтение книг, кофе, чай и тому подобное не считается.

Как вызвать перемены при помощи ретроспективы

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

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

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

Для проведения ретроспективы желателен опытный фасилитатор

Особенно это важно в стартующих командах

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

Цель

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

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

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

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

О компаниях, использующих Agile

— Есть ли «отраслевые предпочтения» в гибких методологиях? исследование Agile Russia

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

Методики гибкой разработки, принятые в разных отраслях. Суммы не равны 100 %, потому что можно было выбирать более одного пункта. Изображение/ScrumTrek— А как дела у мобильных разработчиков? Есть ли у Agile специфика в мобильной разработке? SLeSS Lean Six Sigma— Насколько гибкие методологии поддаются модификации под частные условия?— Какие типичные ошибки при адаптации Scrum совершает бизнес?может работать

  • Проектного менеджера хоть и окрестили Владельцем Продукта, однако он не получил необходимых полномочий и поэтому не вправе формировать видение продукта или менять приоритеты реализации. Как и раньше, он вынужден согласовывать каждый свой шаг с руководством и зажат в рамки требований по срокам и объёму работ. А значит, скорость принятия решений осталась прежней. Никакого ускорения или адаптации под меняющиеся условия.
  • Проектную команду хоть и назвали Scrum-командой, но люди, включённые в неё, по-прежнему могут числиться каждый в своём отделе и подчиняются непосредственно своим линейным руководителям. Соответственно, каждый из участников команды прежде всего делает то, что ему поручит его линейный руководитель, а не Владелец Продукта. Как следствие, задачи по продукту будут всегда ниже по приоритету, а значит, скорость реализации продукта, под который «собрали» Scrum-команду, никак не повысится.
  • Скорее всего, как и прежде, участники команды будут заняты и в других проектах. В то время как Scrum прямо оговаривает: участники команды должны быть выделены в Scrum-команду на 100 % своего рабочего времени, и заниматься только тем продуктом, которые ведет их Владелец Продукта. Если люди «поделены на проценты» между проектами/продуктами, то они будут переключаться между ними, что резко снизит как вовлеченность, так и эффективность работы над каждым конкретным проектом/продуктом.

Стоп-сигналы для Agile— Как оценить, насколько грамотно гибкие методологии внедрены в компании? Scrum Open опросы 360 ScrumTrek Diagnostic ToolРадар ScrumTrek. Смотрим на разброс оценок
Радар ScrumTrek. Смотрим на медианы

  • Атомарные оценки отдельных людей и их средние интересны сами по себе, тут пояснения не нужны.
  • Разброс оценок в команде — интересная вещь. Когда он очень большой, есть повод договориться о том, что мы как команда подразумеваем под тем или иным аспектом нашей работы. Что мы имеем в виду под «ценностью для клиента», например? А «скорость поставки»? Большой разброс свидетельствует о том, что в команде не сформирована единая позиция по ряду вопросов.
  • Оценки разбиты по категориям. Можно заметить, что с культурой всё хорошо, а вот производительность кое-где проседает. Понятно, куда «копать».
  • Отличие между оценкой внутри и вне команды — это один из самых важных показателей, он показывает расхождения между ожиданиями заказчиков и других заинтересованных лиц от команды и тем, как команда сама себя воспринимает. Agile — про тесное взаимодействие бизнеса и тех, кто реализует продукт, поэтому эти расхождения — отличный повод «сверить часы» между этими двумя областями и договориться о том, как перестроить работу команды.

5 правил интеграции UX в Agile и Scrum

Перевод

Когда я только начинал свою карьеру, программное обеспечение поставлялось в коробках. Если для вас это звучит странно, знайте, что, когда я был ребенком, мой отец приносил домой перфокарты, на которых программы записывались в 1970-х. У такого программного обеспечения было конечное состояние. Через 20 лет с того момента это уже казалось нелепым. Сегодня же мы создаем системы, которые можно совершенствовать бесконечно. Отсюда возникает вопрос: «Когда работа заканчивается?» — и на этот вопрос сложно дать ответ. Мы ищем ответ на этот вопрос, потому что он поможет нам дать ответ на другие, еще более важные вопросы. Получит команда свою премию или ее отчитают? Будет ли команда заниматься чем-то новым? Получит ли стейкхолдер свою выгоду?
Команды разработчиков, которые используют Scrum (или любую другую вариацию методологии Agile), имеют четкое представление о том, когда заканчивается разработка. Часто под этим подразумевается «набор минимальных критериев, которыми должен обладать продукт/услуга для удовлетворения потребностей бизнеса». В результате все сводится к списку функций, который утверждается стейкхолдером (или product owner’ом) и на момент завершения проекта должен быть полностью выполнен. Разработчики зовут это «работает, как было задумано».

Свет в конце тоннеля

Agile

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

Мы прошлись по аспектам, которые необходимо учитывать при изменении мышления на уровне организации. Сухо отвечая на вопрос «Возможен ли Agile для всей компании?» — «Да», но с большим количеством но. В этих оговорках будет спрятан процесс по изменению мышления человека, структуры организации, выбора города, офиса или даже смены страны для всей фирмы. Если не учитывать этого, то можно потратить кучу энергии на изменение, которое не под силу государствам. Если выбрать правильное место и команду, то успех будет на Вашей стороне. Вам не придется пробивать стену там, где она имеет большое сечение. Возможно, это ответ, почему многие организации создают правильную атмосферу внутри компании. Человек находится в экосистеме: любимое дело, досуг, отдых, хобби, знакомые, друзья — все связано с работой. Это один из возможных способов, когда создается микромир и не тратятся силы на изменения городов, стран и континентов.

[Видео] «Пиэмы не нужны» и ещё три идеи по управлению проектами

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

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

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

Openspace Agility: внедряем Agile во всей компании (теперь вместе с руководством!)

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

Как мы хакнули умные подушки и запустили приложение для умной спальни «Асконы»

Привет! Меня зовут Сергей Солдатов, я директор по продукту в компании 65apps. Мы разрабатываем мобильные приложения, используем в работе продуктовый подход. Хочу поделиться с вами нашим недавним кейсом, где именно продуктовый подход помог погрузиться в непривычную предметную область и создать сервис с уникальной ценностью. Это наш совместный проект с компанией «Аскона» — приложение для управления умной спальней.
Для начала забавный факт: перед началом работы всей проектной группе, а это: директор по продукту, арт-директор, руководитель проекта, аналитик, дизайнер, разработчики iOS, Android и QA-специалист, «Аскона» передала свои умные девайсы, — видимо, чтобы мы лучше высыпались и продуктивнее работали. Прямиком с завода к нам в ижевский офис приехали подушки, трекеры сна, основание кровати — все это было необходимо подключить. Мы действительно спали на этих подушках — и это тот самый случай, когда я готов их неистово рекомендовать. Я уже не смог вернуться к своей старенькой синтепоновой, и после сдачи проекта купил всей семье «умные» подушки («Аскона» не платит мне за рекламу, а жаль).
Это тот самый случай, когда клиент позаботился о своих разработчиках и, в результате, мы сделали классное приложение. Но обо всем по порядку.

Немного теории

Сразу оговорюсь, что данный раздел я включил для помощи тем, кто подумывает или исследует внедрение Agile в компаниях. Если Вы читали или имеете представления о нижеприведенных фреймворках смело пропускайте и переходите к сути статьи: практике применения Agile трансформации в компании численностью 6000 человек.

Agile

Какие есть фреймворки для Agile трансформаций компаний?

Как я упомянул в начале статьи одной из проблем перестройки мышления с директивного на гибкое является повсеместное внедрение Agile практик. То и есть не только использование Скрам в конкретной ИТ команде, а изменение всех отделов, в том числе работы директора компании, на «новые рельсы». Для осуществления таких практик есть ряд решений.

SAFe и безопасно ли…

Спасибо boblenin за краткий экскурс про фреймворк. Когда я впервые столкнулся с SAFe оказалась полезной статья с фотографиями и объяснением «на пальцах», что есть SAFe. Отдельное спасибо и всяческого хабродобра rsn81. Если кратко, то SAFe — это об внедрении Agile подходов не только в ИТ, но и во всей организации.

LeSS и не мало ли…

Помимо SAFe есть и другие подходы. Второй пример — это LeSS с идеологией минималистичности. Общая идея — меньше правил и фокус на использовании экспертизы команд. Звучит интересно, учитывая различия в культурах, знаниях и понимании. Спасибо myIDddv за освещение данного подхода.

Краткое резюме по теории

Я привел три возможных сценария по изменению компании. На самом деле их могло или уже есть намного больше. Главная мысль в кратком отступлении, что для трансформации на уровне компаний существует множество фреймворков, мнений и практических кейсов. Мой путь — это один из возможных. Далее я буду рассказывать про непосредственное внедрение Agile в большой компании на примере SAFe. 

Agile

Фактический человеко-месяц

У нас в Wrike есть традиция делиться с командой мыслями о книгах, которые прочитали. Мы давно думали, что было бы неплохо распространить эту инициативу и на наш блог на Хабрахабре, и вот подвернулся хороший случай — книга Фредерика Брукса «Мифический человеко-месяц».
Книгу можно назвать скорее классикой фольклора разработки, нежели реальным руководством по построению рабочего процесса. В ней отражены проблемы, с которыми Брукс столкнулся при организации работы над созданием операционной системы OS/360, и его подходы к их решению. Результат был далек от идеала, на что сам Брукс и указывает. Его целью было не научить как правильно, но поднять проблемы, требующие решения. Любопытно разобраться, что изменилось в разработке с 1960-х годов.
Фото из архива IBM