Agile *

«— Скажите, пожалуйста, куда мне отсюда идти? — А куда ты хочешь попасть? — ответил Кот. — Мне все равно… — сказала Алиса. — Тогда все равно, куда и идти, — заметил Кот.» (С) «Алиса в стране чудес»

Низкая производительность труда в России

Думаю, что те из вас, кто был в Греции, ни за что не согласятся, что греки работают лучше россиян. Тем не менее, по исследованиям Организации экономического сотрудничества и развития (ОСЭР) Россия со своим показателем производительности труда на уровне $26,5 в час уступает всем странам ОЭСР (по сути все развитые страны), включая Грецию, кроме Мексики, где он составляет $21,6. Средний для ОЭСР показатель — $54,8, а у лидеров — Ирландии и Люксембурга — на уровне $99 в час.

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

На мой вопрос: “Почему ты пришла к нам?” — мне был дан простой ответ: “Кафе и туалеты — это тоже услуги для клиентов!” Здесь вспоминаются слова Рене Декарта: “Если бы среди философов навсегда установилось согласие относительно значения слов, то почти все их споры были бы прекращены” (“Правила для руководства ума”).

Мы работаем продуктовой командой, и у меня встал вопрос: как описать наш продукт так, чтобы каждый понимал, что мы делаем и в чем мы можем помочь? Чтобы дать на него ответ, я решил разобраться, что означает само слово “продукт”.

Результат моих изысканий под катом…

Меня зовут Лена, и я принесла вам YouTrack. Вы наверняка слышали про этот сервис трекинга задач от JetBrains, а если нет — время познакомиться!

Мы выпустили новую версию и вот что происходит: появились новые функции и улучшения практически для всех сценариев использования YouTrack.

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

Когда мы планируем разработку, в нашем бэклоге лежат задачи. Рядом с каждой из них могут незаметно притаиться риски — один или несколько. Давайте поговорим о том, как эти риски увидеть и что с ними делать потом. Это обобщение моего опыта в роли тимлида — что я делал по поводу рисков в бэклоге, что получалось, что нет.

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

Вот уже 7 лет, как я раз и навсегда «переехала» из реальных офисов в виртуальные. Мне гораздо комфортнее работать дома на удалёнке. Под «виртуальным офисом» я подразумеваю системы управления проектами. За годы дистанционной работы с разными компаниями и студиями я перепробовала их более 10 штук.

Поделюсь своим опытом использования 10 систем управления с точки зрения удобства коммуникаций. Для меня как для контент-маркетолога это имеет ключевое значение. Мне важно, чтобы сообщения и файлы не терялись. Смотрим, какой корпоративный мессенджер справляется с этим лучше.



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

Я оценивала удобство коммуникаций максимально объективно, по ряду критериев:

• «Есть ли чаты и живая лента?»
• «Насколько широк функционал комментариев?»
• «Есть ли интеграция с облачными хранилищами?»
• «Сколько ГБ в облаке на бесплатном тарифе?»
• «Можно ли хранить файлы в одном месте?»

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

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

Источник

Традиционно процесс разработки ПО сравнивается со строительством. Термин «архитектор» только укрепляет ассоциативную связь между этими процессами. Но современные реалии сделали эту модель неактуальной, потому что есть механизмы, которые она объяснить не может:

• Если мы делаем какой-то физический объект или продукт, то почему ПО никогда не считается законченным?
• Если мы говорим об инженерных решениях, то почему мы никогда не можем уверенно планировать наперед?
• Если мы — архитекторы или строители, то почему так много проектов заканчиваются полным провалом?
• И наконец, при наличии множества советов, best practices, принципов, книг и докладов о разработке ПО, почему так много проектов превращаются в невыносимое место для работы?

Предлагаю близкий к тексту перевод блестящего доклада Сары Мэй «Livable code», где она рассматривает все эти вопросы.

Что делать, если вы не знаете, что такое Скрам?

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

Приглашаем 26 ноября на встречу сообщества практиков Agile в крупных организациях — Enterprise Agile Russia. Спикеры Технологического Центра Дойче Банка, Райффайзенбанка и компании Ингосстрах поделятся своим опытом Agile-процессов.

Подключайтесь к трансляции!

Картинка взята с данного ресурса.

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

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

Хотя Daily Scrum или Stand-up встречи принципиально отличаются от отчетных встреч, иногда первые становятся похожими на вторые. Чтобы этого избежать, давайте рассмотрим отличия хорошего эффективного Daily/Stand-up и не лучшей сферической встречи по статусу в вакууме, а затем будем стараться придерживаться хороших практик или избегать плохих.

Гибкий суррогат

Словом «Scrum» называются, как минимум, две сущности: философия и фреймворк.
Философия, или подход к работе, описан в книге Джеффа Сазерленда.
Фреймворк, т.е. алгоритм действий, описан в документе под названием Scrum Guide.
Философия превратилась в фреймворк, потому что авторы философии хотели заработать на ней денег (по их собственным словам).

Фреймворк сильно упрощен, по сравнению с философией. Главное — упрощена, а точнее выкинута, цель.

Цель философии: ускорение достижения результата. Причем, в разы. В книге есть примеры ускорения в 8 раз.

Цель фреймворка: чтобы у вас был Scrum. Там так и написано: делаете по инструкции — у вас Scrum, нарушаете инструкцию — у вас не Scrum.

Фреймворк не предполагает ускорения достижения результата, вообще.

Люди, преподающие или внедряющие Scrum, работают с фреймворком. Рассказывают и внедряют алгоритм, не приводящий ни к каким результатам, кроме «у нас теперь Scrum».

Суть понятна. Философию продавать очень сложно. Фреймворк — проще.

Фреймворк — это продукт. Он, как положено, прошел «упаковку». Он прост, понятен, есть поддержка и много специалистов. Ничего не напоминает?

Всё хорошо, кроме результата — его нет.

Привет! Меня зовут Маша, я Scrum Master в ivi. Работаю с командами биллинга и веб-разработки и помогаю ребятам организовывать рабочие процессы так, чтобы не только эффективно достигать целей, которые ставит бизнес, но и получать удовольствие от того, что ты делаешь. В своих статьях хочу делиться опытом, как настраивать свою собственную работу и работу команд, если вы Scrum Master или Team Lead. А в этой статье давайте поговорим о важности культуры обратной связи.

Фидбэк от других участников команды является компасом, по которому каждый определяет, куда двигаться дальше. Согласно Патрику Ленсиони, один из пяти пороков команды — нетребовательность друг к другу. Этот порок достаточно сложно «вылечить». Но при этом он может оказаться губительным.

Присоединяйся к митапу от Scrum Community Райффайзенбанка сегодня, 29 октября, в Нагатино. В программе две важные темы — от теории до практики. Узнавайте новое вместе с участниками Скрам-сообщества Raiffeisen Digital.

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

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

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

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

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

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

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

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

О чем частенько молчат консультанты по Agile? Во что упираются большие организации, когда решают внедрить Agile-подход? Почему вместо розовых единорожек мы получаем здоровенных бегемотов? Мое выступление на конференции Enterprise Agile Russia — 2019

Вам приходилось испытывать сильные эмоции на работе? Как насчёт страха, внезапно захлестнувшего ваш мозг? Легко потом работать эффективно? Если ваша организация уже внедрила agile, но с вами такое всё еще случается – что-то идёт не так.

Меня зовут Артем Зарафьянц, и я руковожу одним из отделов разработки СХД Dell Technologies в Санкт-Петербурге. Работаю 12 лет, с открытия нашего офиса. В 2007 году, начиная работу над VNXe, мы стали использовать agile на уровне команды – тогда не сложилось. Наш процесс столкнулся с ватерфоллом на глобальном уровне и постепенно угас. VNXe мы выпускали без agile: конечно же, успешно (как и всё масштабное в нашей корпорации), однако медленно, дорого и на стрессе. Примерно 6 лет назад наша инженерная организация (несколько тысяч сотрудников) начала систематическое внедрение agile at scale сверху. В то время я уже был менеджером и получил второе (из трёх) высшее образование – по психологии. Это помогло мне осознанно пройти через опыт внедрения agile, и я готов им поделиться.

Уже несколько раз, общаясь с коллегами на конференциях и лекциях, я получал вот этот вопрос:

Кажется, пора зафиксировать где-то ответ на него и ссылаться при случае :)

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

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

«Оптимизируй свой бизнес-процесс» — проще сказать, чем сделать! Сегодня у топ-менеджеров стол ломится от методов, стратегий, программ и лучших практик по оптимизации бизнес-процессов.

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

«Lean Six Sigma» — это американский Франкенштейн, объединивший в себе две методологии «Lean» и «Six Sigma». Методология «Lean» направлена на сокращение потерь и ускорение процессов, в то время как «Six Sigma» оперирует понятием удовлетворенность потребителя и направлена на снижение количество дефектов.