?

Log in

No account? Create an account
Меня зовут Данила Турунтаев. Я работаю руководителем отдела разработки в одной софтверной компании. Разработкой программного обеспечения занимаюсь с 2006 года. Был разработчиком (преимущественно C++), team lead, с 2010 полностью перешел в менеджмент.
Интересуюсь всем, что связано с разработкой и руководством разработкой, люблю читать умные книжки и статьи на эти темы, а также посещать конференции. На эти темы и планирую писать здесь. И всегда буду рад их обсудить - так что добавляйтесь во френды и комментируйте :)

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

Кому интересно, можете заглянуть в прочие мои блоги:
http://danila-fizik.livejournal.com/
http://vk.com/turuntaevds
https://www.facebook.com/fizoid
Продолжаю выкладывать материалы с конференции Agile Days 2013.
Часть 1
Часть 2

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

Борис Вольфсон (HeadHunter) - Ничего лишнего: как вычистить свой продукт от лишних фич!

Все мы любим клепать фичи. В конце концов, вроде для этого и работаем, не так ли? Чтобы что-то создавать. Опять же, фичи красиво смотрятся в квартальном отчете.





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

Если речь идет о длительном проекте, то кроме разработки фичи в стоимость следует закладывать поддержку, которая состоит из:
- исправления дефектов
- выполнения мелких хотелок
- рефакторинга
- глобального рефакторинга (смена архитектуры, платформы)
- зависимых фич

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





При достаточно большом сроке жизни стоимость поддержки превзойдет стоимость самой фичи:





Из всего этого можно сделать два вывода. Во-первых, не надо делать лишние фичи.





С точки зрения Lean Startup (для подробного знакомства с этой концепцией стоит прочитать эту книгу) ТЗ - это набор гипотез. Гипотезы подлежат тестированию. Поэтому чем лучше мы прорабатываем ТЗ и чем больше туда закладываем - тем больше мы плодим гипотезы, а вместе с ними - и лишние фичи.

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

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

P.S. книга Eric Ries "The lean startup" - это однозначно must read. Сам сейчас читаю :)
Продолжаю выкладывать материалы с конференции Agile Days 2013. Первую часть можно прочитать тут.


Гойко Аджич - Reinventing software quality.

Этот доклад во многом перекликался с выступлением Паттона, о котором я писал в первой части. Аджич приводил довольно красочные метафоры по поводу процесса разработки. Попытаюсь воспроизвести.
Допустим, мы с товарищем выезжаем друг другу навстречу из Москвы и Санкт-Петербурга. При этом договариваемся встретиться в Великом Новгороде. И вот я, добравшись до Новгорода, звоню товарищу и говорю: "Я доехал, время в пути составило 6 часов, средняя скорость была 100км/ч". Является ли это хорошим результатом? Казалось бы, да. Но если я приехал вместо Великого Новгорода в Нижний - то это уже явно плохой результат, несмотря на то, что я ехал довольно быстро. Зачастую в разработке мы оцениваем velocity, некие story point-ы, реализованные за итерацию, но не особо пытаемся узнать, а туда ли мы "едем". Хороший процесс разработки должен работать как GPS-навигатор. Он строит маршрут, подсказывает следующее действие, а если мы сбились с пути - то перестраивает маршрут на ходу и, опять же, показывает следующее действие.

При работе со Story Map полезно составлять такие Mind Map:





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


Lightning Talk

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

Никита Филиппов (ScrumTrek) - Менеджер - глупая идея!
Менеджер - слово вредное, если все устроено так, что:
1. менеджер в случае успеха - единственный герой, в случае провала - единственный виновный
2. всё взаимодействие команды с заказчиком происходит через менеджера








От себя. На самом деле про ошибки менеджера из серии взвалить всё на себя или, скажем, о вреде микроменеджмента написано, кажется, во всех книгах по менеджменту, которые мне доводилось читать. И не только в IT-шных. Но иногда их как-то так представляют, что вроде бы всё это зло исходит от того, что не agile. А в правильном agile такого нет. На самом деле Agile, на мой взгляд, тут вообще ни при чем, менеджмент есть везде (просто называть его можно разными словами), в любом коллективе, где люди совместно решают одну задачу, появляется человек, который начинает что-то организовывать. Он может не быть "менеджером". Но ошибки менеджмента совершать уже может :)
Наблюдение 2. Далеко не всегда, к сожалению, участники команды так уж рады разделению ответственности. Работа над своим узким участком имеет большую привлекательность. Я хорошо написал свой код и со спокойной душой иду домой. Проект не компилируется? Ну правильно, Петя же не учел в своем коде мои последние доработки. А у меня всё работает. Вполне понятное желание - иметь свою узкую зону ответственности со своим блэк-джэком и шлюхами. Одна проблема: разработка софта так не работает :) И вот после погружения в Agile в голове может нарисоваться эдакий "ня-scrum" (картинка чуть ниже будет). Супергеройская самоорганизовывающаяся команда, которая разделяет ответственность, кросс-функциональна и т.д. и т.п. В реалии люди могут попытаться преобразовать Скрам в этакий регулярный водопад, в котором каждая итерация представляет собой каскад ТЗ-разработка-тестирование, и каждый стремится участвовать в одном и только в одном участке этого процесса.
Конец отсебятины.


Алексей Пикулев (Agile Technologies) - Управление рисками в Agile-проектах

Проблемы:
1. риски вырабатываются отдельно от команды, команда их не понимает
2. риски остаются на бумаге в уставе

Мифы:
В agile не нужно управление рисками

Действия:
- Выработать риски с командой
- Оценить денежный эквивалент (потери * вероятность)
- Занести реакцию на риск в бэклог, приоритезировать
- Проводить эту процедуру регулярно

Даниил Колесников(Объединенная компания Афиша-Рамблер) - Как перестать мотивировать персонал

Из доклада запомнился один интересный факт. В компании Atlassian регулярно выделяется день, когда все разработчики могут заниматься чем угодно (в рамках проекта). Независимо от бэклога, PO и других.





Стас Фомин (ROSALab) - Информационная алхимия

Надо использовать эффективные инструменты для взаимодействия! Особенно если у вас большая распределенная команда.
При освоении скрама у многих в головах рисуется самая радужная картина (тот самый ня-скрам :) ):





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





Демонстрация не всегда проходит увлекательно, интересно и комфортно для участников:





Стэнд-ап митинги тоже:





Общение проходит гораздо эффективнее, если его поставить на современную технологическую базу:
Google draw вместо флипчартов
Mediawiki
Mindmap
Seminar assembler
http://wiki.4intra.net/SeminarAssembler


Николай Алименков (XP Injection/ZoralLabs) - Портрет профессионального разработчика

Доклад был посвящен тому, что автор считает качествами, необходимыми для современного разработчика. Всё перечислять не буду (то, что более-менее очевидно). Перечислю то, что очевидно пока не всем.


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

Ну и забавные слайды:









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


Продолжение следует :)

Tags:

Сайт конференции: http://agiledays.ru/
Программа: http://msk13.agiledays.ru/program/
Место проведения: Digital october.

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

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

Ключевая мысль, которую я уловил на конференции, может быть сформулирована примерно так. Сами по себе практики Agile, конечно, хороши. Планирование, демонстрация, dayly stand-up meeting, continuos integration, и т.д. и т.п. - это всё классно. Но есть большой соблазн, сосредоточившись на этом всём, забыть зачем, собственно, мы занимаемся разработкой. Куда мы движемся? Совпадает ли это с тем, что хочет заказчик? Совпадает ли то, что нам говорит заказчик, с тем, что он хочет на самом деле? Без должного внимания к данным вопросам весь "agile" может свестись к подобному высказыванию:
- Раньше, без Agile, мы выдавали какую-то хрень раз в полгода :( Но теперь у нас есть Agile - и мы можем выдавать какую-то хрень каждые две недели! : )))

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

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

Jeff Patton - Co-making Great Products

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

Почему не работает водопад?
Слишком долго, требования меняются до завершения.

Оригинальная модель Ройса (автор публикации, из которой пошла водопадная или каскадная модель разработки) содержит обратную связь от каждого этапа к предыдущему:





Но большинство её знают в другом виде, без обратных связей:





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

Agile-процесс сам по себе не гарантирует успеха. "Раньше мы выпускали хрень каждые полгода, но теперь у нас есть Agile - и мы выпускаем хрень каждые 2 недели!"

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

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

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

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

В разработке дизайна должна принимать участие вся команда. Это не водопадный процесс, где мы говорим: "дизайнер, нарисуй эту вещь, принеси её нам и мы скажем тебе, почему ты не прав". Мы все рисуем!

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

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

Продолжение следует :)

Пост номер ноль

Я решил вести отдельный блог, в котором буду писать исключительно на профессиональные темы: разработка софта и руководство этим увлекательным процессом. Блог будет автоматом транслироваться на мои страницы на Facebook и Vkontakte, также будут "анонсы" в моем блоге danila_fizik. Кому интересно - добавляйтесь во френды, читайте, пишите комментарии - всегда буду рад обсуждениям :)

В первом посте будет конспект конференции Agile Days 2013. Продолжение следует :)