Анонс мини-курса по основам Scrum

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

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

Я составил вот такой план (на картинке), которого буду придерживаться. Посты будут выходить примерно 1 раз в 2/3 дня, по мере свободного времени и написания материала.

Подписывайтесь на канал, включайте уведомления, чтоб не пропустить следующий пост и погнали 😎

Интересная статья про позицию тимлида. Там про вливание в команду и проект, митапы, встречи, коммуникации. А так же полезные советы, рекомендации и литература.

В последние несколько лет кроссплатформа набирает популярность, и особо заметна востребованность Flutter.

Полезных источников по Fultter не особо много, поэтому хочу порекомендовать Вам канал Oh, my Flutter – отличное комьюнити единомышленников. Автор канала Михаил Зотьев, практикующий Flutter-разработчик и техлид Flutter команды в Surf. На канале Миша публикует всё самое интересное из мира Flutter - новости, статьи, подборки, анонсы. Хоть я и пишу на Kotlin, для общего понимания подписан на канал.

Залетайте: @ohmyflutter

Что такое Scrum и с чем его едят?

А вот и первая, вводная часть мини-курса "Основные понятия Scum". Официальные трактования вы и без меня найдете в интернете, я же постараюсь своими словами объяснить что такое Scrum и для чего используется.

Итак, что же такое Scrum? Можно встретить множество различных интерпретаций этого понятия (методика, методология и даже фреймворк). Я бы описал этот термин как некий набор рекомендаций для более гибкой разработки, который позволяет значительно снизить время выхода фичи в продакшн (time to market).

В основе Scrum лежат

1. Небольшие кросс-функциональные команды. В команде должны быть все необходимые компетенции для реализации нужной фичи. По моим ощущениям команда не должна превышать 10 человек.

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

3. Короткие спринты. Определенный отрезок времени, за который нужно успеть выполнить поставленные цели.

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

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

Если вдруг я что-то упустил, вы всегда можете написать мне в личку @artemiygreg и дайте плиз обратную связь, жмакнув соответствующую кнопку внизу.

Я всегда говорю о том, что количество написаного кода не равно продуктивности и эффективности. Разработка это не только про написание кода, много времени уходит на подумать, проектирование каких-то штук, обсуждение и т.д.

Не давно Github провёл внутренне исследование "Good Day Project от GitHub". Так вот, результаты этого исследования как раз тому подтверждение.

​📊 Дайджест недели 👇

• Анонс мини-курса по основам Scrum

• Смена работы тимлидом: как готовиться, как онбордиться, и что дальше

• Oh, my Flutter – комьюнити единомышленников

• Что такое Scrum и с чем его едят?

• Исследование "Good Day Project от GitHub"

Digital Media – подписывайся на канал и будь в теме 😎

Основные понятия Scrum. Backlog (Бэклог)

Backlog (Бэклог) – простым языком, это список задач продукта, которые нужно выполнить. Стоит отметить что в Scrum есть 2 варианта бэклога.

1. Product backlog (Бэклог продукта) – это непосредственно общий список задач, историй, багов всего продукта. Как правило, поддерживают общий бэклог, формируют, выставляют приоритеты, актуализируют представители бизнеса, Product Owner или Product Manager, хоть и обязанности у них немного отличаются.

2. Sprint Back (Бэклог спринта) – это уже непосредственно список задач, историй, багов, которые команда должна выполнить за спринт. Бэклог спринта определяет непосредственно вся команда на Sprint Planning.

Дальше у нас по плану "Sprint (Спринт)". Первая, вводная часть о скраме тут. И по традиции, оставьте обратную связь, жмакнув соответствующую кнопку.

Крутые лекции по Android для начинающих

Наткнулся недавно на плейлист с лекциями от Android Academy. Посмотрел несколько видосов - крутые лекции от крутых ребят, доступно, понятно и на русском языке, в общем всё как мы любим. Для начинающих зайдет.

А на гитхабе можно посмотреть крутой Android Roadmap

Пять худших практик написания кода, которые помогут испортить отношения с коллегами

Интересная статейка на хабре про худшие практики написания кода.

Вам знакомо такое понятие как "Технический долг"?

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

Так вот, есть интересная статистика от Stepsiz, согласно которой, средний разработчик тратит 6 часов в неделю (~ 1 рабочий день) на работу с техническим долгом.

Среднее время, затрачиваемое на работы по поддержанию работы legacy систем составляет 33%, из этого времени более 50% тратится исключительно на технический долг. Это время, когда инженер не работает над достижением своих основных целей.

Основные понятия Scrum. Sprint (Спринт)

Продолжаем серию постов по теме "Основные понятия Scrum". Сегодня у нас речь пойдет про спринты. 👇

Sprint (Спринт) – это фиксированный, как правило, короткий промежуток времени, за который команда должна выполнить поставленные цели в начале спринта. Иногда спринты называют итерациями.

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

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

Это пожалуй основные моменты, которые нужно знать о спринтах. Для тех, кто пропустил, предыдущая часть "Backlog (Бэклог)". Включайте уведомления, в следующем посте интересная тема "Grooming (Груминг)".

10 практик «ответственного» тимлида

Интересная статья, в которой собраны 10 практик "ответственного" тимлида. Осторожно, в статье присутствует сарказм 😉

Основные понятия Scrum. Grooming (Груминг)

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

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

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

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

Несколько советов по личному опыту

1. Длительность груминга. Для себя определил оптимальное время 1 час, если груминг длится больше 1 часа – как минимум нужно сделать перерыв 15-20 минут, а лучше и во все закончить, иначе эффективность будет снижаться.

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

3. Активное участие. На груминге может участвовать любой желающий, лучше, когда на груминге будут присутствовать представители всех направлений (fron-end, back-end, moble, qa, аналитики, безопасники), таким образом вы закроете вопросы со всех сторон. Ходите на груминги и принимайте активное участие, на планировании вам это зачтется.

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

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

Слышали что-нибудь про требования ACID?

ACID – это набор требований к транзакционной системе, которые обеспечивают сохранность ваших данных. Расшифровывается аббревиатура ACID как Atomicity (Атомарность), Consistency (Согласованность), Isolation (Изолированность), Durability (Надёжность).

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

Наткнулся на интересный сервис, зацените 👇

DevDocs – сайт с документациями по множеству популярных языков для разработчиков Angular, Django, Go, Git, Kotlin... Так же есть разделы с популярными фреймворками и еще куча всего.

Яндекс показал свою нейросеть, которая может переводить текст видосов в реалтайме.

Основные понятия Scrum. Story Points (Стори поинты)

Вот мы и добрались до 5-ой части нашего мини-курса, в которой рассмотрит понятие Story Points. Напомню, в предыдущей части мы говорили про Grooming.

Story Points – это условная величина, с помощью которой оценивается сложность выполнения истории. Story points не должны привязываться к физическому времени: часам, дням и т.д. Для значений story points, как правило, используются числа Фибоначчи (1, 2, 3, 5, 8, 13 и т.д.), либо похожие на Фибоначчи (...13, 20, 40, 80, 100), чем выше значение, тем сложнее реализации фичи.

По окончанию груминга конкретной истории, соответственно нужно оценить сложность ее выполнения. Как это происходит, есть такое понятие Planning Poker – техника оценки. В чем суть, всей команде раздаются карточки с story points (1, 2, 3, 5...) и каждый член команды должен проголосовать, выбрав нужную карточку. Важно понимать, голосуют в закрытую, то есть, на этапе голосования я знаю только свою оценку и никому ее не показываю, пока все не проголосуют. Когда все проголосовали/выбрали оценку – карточки открываются и таким образом смотрят, каких оценок больше.

И тут есть несколько вариантов

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

2. Спорный. Это наверное один из частых кейсов. К примеру, по итогам голосования мы получаем приблизительно одинаковое количество нескольких оценок. В таком случае, путем обсуждений, нужно убедить других членов команд согласиться на вашу оценку, либо вы должны согласиться на оценку ваших коллег. Таким образом добивается оценка.

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

Если вы только начали или начинаете работать по Scrum, planning poker может показаться чем-то не понятными и сложными, но на самом деле сложного в нем ничего нет, просто нужно время, чтобы понять как правильно сопоставить эти величины с реальной сложностью выполнения. Все это приходит с опытом.

Надеюсь мне удалось в понятном виде донести основную мысль. Согласно нашего плана, в следюущей части рассмотрим Sprint Planning.

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

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

– Митап про опыт развития и масштабирования ДС Альфа-Банка
– О дизайн-системе замолвите слово. Статья от HH, в которой ребята делятся своим опытом внедрения дизайн-системы.
– Дизайн-система: что это, для чего и как создать. В статье рассматриваются общие моменты: что такое ДС, для чего она нужна и как её создать.

Полезно будет для всех, кто хоть как-то связан с разработкой клиентских приложений.

Лучшие практики написания комментариев к коду

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

Самые важные уроки, которые я получил от Senior-разработчиков

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