Agile *

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

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

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

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

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

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

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

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

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

Вам приходилось испытывать сильные эмоции на работе? Как насчёт страха, внезапно захлестнувшего ваш мозг? Легко потом работать эффективно? Если ваша организация уже внедрила 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» оперирует понятием удовлетворенность потребителя и направлена на снижение количество дефектов.

Привет! Меня зовут Анатолий Савченко, я разработчик и по совместительству скрам-мастер в команде сервиса «Автотека». Как вы уже догадались, мы работаем по Cкраму. Каждые две недели мы проводим обзор спринта — встречу, на которой команда и заинтересованные стороны обсуждают, что было сделано. На основе этой информации команда может сделать выводы о том, в правильном ли направлении движется разработка, какие доработки ещё необходимы и т.д. Недавно мы получили ценный новый опыт проведения этой важной встречи. О нём я и хочу вам рассказать.

Создание дизайн-макетов и визуализация решений почему-то всегда вызывает огромный интерес у всех участников продуктовой команды, будь то менеджер, желающий освоить Sketch, или разработчик, который многое повидал и теперь хочет делать крутые интерфейсы сам, а не просить об этом дизайнеров. И это нормально, когда всё это просто на стадии обсуждения. А вот когда доходит до реальной работы…

My Why

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

Я тимлид и моя задача — обеспечить продуктивную работу команды. Это непросто, поскольку готового рецепта успеха не существует. Конечно, есть признанные методологии: Agile, Lean, Value Stream Mapping. Они дают общие ориентиры и ценности, что уже неплохо, но это лишь ориентиры. А с конкретными решениями, будь добр, вертись сам. На то ты и тимлид.

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

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

Дети, рожденные в год подписания Agile Manifesto, в этом году празднуют совершеннолетие. А взрослые люди продолжают спорить, где Agile применим. Обычно бьют по площадям: можно ли использовать Agile вне IT. Иногда добавляют драмы: пробовали ли вы строить атомную электростанцию по Agile? Для художественного эффекта так, конечно, лучше. Но если вы хотите сделать продукт, а не победить в конкурсе ораторов, то лучше смотреть применительно к конкретной ситуации.

В этой статье мы расскажем о нескольких моделях оценки применимости Agile и подробнее остановимся на одной их них — Agile Suitability Model, представленной в Agile Practice Guide от PMI и Agile Alliance.

Если вы озаботитесь хотя бы некоторыми полезными вещами:

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

то они улучшат рабочий климат в команде разработке.

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

Источник

Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.

Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.

Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.

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

Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса

— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.

Мини-справочник Scrum

Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.

Некоторое время назад передо мной встал выбор инструмента для управления небольшими проектами по SCRUM-методологии. У меня был довольно большой опыт использования различных инструментов включая Jira, Asana, Trello и проч., но ни один из них не подходил в полной мере для моего проекта: какой-то был чересчур монструозен, а какому-то недоставало важных для меня фич. В итоге пришлось изобретать инструмент самому, на базе Google Sheets.


Требования, предъявляемые мною к инструменту, были таковы:

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

Перед вами продолжение истории под названием «Как тимлиду выжить в масштабируемом скраме и сохранить контроль за качеством кода» об Agile-трансформации в ivi. На TeamLead Conf технический директор компании Евгений Россинский (eross) рассказал, почему может понадобиться откатить всю реорганизацию команды, как при этом не переругаться и помочь разработчикам, а еще и сохранить и приумножить бизнес-эффективность.

В российском ТехЦентре Дойче Банка есть интересная программа Learn While Travel, в рамках которой сотрудник может во время отпуска в другом городе посетить профессиональную конференцию по своей специальности за счет средств компании. 

Я, Кристина Егорова, и мои коллеги, Оля Одинцова и Полина Пересада, решили рассказать вам о нашем опыте участия в международных конференциях, а также о том, как мы решились сами выступить на одной из них.   

Статью мы решили разделить на две части. В первой расскажем, что нас впечатлило в докладах на конференции 1st European Business Analysis Day 2018 во Франкфурте и как мы решили выступить с докладом на будущий год.

А во второй — о своем докладе на 2nd European Business Analysis Day. 



Итак…

Основатель компании ABBYY рассказал Forbes о том, чем успешный бизнес отличается от провального. Мы в LeadStartup полностью согласны с Давидом Яном, поэтому хотим поделиться его интервью.

1. Грамотное инвестирование

Я инвестирую в те проекты, в которых операционно участвую лично сам. Очень мало инвестирую туда, где не могу влиять на внутренние процессы. А ещё – вряд ли это инвестиция, скорее дарение – вкладываюсь в образовательный фонд Айб.

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

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

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

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

Привет. Меня зовут Дима Мурзин.

По профессии я бизнес аналитик в сфере финансов, работаю с бизнес-стейкхолдерами и с командой разработки, в которой исполняю роль Product Owner. Третий год живу с семьёй в Нью-Йорке.

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