Agile *

Привет, Хабр! Вам приходила мысль сделать свою систему управления проектами и задачами? Нам да! И мы делаем YouGile. 

Знаете, в чем самая большая сложность? Выбрать и сфокусироваться на одном востребованном направлении продукта. Вообще такая задача есть везде, но тут она особенно масштабная. 

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

У нас есть внутренний документ, в котором собран обзор 52 систем управления проектами, и он постоянно обновляется и используется в трудные моменты выбора приоритетов.

Текст невероятно длинный (проскроллите до конца?) Внизу есть таблица с кратким содержанием.

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

Привет!

В среду, 24 февраля, мы проведем онлайн-митап для интересующихся практиками Agile.

Митап бесплатный, главное — зарегистрироваться заранее по ссылке. Всё действо займет пару часов (с 19.00 до 21.00).

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

В программе 3 доклада от наших спикеров.

Программа митапа

Приветствую, Хаброзритель. В данной статье я хочу познакомить тебя с органайзером Notion, поделиться своим опытом использования. Также я дам несколько советов, идей, к которым я пришел со временем, учась планировать и использовать свое время, силы и мыслетоплево. Некоторые мысли, конечно, не будут напрямую связаны с данной программой и не все советы я как-то выделил отдельно, не упусти их.

Надеюсь что буду полезен и прошу под кат.

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

Метрики

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шон Престридж – старший инженер по применению (FAE), руководитель группы FAE американского подразделения IAR Systems – в статье «Move fast and break things? Not so fast in embedded», рассказывает о специфике разработки программного обеспечения для встраиваемых систем, уделяя особое внимание вопросам качества кода и тестирования.

«Двигайся быстрее и ломай преграды» — это подход, озвученный Марком Цукербергом, который он внедряет в культуру разработки Facebook. Несмотря на то, что он чудесно звучит, когда мы говорим о быстром создании и запуске новых функций (даже если они не идеальны), все же он теряет свою красоту, если попытаться применить его к разработке программного обеспечения для встраиваемых систем.

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

Поэтому я не хотел писать еще одну статью с описанием техники Red-Green-Refactor. Мне хотелось взглянуть на TDD немного глубже и описать, как и почему TDD влияет на поведение человека.

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

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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "The agile swarm: How to design shareable work for software project teams" автора Stephen Frein.

^{Фото: Flickr}

Успешные аджайл-команды склонны ограничивать незавершённую работу (НЗП, незавершённое производство). Предпочитают ли они Скрам, Канбан-метод, или какую-либо другую аджайл-методологию, эти команды особенно выделяют над всем остальным быструю разработку полезной функциональности.

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

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

Случалось ли вам работать над проектом, где участвует более сотни человек, несколько компаний, с учетом 10 часовых поясов, разных менталитетов и языков? Хотим поделиться своим опытом планирования работ в проекте, который управляется по методологии SAFe в условиях вынужденной удаленной работы.

Зная, как я люблю экспериментировать, иногда на конференциях меня коллеги спрашивают: "Ну, какой у тебя теперь минимальный спринт?"

Я и сам сейчас задумался — с этой самоизоляцией и работой на дому да на даче, какой у меня реальной длительности спринт.

И с удивлением понял: один день.

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