Журнал Bright
  • Журнал Bright
  • Лица
  • События
  • Мнения
  • Путешествия
  • На глубине
  • Архив
  • О журнале

28.01.2019 (понедельник)

13.12.2018Блог Скрам-мастераOlesya_Moysa

Что делаем с Java code conventions? Это один из тех вопросов, решение которого мы с коллегой запланировали на ближайшее время, когда накидывали планы развития команд в первый рабочий день этого года.

УТРО

В чем, собственно, суть? Есть соглашение по оформлению кода Java, которое выпустили еще в 1997 году и оно является эталоном оформления кода. Я о нем узнала совсем недавно, когда очередной раз встал вопрос рефакторинга: вместо того, чтобы «облегчать» работы тех или иных алгоритмов, хочется поменять оформление кода по чисто эстетическим соображения. В итоге мы получаем рефакторинг, который не несет ценности ни коду, ни пользователям. Встал вопрос о том, что нужно договориться об едином стиле кода. В своей команде я уже провела на эту тему несколько встреч в прошлом году, но для того, чтобы вынести это на обсуждение всех трех команд, нужно основательно подготовиться. Мы договорились с моим коллегой скрам-мастером/разработчиком, что он подумает, как с командами «вспомнить» Java conventions, мы дособерем все спорные моменты у остальных двух команд и через неделю проведем встречу, чтобы у нас были свои договоренности на этот счет. Придут новенькие — тоже не будут все меня на свой вкус, а рефакторить по делу.

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

ДЕНЬ

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

ВЕЧЕР

После планирования мы запустили спринт. Команды разобрали задачки, у меня появилось время, чтобы сделать домашнее задание после воркшопа в школе скрам-мастеров: составить канвас встречи, как занести инженерные практики в команды. Я выбрала ATDD, так как сравнив ее со всеми другими поняла, что она самая крутая, так как влияет и на качество кода (улучшает!), и на коммуникации внутри команды и с бизнесом (повышает!) и, как следствие, уменьшает time to market. Видимо, на следующий спринт буду заносить в команды. Участвовала в собеседовании разработчика, неоднозначное впечатление, думаем.

Вернуться -> 25 января (пт)     /     Далее -> 29 января (вт)


Метки: инженерка, планирование
Предыдущая запись 24.01.2019 (четверг) Следующая запись 18.01.2019 (пятница)

Похожие статьи

N серьезных ошибок в общении с коллегами

12.12.2021admin

«Ночь искусств – 2019» в Молодежном театре – «Театральный роман»

13.10.2019admin

День финансовой грамотности в Мастерславле

04.09.2018admin
Комментарии:

Добавить комментарий Отменить ответ

Ваш e-mail не будет опубликован. Обязательные поля помечены *

CAPTCHA
Обновить

*

©Bright live
ЭЛ № ФС 77 — 58164.

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