Agile *

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

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

В чем тут основная сложность? Если быть точным, то сложностей тут две:
1) такая ситуация действительно может только казаться;
2) если не кажется, что с этим делать?

Давайте разбираться. Я лично сторонник нескольких подходов в решении таких задач.

В этой статье хотелось немного поговорить о том, как используется Agile в ИТ-компаниях. И начнем сразу с главного: для большинства таких компаний Agile в виде Scrum, Kanban, Lean или XP – это не просто эфемерная атмосфера всеобщей гибкости, а вполне себе конкретный производственный процесс по созданию и поставке ПО.

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

Продуктовый подход с использованием Scrum может использоваться и в сервисных ИТ-компаниях, когда они делают продукт для заказчика или вместе с ним по вышеописанной логике. Только такие продуктовые истории для сервисных компаний — это проект и внутренние метрики у них отличаются от метрик продуктовых компаний.

Привет, меня зовут Лилия, я QA TeamLead в финансовом маркетплейсе Одобрим.ру.
У нашей команды нет разделения на разработку и поддержку, и мы работаем по Kanban. Данная методология позволяет нам совмещать поддержку (т.е. задачи, которые появляются неожиданно и которые нужно выполнить срочно) и задачи из бэклога, которые запланированы заранее.

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

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

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

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

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

Потому первостепенная задача сейчас – научиться фильтровать информационный поток. Тайм-менеджмент, он не про то, как сделать больше за 8 часов, он про то, как сделать важное за 8 часов.

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

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

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



В итоге основными инструментами для анализа стали: поиск Яндекса, Wordstat и крупнейшие книжные сайты с их статистикой и отзывами. О том, какой рейтинг можно «намыть» с их помощью, — под катом. И еще мы думаем, что методика получилась универсальной — вполне применимой для подбора книг по другим направлениям.

У нас с Анатолием Ивановым, директором по разработке PropellerAds, получился странный разговор — у него никак не хватало времени. Потому я успевал его поймать три раза — и трижды наши темы сворачивали совсем не туда, куда мы планировали. Вместо интервью получилась ретроспектива всего, что сейчас происходит.

• И нарастающий кризис.
• И Agile-транформации, который занимается Анатолий.
• И спор с Тиньковым, что у него «банк» или «IT-компания»
• И двухдневные спринты, на которые сейчас переходят команды.
• И рождение микрокоманд.
• И глобальные изменения в инвестиционных потоках.
• И будущее после того, как всё это закончится.
• И истории, как Agile внедрялся в PropellerAds с реальными примерами и ошибками.

Я бы это назвал упорядоченный хаос. И он мне нравится. Особенно сейчас.

В течение всей истории разработки ПО мы искали надежные способы оценки времени на реализацию задач и проектов. Но и спустя более чем 60 лет существования отрасли наши прогнозы все еще оставляют желать лучшего. Может быть, дело не в том, как именно мы пытаемся оценивать, а в том, что мы вообще опираемся на оценки?

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

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

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

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

Однажды для нашей команды перестали работать ретроспективы.

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

Это были мои первые спринты в роли скрам-мастера, и я чувствовал, у команды нет доверия к ретроспективам. Да и потребности тоже нет — есть жалобы на «скрам-день», забитый митингами. А работать-то когда?

Я решился на страшное для скрам-мастера: предложил команде отменить ретроспективы — и вот что из этого вышло.


Я, пытаюсь провести скучную ретроспективу

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

На связи команда Youtrack из JetBrains. Наши пользователи очень давно просили нас придумать что-то, что позволило бы им хранить документацию прямо в трекере. И вот в рамках мажорного релиза 2020.2 произошло важное событие: в YouTrack появилась база знаний. Теперь вы можете собирать полезную информацию для работы в одном месте и хранить внутреннюю документацию прямо в YouTrack, бок о бок с проектами и задачами, а ваши внешние пользователи смогут находить ответы на свои вопросы прямо в трекере.



За подробностями добро пожаловать в пост.

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

Привет! Если ты новичок в IT-мире и хочешь разобраться в итеративно-инкрементальной разработке с помощью инструмента для управления проектами, присоединяйся к нашему бесплатному воркшопу 3-го июня. В простом и интерактивном zoom-формате мы расскажем, как определять приоритеты, наполнять бэклог, разрабатывать MVP — все на простых и жизненных примерах. Если ты только начинаешь свой путь в IT, тебе точно будет полезно узнать про итерации и инкременты.

Привет, Хаброжители! Мы сдали в типографию очередную новинку! Прошло почти двадцать лет с тех пор как появился Манифест Agile. Легендарный Роберт Мартин (Дядя Боб) понял, что пора стряхнуть пыль с принципов Agile, и заново рассказать о гибком подходе не только новому поколению программистов, но и специалистам из других отраслей. Автор полюбившихся айтишникам книг «Чистый код», «Идеальный программист», «Чистая архитектура» стоял у истоков Agile. «Чистый Agile» устраняет недопонимание и путаницу, которые за годы существования Agile усложнили его применение по сравнению с изначальным замыслом. По сути Agile — это всего лишь небольшая подборка методов и инструментов, помогающая небольшим командам программистов управлять небольшими проектами,… но приводящая к большим результатам, потому что каждый крупный проект состоит из огромного количества кирпичиков. Пять десятков лет работы с проектами всех мыслимых видов и размеров позволяют Дяде Бобу показать, как на самом деле должен работать Agile. Если вы хотите понять преимущества Agile, не ищите лёгких путей — нужно правильно применять Agile. «Чистый Agile» расскажет, как это делать разработчикам, тестировщикам, руководителям, менеджерам проектов и клиентам.

Что такое разработка в Сбере? В глазах обычного айтишника: «Вот где код написали, туда и идите!». Но это давно уже стереотип, а они хорошими не бывают. Стремительное развитие open source доказывает, что такая культура давно себя изжила, и энтерпрайз (если он умный) давно пересмотрел silo-based подход к разработке.



Публикация всего банковского ПО в open source — эффектный способ самоубийства довольно спорное решение, и нужен какой-то промежуточный этап. C масштабами банка мы можем запустить свой внутренний open source, а не пытаться проверить, что можно показать всем и трястись от страха за наши маленькие большие секреты.

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

Чтобы сформировалась реальная, а не cargo Agile-команда. Причём эти принципы касаются, как бизнеса, так и IT. И на десерт мы приберегли роли в Scrum и SWAY.

Конечно же, в процессе не обошлось без инсайта.

Привет всем, хотел рассказать о материалах при подготовке к сертификации PSM II от Scrum.org. Буду очень рад, если поделитесь своим опытом тоже :)

Sidenote: если вы апологет движения "сертификаты потеряли свою ценность" — я с вами соглашусь. И в отношении PSM I всё довольно просто — сертификация говорит что вы понимаете как работает фреймворк в общих чертах. В PSM II уже идёт работа с набранным в бою опытом применения скрама, потому она (сертификация) серьёзнее. Но ничего сверхъестественного в этом экзамене тоже нет. Кстати, сейчас в мире 6793 PSM II обладателей.

Подготовка к PSM II

Как писал Denis Salnikov, хорошо будет пройти Scrum.org open assesments перед сдачей несколько раз на 100%

• PSPO open — потому что там бывают вопросы, чтоб вы понимали как коучить PO и как идёт работа с ценностью. (кстати говоря, если вы дошли до PSM II, вы вполне можете сдать PSPO не мучаясь, что я и сделал).
• PSM — потому что это должно отскакивать на зубок. Ценности, роли, события, артефакты.
• PAL-E — чтобы через призму коучинга понимать менеджмент, и некоторые метрики, взрослость компании.
• PSK open — чтобы понимать основы работы с потоком.
• Nexus open — базовые основы пусть не самого популярного, но официального scrum.org решения для масштабирования.

Какие-то другие тесты надо проходить осторожно. В интернете довольно много подготовительных тестов: некоторые из них несколько PMBoK уклона, что норм для PMI-ACP, но другие прям адово извращают саму суть скрама, вводят какие-то новые роли, занимаются всяческим саботажем того, что вы практикуете к моменту подготовки к PSM II — берегите себя.

Коучинг, книжки, тренерство

Lyssa Adkins: Coaching Agile Teams — довольно лёгкая

Вступительное слово

Для удобства я буду писать различные английские слова, такие как “Agile”, “coach”, “Scrum” и т.д. русскими буквами. Аджайл, коуч, скрам и т.д. Кто легко оскорбляется наличием транслитерации в тексте — прошу меня понять и простить.

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

К нашему всеобщему счастью в Аджайле обитают не только чудовища. Одно из порождений Аджайла, о котором сегодня пойдёт речь — аджайл коуч.

А стоит об этом поговорить, потому как всё чаще можно встретить людей, всерьёз рассуждающих, что лучше канбан, или скрам; увидеть компании, ищущие аджайл коучей/скрам-мастеров (именно в таком виде), и наткнуться на литературу, рассказывающую, что в начале было слово, и это слово было “Аджайл”.

И это опасная тенденция.

В конце есть краткое содержание, если что.

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

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

Поначалу думал, что дело во мне. Ну, такой вот я дурак, не могу стабильно работать. Потом стали бросаться в глаза скачки в работе команды, которой руковожу – опять же, дикие, в 2-3 раза. Не говоря уже о перепадах эффективности отдельных программистов.

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

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

Ответ пришел случайно. Всё дело в настроении.