воскресенье, 23 марта 2014 г.

AgileDays'14

Зачетная футболочка :)
Сразу начну со слов благодарности организаторам. Никаких вопросов: отличное место, отличная организация, все удобно - конференция проведена на, не побоюсь этого слова, мировом уровне (а я был на конференциях и в Европе, и Штатах). Уверен, ни в одном из обзоров после конференции, ни в одном отзыве, не будет никаких претензий к качеству организации. ScrumTrek, вы молодцы!

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

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

По докладам: в этот раз записывал мало. Что отложилось в голове, то здесь и появится.

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

Поехали:
Начну с доклада. который сделал для меня эту конференцию. Как бы это не парадоксально звучало, доклад был последний в программе конференции :)
Кирилл Мокевнин "Формирование инженерной культуры". 
Кирилл рассказал про то, как с нуля сделал компанию, которая целиком соответствует его представлению о инженерной культуре. Все как в сказке: все через тесты, люди постоянно учатся, принцип "не знаешь - сделай доклад", новички почти сразу участвуют в собеседованиях очередных кандидатов. Кирилл хорошо относится к тому, что разработчики ходят на собеседования к конкурентам. Это позволяет им понимать свой уровень, компании не расслабляться. Итого: 3 года, с 1 до 40 человек, полное взаимопонимание и следование всем самым современным инженерным практикам. Да проблемы есть и радует, что Кирилл это понимает. Но очень позитивно к этому относится: будут проблемы - будем решать. Побольше бы таких драйвовых людей в нашей индустрии. Пока ни слайдов, ни записи нет. Уже есть! Как будут - смотреть обязательно!

Дальше по порядку:

Дэвид Андерсон в пиджаке и галстуке у меня не "пошел". Скучновато и не зажигательно.

Убежал с него на Асхата Уразбаева с докладом "Быстрое введение в Scrum и Kanban". Я не отношу себя к знатокам Scrum и Kanban, поэтому доклад очень пригодился как переключатель мозга на тему конференции. Самое то. Кстати, узнал как называются итерации в Kanbab: "каденции". Оказывается уже давно используется, а я как то не встречал раньше.

Вообще, Kanban сейчас модная тема и много докладов было ему посвящено. Перескакивая сразу на 2-й день упомяну доклад Димы Лобасева с историей про внедрение Kanban в разработку банковского ПО. 
Чистая практика, по пунктам.  Определение проблем, утренние стендапы (с участием распределенных команд), доска во всю стену. Итого: пока еще не классический Kanban, а protoKanban (нет, как минимум, ограничений по wip), но денег банк стал тратить меньше, а разработка стала двигаться. Но важна работа команды, вернее отношение команды к тому, что они делают.

Вернемся к первому дню. Ахмед Сидки рассказал про то, что нужно сделать чтобы трансформировать культуру крупной организации, как проводить изменения, как при этом учитывать Fixed & Growth Midset. Не буду пересказывать доклад и прогружать своими впечатлениями, надо просто потратить 50 мин своего времени и посмотреть слайдкаст (требуется регистрация в Penxy или FB). Рекомендую.

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

Приемы помогающие креативности (как оказалось у меня все записано :) ): 
  • Смотрим на привычные вещи новыми глазами
  • выходим из сумрака = выход из зоны комфорта
  • Open Space (как это не странно) может помочь
  • Отказ от наказания за нарушение стандартов
  • Пространство для экспериментов
  • "Мыслить решения" (имхо очень похоже на 5why)
  • Ненужные люди - это очень интересно. Люди которые как бы не нужны, могут способствовать креативности, за счет того что они думают иначе, идут против общего течения. (тут я задумался... реально так или я че то не так понял? Леша? - Леша ответил)
Слайдкаст уже можно посмотреть.
Саша Мартюшев с докладом про эмоциональную мотивацию - немного не дожал. Начало было интересное, и контент тоже. А дальше "солнца" не хватило. Доклад то был про эмоции.

Дальше еще была серия докладов по мотивации. Но... интересное мнение высказал Коля Алименков "чувак получает несколько тысяч долларов, а мы должны думать как его замотивировать...?!", похожее мнение от Леши Пименова "правильнее нанять уже мотивированных людей". Я соглашаюсь с обоими. Но если тема для вас больная, то дождитесь публикации записей докладов (кстати запись велась по технологии от Стаса Фомина, должно быть круто) и смотрите. Была и панельная дискуссия с вопросами-ответами по мотивации.

Аня предупредила, что тема сложная и многим не сразу дается. Мне не далось :) А то что у нас (в пост-СССР) больше распространен growth mindset - все хотят роста. Но мне кажется, что хотеть то может и хотят, но вот делать для этого ничего не делают. Надо посмотреть в записи. Пока вот слайды.

Сергей Прохоренко "Agile-спезназ" - худший доклад, я не дотерпел. Рассказывать про полезность Agile на примере орг-штат структуры и действиям американской армии, хмм. Неясно.

Антон Волков "Не согласен - До свидания". Антону было сложно после своего фиеричного прошлогоднего доклада. Планка была задана высокая. И я думаю, что доклад этого года не оправдал ожидания многих. Немного Антон не дожал. Первая линия: "проблемы коммуникации приводят к проблемам в организации". Вторая линия: "у организации должна быть четкая цель - и сотрудники должны ее понимать и принимать". Соответственно Антон у себя в компании, совместно в другими директорами, сформулировали цель. И часть сотрудников ее не приняла. Я сначала подумал, что ушли не рядовые сотрудники. Но потом, после общения с Антоном, оказалось что это были разработчики. Немного обсуждения здесь.




Асхат Уразбаев "#NoEstimates. Безоценочная разработка".
Интересная тема, но опасная - велик соблазн (я например не люблю оценивать), а косяки могут быть дорогими. Я решил, что лучше посмотрю доклад еще раз. Из запомнившегося: "Возможности и потребности уравняй свои", "Каждый делающий оценку знает какой ответ от него ожидают"
Без звука конечно сложно, но можно прицениться по слайдам. Основное что для себя отметил "если вы не являетесь узким местом, то можно попробовать не оценивать". Может попробовать? ;)



Коля Алименков "TDD для интеграции с БД"

Очень бодро и интересно. Крайне рекомендую, особенно если вы пишите на Java. Я только слюни глотал, глядя как ide сама пишет за Колю все, что нужно. Так реально можно писать тесты :) Коля рекомендует смотреть записи в его запасниках.









Вагиф Абилов рассказывал про приемочные тесты на базе спецификаций. Это и Cucumber, и  Gherkin. Интересно, советы тоже полезные. Кто задается вопросом читаемых тестов - вам в слайды , примеры и запись (когда появятся). В конце Вагиф исполнил караоке (я такое раньше видел только на докладах Роя Ошерова) на тему доклада.




Наташа Руколь "Гибкое тестирование"
Легко, непринужденно, интересно. Из полезного отметил про парное тестирование: когда разработчик и тестировщик вместе делают первый заход по готовой фиче. Отмечают явные косяки на бумажке, разработчик фиксит то, что нужно. Остальное уже потом, в ходе повторной проверки тестировщик заносит в багслог. Все материалы по докладу здесь.

Алексей Воронин "Legacy vs Agile Team"
История тут. Немного затянуто и решение выделить команду-мучеников на legacy-проект спорное. Радует, что баги там фиксят только наращивая базу тестов.

Не смог посмотреть, но благодаря Penxy хоть послушаю:

Тимофей Евграшин Ретроспектива: "посмертное вскрытие", "разбор полетов" или все-таки механизм постоянной адаптации? Penxy-слайдкаст

Макс Дорофеев Инструменты хорошей ретроспективы Penxy-слайдкаст

Еще слайдкасты по теме AgileDays'14 от Penxy.

Все видео-записи докладов тут и тут (с) Стас Фомин.

Хороший и обстоятельный отчет от Максима Цепкова.
Отзыв от Коли Алименкова
Отзыв Андрея Валяева

Лента в твиттере по хештегу #agiledays

суббота, 8 марта 2014 г.

Технический долг - бьем на части и ликвидируем.

Бери да помни! Не штука занять, штука отдать.
В последнее время очень часто обсуждается тема технического долга. Делается много докладов, пишется много постов, рисуется много графиков и тд, и тп.

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

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

Как только вы дали слабину и приняли заведомо спорное (или компромиссное) решение, вы должны отдавать себе отчет - ваш баланс стал отрицательным. И если в самое ближайшее время вы его не выправите, дальше будет все сложнее и сложнее выделить время, ресурсы, деньги (нужное подчеркнуть) на то, чтобы исправить ситуацию.
Дальше хуже: теория разбитых окон проявится во всей своей красе.

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

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

Давайте вспомним, что мы обычно понимаем под техническим долгом. Согласно классическому определению, данному Уордом Каннигемом (Ward Cunningham), технический долг - это разница между идеальным техническим решением и тем решением, которое принимается сейчас.

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

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

IT, по мотивам cartmendum
Долг реализации: сюда можно отнести то, что обычно и понимают под техническим долгом, на мой взгляд узко смотря на эту проблему. Приобрести этот долг можно и приняв неправильные архитектурные решения (вот тут аккуратно, очень скользкий момент), и добавив "костыли" в коде, и упростив процесс тестирования оставив там только "успешные" сценарии. Сюда же добавим и невозможность рефакторить исходный код, которая вызвана отсутствием тестов, что зацикливает эту проблему и вводит в клинч, когда все больше времени требуется на добавление новых фичей, потому что постоянно умирают старые. Очень ярко это отражено в твите (18+), читайте комменты - это просто песня. Я прослезился. Или наоборот "рефакторится" все направо и налево, а проверяют все это тестировщики ручками.

Долг технологический приобретается через отказ от применения новшеств в языках,
фреймворках, инструментах. У меня на глазах пример использования С++, когда часто можно наблюдать осторожность (мягко говоря) во внедрении С++11, когда отказываются от использования boost'a, когда продолжают писать свои мега-крутые "велосипеды" игнорируя open-source библиотеки. Все это приводит к замедлению разработки, снижению качества и даже к снижению мотивации у людей, потому что они используют "несвежие" инструменты.
Очень пересекается с Innovation Debt.

В кабалу процессного долга можно попасть отказываясь или затягивая принятие решений по применению Continuous Integration, XP-практик. Отсутствие веры, желания, понимания важности этого всего приводит к тому, что эти задачи, как правило с нижайшим приоритетом, накапливаются в списке общих задач. Потому что у нас всегда есть суперсрочные и суперважные для продукта задачи. И как следствие, только для того чтобы просто понять, что свежесобранный сетап не работает, приходится тратить от 10 мин до N часов (зависит от навороченности продукта).

Долг компетенции возникает из-за узкоспециализированной разработки, когда в команде есть человек(и) с уникальными знаниями. Это усугубляется отсутствием обмена знаниями или, хотя бы, обмена возникающими проблемами и принятым по ним решениям. Такое можно наблюдать в масштабе и целой компании, и даже маленькой команды. В итоге, принимаются решения заведомо неверные, которые у человека разбирающегося в вопросе вызывают дикое удивление. И это нас возвращает к долгу реализации. А если спец уходит, то вообще возникает вакуум и код, которые он суппортил, превращается в магический лабиринт из языковых инструкций, которые реализуют "нечто". К нему стараются не прикасаться без крайней необходимости, при первой же возможности к нему применяется паттерн "invented not here" и он помечается черной меткой под названием "переписать".

Обо все этом мы сможем с вами поговорить на конференции BitByte, 25 апреля в Питере. Приходите, буду рад пообщаться. В том числе и про способы ликвидации долга. Не дайте импотеке управлять вами! :)

Мой отчет с выступления. Там же можно найти много полезных линков на эту тему.

Пишите комментарии здесь, может я излишне пессимистичен или все усложняю :)

Слайды с аналогичного выступления на IT Global Meetup SPb


ITGM#4 Технический долг 2.0 from Maxim Shulga

Список материалов, которые могут помочь разобраться с этим вопросом подробнее:

Материалы с сайта Уорда Канингема:
Technical Debt
Видео с объяснением что такое тех долг от Уорда

Попытка посчитать сколько может стоить долг

Мартин Фаулер про техдолг

Интересная статья Сергея Теплякова

Про долг компетенции

Выступление Бориса Вольфсона на тему технического долга, очень рекомендую

Видео доклада про технический долг с AgileDays'14

Еще интересно про тех.долг

Про неправильные метафоры технического долга.

"Не тратьте время на отслеживание технического долга" - интересные мысли.

Сборник статей по тех.долгу

"Технический долг как избыточный вес"

Обзор состояния Agile-разработки за 2013 от VersionOne

Очередной обзор от VersionOne (pdf).
Цифры за последние 3 года +/- не меняются. Более подробная выжимка интересного за 2012 год.


Отзыв-конспект: Rework: бизнес без предрассудков

Еще одна интересная книжка от товарищей из 37signals: "Rework: бизнес без предрассудков" (есть еще обзор про Remote: Офис не обязателен)

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

Интересная книга, но из идеального мира. А может он где то такой и есть. Все же 37signals отметили свое 15-летие в феврале этого года :)

Читается очень легко.

А вот насчет пользы...Многие моменты хорошо легли в мое мировосприятие. Даже подозрительно легко. Может просто искал оправдание некоторым своим чертам, которые часто поддаваясь самокритике, не считаю правильными.

Скорее всего, это все отразилось и на том, что попало в мои заметки по книге. Итак, поехали.

Планирование.
"Если вы не предсказатель, то долгосрочное бизнес-планирование будет для вас не более чем фантазией". А, каково? :) Дальше все сводится к тому, что планы - это всего лишь наши догадки. (В этот момент мне вспомнился Талеб, с его Черным Лебедем.) А раз так, то надо просто прекратить тратить время на построение догадок. Планируйте дела на неделю, но не на год. Принимайте решения непосредственно перед тем, как начать действовать, а не задолго до этого.

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

Меньше говорите, больше делайте.
"Самая важная задача - это начать." Идея так и остается идеей, пока вы не начнете хоть что-то делать.

Игнорируйте детали на ранних стадиях
"Начиная что-нибудь проектировать, мы схематично набрасываем наши идеи на бумаге с помощью большого и толстого маркера вместо обычной шариковой ручки. Почему? У ручек слишком тонкие кончики." Это подстрекает вас к тому, что вы начинаете углубляться в детали, теряете целостность всей картины

Принять вызов - значит продвинуться вперед
"Когда это возможно, замените выражение «Давайте над этим подумаем» на «Давайте примем решение по этому вопросу». Отнеситесь серьезно к принятию решений. Не ждите идеального варианта. Примите решение и двигайтесь дальше." Очень хорошо.

Сначала всегда говорите нет
"Возьмите за привычку говорить нет даже многим из ваших лучших идей. Используйте силу слова «Нет», чтобы определиться со своими приоритетами."

Про силу веры
"Главное, чтобы ваш продукт нравился вам самим. Вы - тот, кто должен верить в него больше остальных. «Я думаю, он вам понравится, потому что он нравится мне» - вот лучшая рекомендация, которую клиент может услышать от сотрудника компании." Черт возьми, как это актуально!

Наращивайте аудиторию
"Создавайте свою аудиторию. Рассказывайте, публикуйтесь, ведите блог, пишите в Твиттер, снимайте видео… все что угодно. Делясь ценной информацией медленно, но верно, вы обязательно создадите лояльную аудиторию. А затем, когда вам потребуется, чтобы о вас услышали, нужные люди уже будут готовы слушать"

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

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

Вы не создаете культуру
"Не насаждайте ее. Культуру невозможно установить. Как и хорошему виски, ей требуется время, чтобы настояться."

Вот вроде и все. Удачи всем и больше читайте :)

пятница, 7 марта 2014 г.

Анонс: "Remote. Офис не обязателен"


Не так давно, я писал отзыв по книге "Remote: Office Not Required".

Скоро, благодаря издательству "Манн, Иванов и Фербер", эта книжка появится и на русском языке.

Покупайте и с удовольствием читайте.