Agile *

*На фотографии моя голограмма из моего приложения.

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

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

Друзья, привет!

С вами Денис Бартоломе, руководитель направления развития проектной деятельности Росбанка. Сегодня я расскажу об эволюции восприятия Канбан-метода.

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



Если интересно — добро пожаловать под кат.

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

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

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

Бывало ли с вами такое, что вовремя общения, чтения или изучения чего-то будто осеняет, какая-то из старых или нынешних ситуаций в буквальном смысле предстаёт в новом свете? Со мной это постоянно случается, в этот раз при чтении книги “Азбука системного мышления” Донеллы Медоуз.



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

Один из призывов и советов Донеллы в книге — обращать внимание не на конкретные События, а на Поведение Системы в целом и на то, как устроена, её Структура.

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

Здесь и далее команда и система будут синонимами.

Я вернулась из NYC две недели назад с конференции Business Agility Conference, сейчас заканчивается мой двухнедельный карантин — есть время поделиться наблюдениями, как всё происходило в США и как у нас. А заодно, что стоит делать и чего не стоит с точки зрения Agile. Даже в случае пандемии такой инструмент может помочь — упорядочить мысли и действия. Чтобы не метаться бессмысленно, как курица с гречкой вместо головы — что в жизни, что в бизнесе.

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

У меня за время путешествия между континентами сформировался чёткий план действий, которым я с удовольствием поделюсь с вами.

Мне «повезло» увидеть, как начался коронавирус в США — и только я вернулась в Россию, а здесь уже было продолжение. И могу поделиться, в чём разница.

Начало истории: я выступала на конференции в Нью-Йорке, на Business Agility Conference. Это крупнейшая конференция по Agile — проходила она 11-12 марта. Я была единственной русской. И вообще единственным иностранным спикером на сцене.

Я вернулась из NYC две недели назад с конференции Business Agility Conference, сейчас заканчивается мой двухнедельный карантин — есть время поделиться наблюдениями, как всё происходило в США и как у нас. А заодно, что стоит делать и чего не стоит с точки зрения Agile. Даже в случае пандемии такой инструмент может помочь — упорядочить мысли и действия. Чтобы не метаться бессмысленно, как курица с гречкой вместо головы — что в жизни, что в бизнесе.

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

У меня за время путешествия между континентами сформировался чёткий план действий, которым я с удовольствием поделюсь с вами.

Мне «повезло» увидеть, как начался коронавирус в США — и только я вернулась в Россию, а здесь уже было продолжение. И могу поделиться, в чём разница.

Начало истории: я выступала на конференции в Нью-Йорке, на Business Agility Conference. Это крупнейшая конференция по Agile — проходила она 11-12 марта. Я была единственной русской. И вообще единственным иностранным спикером на сцене.

За пять лет в коммерческой разработке у меня накопился ряд претензий к манифестам. И я решил, что будет забавно сделать манифест на эту тему. Представляю вам:

Манифест про манифесты

• В манифестах пишут очевидные вещи. Это одна из них.
• Предыдущий пункт — шутка про рекурсию.
• Прежде чем пользоваться советом из чужого манифеста, найди доказательства, что совет работает.
• Это касается и предыдущего пункта.
• Если в манифесте написано что-то правильное, это не означает что все пункты правильны.
• Если вы нашли в манифесте ошибку — он бесполезен.
• Предыдущий пункт — пример ошибки.
• Манифесты склонны становиться карго-культом.
• Добавьте по 1 очку культиста, за каждый непонятный вам пункт. Включая предыдущий и этот.
• Этот манифест подписали: Боб Мартин, Линус Товальдс и Дональд Кнут.
• Конечно, нет. Но если бы от этого манифест стал для вас более ценным, добавьте себе еще 2 очка культиста.
• Добавьте еще 5 очков.
• Если вы склонны объяснять вещи с конца и вас злит, что они не очевидны другим.
• Если вы не вели хотя-бы приблизительный подсчет очков, еще 3 очка штрафа.
• Посчитайте очки и сделайте выводы.

Готовил его специально к 1 апреля. А теперь, хочу пригласить вас обсудить манифесты.

Привет, я Лена из JetBrains! В текущей ситуации нам с командой YouTrack кажется особенно важным выполнять обещания по тому, что запланировано к выпуску на 2020. Поэтому рада представить YouTrack 2020.1, в котором такую радость и другие эмоции можно теперь выражать с помощью с эмодзи-реакций. Ими теперь можно отвечать на комментарии к задачам, а центр уведомлений будет держать вас в курсе реакций, которые вы получаете.



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

Подробнее о новшествах — дальше в посте.

На вопросы отвечал Павел Зыков, СТО DomClick.ru

ДомКлику скоро 5 лет. Давайте немного вспомним историю и заодно познакомимся. Компания была основана в 2015 году. Ты помнишь день, с которого все начиналось?

Еще как помню. Я входил в число основателей, поэтому помню все в мельчайших деталях – как собеседовали первых людей, как в августе 2015 года сняли первый офис на улице Рабочая, который устраивал нас по цене, несмотря на то, что подоконники кабинетов всегда были в пыли от проходящих рядом поездов. Сейчас, сидя в максимально комфортном Agile Home в 2 минутах от ст. метро Кутузовская, с теплотой вспоминаем о тех временах, когда два интернет — провайдера в здании считалось нашим уникальным преимуществом.

Тема OKR (Objectives and Key Results) сейчас становится все более популярной в бизнесе. Во многих компаниях рассматривают возможность внедрить у себя эту методологию. Мы в Wrike перешли на OKR в 2015 году, и на тот момент это была достаточно новая и малоизученная тема, по крайней мере в нашей стране. Теперь по прошествии нескольких лет кажется полезным рассказать о нашем опыте работы с OKR. И о наших ошибках, которых можно было бы избежать. Оценить общий результат, который мы получили от внедрения OKR в компании. Возможно, наш опыт окажется полезным для тех, кто задумывается о том, стоит ли переходить на OKR.

Есть замечательное приложение T-REC позволяющее трэкать время, потраченное на задачи в Youtrack, и записывающее его в таску. Но автор забросил его больше двух лет назад, плюс старые зависимости, постоянная загрузка одного ядра (тут видимо виноват electron) и периодические падения привели к тому, что пользоваться им стало «неудобно». Решил написать свой, с тем же функционалом, только на плюсах, так появился Honsu…

Разработка по методологии Agile нацелена на то, чтобы выдавать новые фичи быстро и с нужной периодичностью, обеспечивая постоянный поток изменений. Гибкий подход позволяет команде держать высокий темп, но из-за этого нередко страдает качество кода и стабильность продукта. Как решить эту проблему, не загоняя команду в жесткие рамки и не лишая ее преимуществ agile-методов? Помощь приходит со стороны тестировщиков. Меня зовут Денис Дубовой, я руковожу отделом тестирования в дирекции больших данных X5 Retail Group, и в этом материале я расскажу, как появление тестировщиков помогло повысить качество работы наших разработчиков.

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

Проблема

Скрам — это эджайл фреймворк, он предполагает гибкую разработку. Гибкая разработка предполагает гибкие сроки и аналогичный бюджет. Аутсорс-разработка, в свою очередь, в 95% случаев (кроме дедикейта) предполагает жесткие сроки и жесткий бюджет. Условно: “сделайте мне корпоративный портал за 3 месяца, бюджет 3 миллиона. Плачу вам за результат”. И заказчик прав, он хочет видеть результат. И менеджер должен привести команду к этому результату. Только вот, как это сделать, используя скрам?

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

У слова "эффективный" есть два значения:

1. дающий эффект, действенный, позволяющий достичь желаемого результата, далее в тексте – результативный
2. оптимальный, позволяющий достичь желаемого результата с минимальными затратами, наименьшими нежелательными эффектами/ошибками, рентабельный, организованный, с высоким КПД, далее в тексте – производительный

В английском языке – это два разных слова: effective и efficient.

• Being effective is about doing the right things, while being efficient is about doing things right.

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

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

Agile Манифест был опубликован в 2001 году. Он определил ценности и принципы, на основе которых всё множество практик, использовавшихся в разработке программного обеспечения, как новых, так и ранее существовавших, было разделено на две части – Agile практики и не-Agile практики.

Например, юнит-тестирование, покер планирования, ежедневные стендапы стали считаться Agile практиками.

С другой стороны, штрафование сотрудников, подготовка и подписание полного ТЗ проекта, разделение команд по функциональному признаку (отделы архитектуры, разработки, качества) в Agile список не попали.

Причины, по которым ту или иную практику считают Agile или наоборот, не всегда очевидны.

Данная статья – попытка переосмыслить известные мне Agile практики, сформулировать простые и четкие критерии того, какую практику можно считать Agile, а какую нет.

Да все уже 100 раз про управление проектами написали

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

Чистый скрам — как единорог на музыкальном фестивале: вроде бы он существует, все о нём говорят, только вот показать тебе его никто не может. Так же сложилось и у нас в команде, об этом и поговорим. А если конкретнее — о том, как мы сократили время на встречи и не потеряли пользу от них.

В стратегиях большинства компаний все чаще упоминается цифровизация: одни компании пытаются внедрять современные технологии (например, Big Data, IoT, AI, blockchain), другие — повсеместно автоматизируют свои внутренние процессы. Несмотря на растущие усилия и инвестиции во внедрение систем, многие считают результаты посредственными. В идеале современным организациям надо уметь быстро создавать новые цифровые продукты или интегрироваться с популярными сторонними сервисами; выводить процессы за пределы своей организации; уметь эффективно взаимодействовать с партнерами, сохраняя при этом обособленность своих процессов. Также надо уметь не только собирать данные, но и быстро получать к ним доступ и управлять ими. Тем не менее даже «зрелые» компании сталкиваются со сложностью преобразования и управления данными, с постоянной конкуренцией бизнес-приоритетов. Что же мешает им достичь совершенства? 

Опыт нашей команды DTG в создании цифровых продуктов и сервисов позволяет утверждать — решению перечисленных задач мешает проблема трех монолитов: монолита приложений, интеграционного монолита и монолита данных. Они являются результатом унаследованных парадигм традиционной архитектуры, культуры полагаться на имеющиеся данные и работать в «слоеной» системе, где обособленность IT-департамента и бизнеса ведет к потере данных и знаний о них. Решением же данной проблемы мы видим переход от традиционных подходов разработки и управления к распределенным, что предполагает серьезные технические и культурные изменения в организации.

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

– Рынок систем управления давно насыщен! Это была хорошая идея 30 лет назад.
– Ха-ха еще одна система управления проектами. Их же уже сотни?
– Команда вроде опытная, а занялись давно просроченной идеей. Вам бы что-то на Блокчейн сделать…

Примерно так говорят 9 из 10 инвесторов, когда слышат, что мы делаем еще одну «новую» систему управления проектами с упором на коммуникации. Оставшиеся 10% смотрят на рост пользователей, размер рынка и спрашивают: «А вы сами понимаете, в чем фишка и почему вы растете?»

Мы думаем, что понимаем. И также думаем, что понимаем, в чем «фишки» других продуктов, которые продаются на b2b рынке систем управления примерно на $10 млрд в год.



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