Что делаем с Java code conventions? Это один из тех вопросов, решение которого мы с коллегой запланировали на ближайшее время, когда накидывали планы развития команд в первый рабочий день этого года.
УТРО
В чем, собственно, суть? Есть соглашение по оформлению кода Java, которое выпустили еще в 1997 году и оно является эталоном оформления кода. Я о нем узнала совсем недавно, когда очередной раз встал вопрос рефакторинга: вместо того, чтобы «облегчать» работы тех или иных алгоритмов, хочется поменять оформление кода по чисто эстетическим соображения. В итоге мы получаем рефакторинг, который не несет ценности ни коду, ни пользователям. Встал вопрос о том, что нужно договориться об едином стиле кода. В своей команде я уже провела на эту тему несколько встреч в прошлом году, но для того, чтобы вынести это на обсуждение всех трех команд, нужно основательно подготовиться. Мы договорились с моим коллегой скрам-мастером/разработчиком, что он подумает, как с командами «вспомнить» Java conventions, мы дособерем все спорные моменты у остальных двух команд и через неделю проведем встречу, чтобы у нас были свои договоренности на этот счет. Придут новенькие — тоже не будут все меня на свой вкус, а рефакторить по делу.
Владелец продукта прислал сообщение, что у него возникла накладка по встречам, поэтом у планироваться начали без него. По идее, я должна была взять верхние истории из бэклога и принести команде, но в сообщении он прислал не все истории из бэклога. Что-то видимо появилось на выходных, поэтому я внесла по ходу. Он прислал подробную информацию о целях той или иной истории, которую он предлагает командам, о результатах, которые мы ожидаем получить. Как обычно, на первой части планирования у нас присутствуют по 2 человека от команды, мы разобрали и распределили все истории, а когда владелец продукта подошел, то вместе сформулировали цели спринтов и как мы поймем, что они буду достигнуты.
ДЕНЬ
Разбежались на планирование по командам, владелец продукта ходил от одной команде к другой и отвечал на вопросы. Мы опять запланировались так, что оставалось немного места, а так как другим командам помощь не была нужна, то мы взяли задачки из техдолга и некоторые из тех, что обсуждали на общем ретро. Я еще утром занесли все итоги встречи, также посмотрела, что команды добавили задачки с общего ретро в бэклог.
ВЕЧЕР
После планирования мы запустили спринт. Команды разобрали задачки, у меня появилось время, чтобы сделать домашнее задание после воркшопа в школе скрам-мастеров: составить канвас встречи, как занести инженерные практики в команды. Я выбрала ATDD, так как сравнив ее со всеми другими поняла, что она самая крутая, так как влияет и на качество кода (улучшает!), и на коммуникации внутри команды и с бизнесом (повышает!) и, как следствие, уменьшает time to market. Видимо, на следующий спринт буду заносить в команды. Участвовала в собеседовании разработчика, неоднозначное впечатление, думаем.
Вернуться -> 25 января (пт) / Далее -> 29 января (вт)
| Комментарии: |