Agile *

В руководстве по Evidence-Based Management говорится не только о Стратегической Цели, но и о промежуточной стратегической цели, которая нужна для пересмотра и адаптации вашего прогресса относительно намеченного видения вашего продукта.

Достижение стратегических целей требует экспериментов, проверки и адаптации.

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

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

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

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

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

Метрики

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

Наша самая главная метрика — Lead Time: это характерное время, за которое задача доходит от одной из четырех контрольных точек (появление идеи, ТПР, Х и ТПО) до установки на продуктив.

Если вы планируете создать свою софтверную компанию, то вы задумываетесь как построить работу людей, как выбрать методологию для работы. Но если приглядеться к известным методологиям, то есть к ним некоторое недоверие, особенно если вы тратите на компанию собственные деньги…

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

Привет! Меня зовут Петр Александров, я много лет работал руководителем проектов и живо интересовался вопросами календарного планирования, достижения дедлайнов и координации работ во времени. Сейчас я лидер продукта «Портал метрик продуктовых команд» в SM Lab и работаю с продуктовыми agile-командами. Такие команды делают задачи не к определенному сроку, а по потоку. 

Что это значит?

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

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

3. Задачи в бэклоге приоритезирует Product Owner (заказчик), а не команда.

4. В работу берется самая приоритетная задача из бэклога, и только после того, как обработана и передана дальше по потоку предыдущая задача.

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

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

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

Этот пост посвящен описанию нашего подхода к работе продуктовых команд. В следующем посте я остановлюсь на метриках команд и их использовании при прогнозировании  сроков и синхронизации исполнения задач.

У этой статьи есть две темы: первая - продемонстрировать фреймворк S.T.A.R. (Situation-Task-Action-Result), вторая – рассказать о моём опыте внедрения доски в цикл разработки технологий, позволяющий выполнять геофизическое исследование. Статья будет полезна для начинающих руководителей группы и тех, кто сталкивается с проблемами в приоритизации задач. 

День ото дня мы приближаемся к Agile-трансформации. Одна из самых важных целей для нас – увеличить velocity команд на X %. Слышали об этом? Слова Марка Андрессена о том, что «программное обеспечение пожирает мир», становятся отличительной чертой отраслей, которые раньше были менее автоматизированными.

Компания, занимающаяся разработкой Agile-продуктов, опросила более 18 000 клиентов и специалистов по разработке программного обеспечения.

У большинства систем управления проектами есть бесплатные версии, но они бывают двух принципиально разных видов.

1) «Честная» бесплатная версия. Система искренне хочет, чтобы вы свободно пользовались ею без ограничений по времени. И делились с друзьями.

2) «Пробная» бесплатная версия. Продукт нацелен на то, чтобы сконвертировать вас в платящего клиента. И потому намеренно урезает вам «жизненно важные» функции. Как правило, об этом можно узнать, только начав пользоваться системой.

Мы в YouGile приняли опасное для себя решение и в октябре запустили «честную» бесплатную версию. Сняли все ограничения, оставили только одно – до 10 пользователей. Результат пока такой: сильно потеряли в количестве платящих клиентов, зато график активности в системе вырос в 2 раза за 3,5 месяца.

Конечно, предварительно мы изучили рынок и посмотрели, а какие free-версии предлагают наши конкуренты: Asana, Bitrix24, Trello и другие. Мы постоянно тестируем различные системы управления и можем смело делать выводы: кто предлагает «честную» бесплатную версию, а кто нет.

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

Начнем с продуктов, у которых бесплатные версии наиболее полноценные, а также расскажем про свою.

Agile методология разработки программного обеспечения и DevOps, и в особенности их упор на юзер экспириенс, обращают наше внимание на людей, стоящих за продуктами. Но действительно ли процесс разработки имеет значение или же цель попросту оправдывает средства? Лондонская P3X или People, Product, and Process Exchange в значительной степени сфокусирована на точке пересечения трех этих P, причем, пожалуй, последняя из них является наиболее интересной, поскольку объединила в себе самое большое количество акронимов - разработка через тестирование (TDD - test-driven development), разработка на основе поведения (BDD - behavior-driven development), непрерывная доставка (CD - continuous delivery), разработка на основе предметной области (DDD - domain-driven development) и многие другие - чтобы помочь командам определить, как систематически создавать лучшие системы.

Соучредитель Agile Testing Fellowship Джанет Грегори завершила свой основной доклад о процессе обеспечения качества программного обеспечения, попросив собравшихся поднять руки, если они чувствуют момент волшебства в своей agile-команде и чувствуют, что несут миру качество. Лишь несколько человек из аудитории, предположительно полностью состоящей из практикующих agile разработчиков, подняли руки.

Как так получилось, что с момента подписания Agile-манифеста прошло 17 лет (на момент доклада), а все еще так мало людей вышли за рамки созерцания теней на стене пещеры? Быть может, у нас все еще нет правильного диалога. Быть может, мы все еще не ведем его с правильными людьми. Или, может быть, диалог вообще не являются частью наших процессов.

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

Привет! Я хочу рассказать про свой опыт в самоорганизующейся команде. За полтора года там было от 3 до 5 разработчиков, я не занимался их наймом, но все процессы и разработку я построил с нуля. Расскажу что такое самоорганизующаяся команда, какую пользу она приносит для компании, команды, и ее участников.

Меня зовут Илона, я Senior Experience Designer в EPAM. Работа для меня удачно совпадает с хобби — в EPAM я проектирую интерфейсы для зарубежных заказчиков, читаю лекции для сотрудников и студентов лабы, менторю дизайнеров. В свободное время преподаю проектирование интерфейсов в магистратуре Университета ИТМО и веду Телеграм-канал о UX-дизайне.

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

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

Кристиан Вервейс: О сложности или зачем вам Скрам? 

Предисловие переводчика 

Предупреждение: Это лонгрид и это достаточно серьезный текст, далекий от большинства “простеньких” объяснений что вы могли прочитать на русском про Скрам и Эджайл.  

Оригинал статьи находится тут. Статья входит в список scrum.org рекомендованного к изучению для подготовки к экзамену PSM III.

Важность таких статей сложно переоценить. Судя по ошибкам, которыми делятся команды, и некоторым комментариям, значительное количество людей, пытающихся применить Agile, на самом деле не пошло дальше материалов типа “строим Скрам за 5 дней”, которые больше сосредоточены на практике, а не на причинах и не на основополагающих принципах Скрам и Эджайл. Я сам, как руководитель, изначально столкнулся именно с такой, “от сохи”, реализацией Скрама, но, к счастью для себя, не сделал “обоснованный” вывод что весь этот ваш Скрам - это очередная подделка и модная глупость, а полез разбираться откуда и зачем есть пошел Эджайл и прочие Скрамы. Честно скажу - объем “открытий чудных” был намного больше ожидаемого, несмотря на годы опыта в управлении проектами, накопленные к тому моменту. Так что, надеюсь, что перевод достаточно важной для понимания Скрам статьи будет полезен почтенной публике, и, конечно же, я сам, как сертифицированный Скрам-мастер и человек преподающий Скрам и Эджайл, буду рад ответить на все вопросы. 

Привет, Хабр!

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

Дано:

1. Корпоративное iOS-приложение, реализованное только под форм-фактор Apple iPad с устаревшим дизайном (особенно, если изучать гайдлайны Apple).

2. Заказчик = крупное российское полукоммерческое предприятие. Со стороны Заказчика участвуют 4 департамента (с одинаковым влиянием друг на друга), один из департаментов является функциональным заказчиком (ФЗ) и владельцем бюджета. Остальные отвечают за безопасность и ИТ-сопровождение.

3. Распределенная на 2 города команда со стороны Исполнителя, проблемы с коммуникациями отсутствуют.

Найти:

1. iOS-приложение под iPhone с современным интерфейсом и доп. функционалом

Ограничения:

1. Заказчик на момент проекта никогда ранее не работал по Agile-методологиям, но их руководство на основе последних трендов повсеместно пыталось запустить использование Agile;

2. Договорные отношения между Заказчиком и нами были FixedPrice (оформить T&M было невозможно).

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