Михаил затронул интересную тему в комментах к предыдущему постингу: задачи и ответственность некого “руководитела команды”.
В частности он говорил о том, что все наши “неудачи” в начале процесса связаны с плохим “руководителем команды”, а если этого руководителя нет, то “и не удивительно” :)

Тема мне показалась интересной, а утверждение – спорным. В частности и потому, что “неудачи” были успешно пофиксены, а “руководитель команды” так и не появился. Просто мы стали командой. И всё.
Поэтому давайте рассмотрим, что же это за позиция такая: “руководитель команды”? Позиция, кстати сказать, весьма распространённая.

Итак, в чём заключается роль “руководителя команды” (они любят называть себя ПиЭм, поэтому я тоже буду использовать эту аббревиатуру, хотя это неверно).

1. Управление требованиями, приоритетами задач, функциональностью релизов.
2. Прямое руководство командой программистов.
   Программисты находятся в прямом официальном подчинении у ПиЭм’а.
3. Распределение задач между программистами, сроков выполнения этих задач, а так же отслеживание результатов.
4. Поддержка формальной методологии разработки ПО.

Вроде на этом всё. Рассмотрим по пунктам.

Начать хочется с пункта 4, как самого интересного :)
Интересного в этом пункте то, что формальные методологии процесса разработки практически умерли, доказав свою неэффективность.
Перефразируя Ладыженского:
”Умер RUP.
Это много страшнее других смертей.
Обалденно стою
Над потерей потерь.”

То есть, найти в применении что-то, что не-agile сейчас действительно проблематично. А Agile – это уже даже не методология, а процесс… Тот же SCRUM, пожалуй один из самых распространённых в мире процессов. Тот же канбан, который, видимо, набирает силу (но к которому я отношусь с подозрением). Всё это происходит от того, что издержки от “тяжёлых” методологий велики.

“Тяжёлые” методологии умирают. Об этом же пишет Том ДеМарко, один из основоположников всего этого дела и автор книги “Controlling Software Projects: Management, Measurement, and Estimation”. Он в своей статье прямо пишет:

“In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.”

В статье он называет самого себя “юным автором, которому нравились метрики” и заявляет о том, что всё это оказалось неверным.
Оригинал можно почитать тут: http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf
Перевод – здесь: http://bishop-it.ru/2009/07/softwareengineeringisdead/

В действительности, поддержка “тяжёлых” методологий – это достаточно большой и не нужный кусок работы.

Перейдём к пункту 3.
Имея на руках задачи (об этом позже), кто может сделать разбивку задач на технические “таски”, сделать оценку сложности работ, оценку приблизительного времени исполнения лучше, чем сама команда разработчиков? Некий “руководитель”, который придёт и скажет потом “Вася с Петей делают то-то, у вас неделя, Миша, Маша и Маня – вот это, у вас 8 дней”? Да не смешите, это не работает :) Но даже если это сработает с определенной поправкой (допустим, “руководитель” хорошо знает способности всех пятерых), то это всё равно не будет лучше, чем если бы это сделали сами исполнители.
К тому же, в подавляющем большинстве случаев, программисты знают код и архитектуру лучше, чем любой волшебный ПиЭм :) Поэтому оценки будут вернее.
Есть ещё один аспект: команда может перераспределять подзадачи внутри себя. Никакой “ПиЭм” ей для этого не нужен. А эффективность возрастает существенно по сравнению с тем, что Вася сидит и делает данный ему “свыше” таск – практика.

Кстати, о том, что “нет руководителя – неудивительно”. Когда команда принимает решение – это делает именно команда. То есть, несколько человек. В процессе обсуждения.
Если мы “выцепим” одного из процесса, фактически из той же команды, и заставим его одного принимать решения – риск ошибки и негативных последствий только возрастёт.

О контроле за процессом разработки. Тут даже говорить-то не о чем – весь контроль – это фикция, сводящаяся к назойливому ежедневному (хорошо если не ежечасному) “ну, как продвигается?”. Да невозможно узнать “как продвигается” лучше, чем знают это конкретные исполнители. И если дать возможность команде самоорганизовываться – она станет способна решать эти проблемы. Сама.

О пункте 2. Простой вопрос: зачем?
При отсутствии фигни из пункта 3 отпадает всякая необходимость и в этом.

Наконец, пункт 1.
Это очень важный и нужный кусок работы. Серьёзно. Но фишка в том, что он никак не связан с “руководством команды”. Это просто кусок работы, который должен кто-то делать. Этот “кто-то” не является руководителем, не находится ни выше, ни ниже тех же программистов и тестеров. Так же, как и последние две (программисты и тестеры), эти специалисты представляют собой независимую ветвь.
Важно: они ничего никому не приказывают, никакими программистами не руководят. Они организовывают требования, описывают их с точки зрения будущего продукта, определяют, в какой момент жизни продукта в нём должна появиться какая функциональность и т.д.
Поэтому этот пункт мы отбрасывать не будем.

Итак, у нас осталась разработка требований, которая с руководством не связана.
Теперь давайте посмотрим на типичную команду, имеющую “руководителя-ПиЭма”. Кто он?
В 90% случаев (я видел только таких, но пишу 90%, мало ли :)) это люди, которые работали сначала разработчиками, потом.. как это по-русски.. senior software developer, а потом типа “выросли” до ПиЭма. То есть – программеры-переростки :)
Что такие люди знают об управлении требованиями? Об управлении людьми (буде они таки собрались ими управлять)? Об управлении чем-либо вообще? Ни-че-го. Хорошо, если книжек про это почитают.
И это хорошо ещё, если этот человек таки действительно занимается требованиями. Ибо часто бывает, что требованиями занимаются другие, например, непосредственно менеджмент, или представитель заказчика, а такой вот ПиЭм является просто переносчиком информации (вопрос “как продвигается” остаётся в силе).

Теперь задумайтесь: “повышая” (а посути понижая) хорошего разработчика до такого вот “руководителя команды” мы:

1. Теряем высококвалифицированного специалиста.
2. Получаем неквалифицированного (низко квалифицированного) человека, занимающегося требованиями.
3. Вынуждены платить большие деньги этому человеку на новой позиции.
4. Теряем гибкость и чёткость работы команды именно как команды, а не как Васи, Пети, Маши, Миши и Мани, делающих то, что в данный момент велел “руководитель”. Поверьте, именно командная работа существенно улучшает конечный результат.
5. Увеличиваем риск ошибки (одна голова хорошо, но две – лучше). К тому же, та же самая голова никуда и не девается.

Скрипач не нужен…

Получается, что гораздо выгоднее перейти на рельсы самоорганизации команды, сделать её именно командой, вернуть такого программера-переростка на место, получив обратно +1.5 к programming skills в комманде.
А для работы с требованиями программист не нужен. Достаточно усердного человека, хорошо разбирающегося в офисе с минимальными навыками в программировании на уровне сделать запрос в ACCESS или простейший макрос на Office VB, чтобы просто понимал, что за магию творят другие :)
И станет он разбираться в продукте с “внешней” его стороны, и станет он распределять приоритеты необходимой для релиза функциональности, и станет он описывать требования ну никак не хуже вышеописанного ПиЭма. :)

Завтра – последний день отпуска. Неделя быстро пролетела. С понедельника возвращаюсь на работу.
Хочу пожелать себе в этой связи, чтобы я вернулся на работу, а багфикс там был уже закончен. Не люблю багфикс. Понимаю, без него не бывает. Но у нас ситуация особенная, можно сказать даже новая для меня: в самом начале проекта было допущено много ошибок. Организационных, методологических, всяких. В результате только с моего прихода в команду я переписал, наверное, четверть проекта – пытался построить архитектуру, с которой можно жить. Еще пара человек делали то же.
Но даже с учетом такого, иногда весьма серьёзного, рефакторинга всё это дело вылилось в несколькомесячный багфикс (в результате которого тоже было очень много рефакторинга).
Когда я уходил в отпуск неделю назад тучи уже практически рассеялись (потому и отпуск дали :)). Продукт работал, даже сроки не были сорваны.
Надеюсь, я вернусь – и всё будет хорошо. Можно будет работать дальше.

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

Вообще, на мой взгляд, основными допущенные изначально командой ошибками были:

1. “Сделаем это просто и быстро”. Любая задача решается “в лоб” без оглядки на какую-либо общую инфраструктуру, архитектуру, что бы то ни было. Проще написать спагетти-метод на две страницы, чем изобретать какую-то декомпозицию, API и т.д. Он будет работать здесь и сейчас – это нам и нужно.
2. “Будем думать только о реализации текущей задачи”. Программист получает таск (задачу) и делает её так, чтобы в максимально короткий срок выдать её решение. При этом человек не думает о том, насколько это решение укладывается в общую архитектуру, укладывается ли вообще и насколько просто/сложно будет потом это решение поддерживать. Сколько нужно усилий будет приложить потом, когда требования изменятся или расширятся. Как потом строить что-то поверх, имея в основе данное решение. Всё это приносится в жертву тому, чтобы поскорее поставить задаче статус “done” и объясняется тем, что “сделано быстро и просто, надо будет – просто переделаем этот кусок”.
3. “Решим конкретную задачу”. При этом такое “решение” совершенно не является решением. Оно является костылём. Как-то что-то подпёрли – вроде пошло дело. Что-то помешало – подопрём и это немножко с другой стороны. Работает же! О! очень не люблю фразу “работает – не трожь”. Есть основания.
4. “Кто делал эту часть?”. Люди, которые делают какую-то часть проекта. Другие люди не знают этой части, не знают, как оно сделано, почему оно сделано так, насколько оно вообще сделано (несмотря на статус “done”). Когда возникают какие-то проблемы или появляются новые требования, в команде возникает вопрос “Кто у нас делал эту подсистему?” и ответ “А это не я, это XXX” и задача автоматически делегируется этому человеку.
5. “Поставим костыль”. Очень похоже на номер 3, но поскольку это оооочень плохо и мы ооооочень много на этом накалывались, напишу ещё раз :) Внося исправление, программист видит, что там, в коде, не решение задачи, а какой-то бред написан (утрирую). Даже если задача попала ему в соответствие с пунктом 4. А уж если нет… При этом он, в соответствие с 2 и 3 думает: “А ну его нафиг! Щас вот тут подправлю, подфиксю – и будет работать”. И подфиксивает. И оно работает. До следующего раза. Потому, что решение так и не было предложено. Потому, что для того, чтобы получить решение, нужно много отрефакторить и много переписать. В результате, как показывает практика, хотя кода становится в полтора раза меньше, но времени-то тратится куда больше на то, чтобы написать это решение плюс повыкидывать те костыли, которые уже успели понаставить.

Сейчас эти проблемы в нашей команде можно сказать решены. Поздновато они были решены, но такова жизнь. За это заплачено достаточно большой потерей времени (можно было сделать раньше) и достаточно большими переработками всей команды (отчего и устал и ушёл в отпуск, и многие сейчас уходят).
И всё это вылилось, как я сказал, в несколькомесячный трудный, унылый, утомительный багфикс. Наша команда ошибки осознала и исправила (хоть и не осталось практически никого из “первого состава”).
Всем остальным от всей души советую этих ошибок не допускать, а если они есть – вырывать с корнем прямо с понедельника :)

Cебе желаю, чтобы багфикс к понедельнику благополучно закончился :)

Подписали билды Windows 7 и Windows Server 2008 RC2. Следовательно, релиз состоялся. По плану и даже чуть раньше. Прогнозы “аналитиков” о том, что делать будут “аж до хрен знает когда, раз Висту так задержали” не оправдались.

Ходил намедни по Сити в поисках приличных дантистов. Набрёл на “малоизвестное” место под названием Martin Place. Это в самом-самом центре Сити. Хотя живу тут уже год (год был 3 дня назад! ощущения такие, будто 5 лет, но при этом всё равно не привыкну никак), не был там ни разу. Как-то очень редко выбираюсь в Сити, а когда выбираюсь – то это обычно маршрут Town Hall <->Darling Harbor.

Красивое место, мне понравилось. Какое-то живое, чтоли. Чем-то даже на европу смахивает немного.
Сделал несколько кадров, впрочем не слишком удачных – начинался дождь…

Надо будет побродить ещё по этому району в хорошую погоду :)

Прислали ссылку: http://habrahabr.ru/blogs/silverlight/65191/

Почитал новость, потом комментарии к оной.
Самое смешное это, конечно, как всегда комментарии линуксоидов. “Я отнюдь не за распространение этой технологии”, как красиво и смешно сказано! Отож, призрак Microsoft маячит за “технологией”, ничего, что mono-ребята реализовывали всё open source и с нуля по спецификациям. И призрак этот ну просто откровенно мешает людям жить! Поэтому технологию, конечно, распространять не надо.
Смешно.

Причем проблемы себе создают сами.
- Попробуйте установить мунлайт? Работает.
- Какой дистрибутив, какой репозиторий?

Ужас. То, что в цивилизованном мире делается совершенно неподготовленным пользователем с помощью одного клика по большому баннеру “сильверлайт”, в однопроцентном мире требует знания понятий “дистрибутив”, “репозиторий”, понимания разницы между различными репозиториями и т.д. Ужас.

По-моему же проблема ситуация формулируется гораздо проще даже безо всяких допущений, сгребём всех в одну коробку: не работает на одном проценте клиентских машин, у пользователей которые всё равно параллельно установлена виндовс в качестве операционной системы, куда они и переключаются, устав от бесконечного “администрирования” (ух, Линукс настроил, а что с ним дальше делать?) для решения реальных задач (от “поиграть” до “курсовик допинать”).
Решение проблемы ситуации: да и хрен с ними! :) У кого заработает (как они говорят “руки из того места растут”) – хорошо, остальные – хрен с ними. Ибо их всё равно в разы меньше чем тех, кто тупо отключает Javascript в браузерах. Статистически, а статистика - вещь упрямая. Поэтому глупо притягивать за уши HTML5+JS к Сильвер/Мунлайту.

P.S. Про призрак. Недавно прочитал, MS планирует опубликовать в основную ветку ядра Линукса несколько тысяч строк кода различных дополнений. Интересно, эти чистые душою и идеологией люди перестанут пользоваться некошерной и осквернённой веткой ядра? :)

P.P.S. Поставил Silverlight 3 на Mac OS X. Просто, ради посмотреть, как оно там живёт. Живёт оно точно так же: нажал кнопарь – установилось. Отлично показываются видеоролики и всё остальное. Про “репозиторий” и “дистрибутив” меня никто не спросил. Всё просто работает. И, что показательно, выбор между HTML5+JS и сильверлайтом делать не заставляют.
Бедные однопроцентники, даже жалко их :) Мыши плакали, кололись, но продолжали есть кактус, не иначе…

Что получается...

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

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

Через год мы переехали в Бельгию. Мы с коллегой поселились в одном доме, в одном подъезде, с разницей в несколько этажей. Так у нас появилась собственная беспроводная сеть. Мы напополам купили роутер, оформили подключение на мой адрес. Это был 4-х (после двух лет стал 8-ми) мегабитный канал; по тарифу нам полагалось 15 гигабайт трафика. На двоих, но что делать с 7.5 гигабайтами ни я после Питера, ни он после Челябинска не знали. Однако "втянулись". Сначала старались выбирать положеную нам квоту, потом устали от этого занятия. Евро-другой ничего не меняют (а гигабайт "сверху" стоил как раз евро). Иногда приходилось доплачиват��, а иногда и нет. За статистикой уже никто не следил.
Потом коллега, узнав о моем переезде в Австралию, подключил себе собственный интернет, так что на нашу долю перепали все 15 гигабайт. Та же история. Прижились, иногда укладывались, редко - нет...

Переехав в Австралию я подключился на тариф, которого я даже не хотел. Шутка ли: 15 гигабайт дневного трафика и 20 гигабайт - ночного. Я говорю жене: "я понимаю, куда девать 15 дневного, но нафига нам 20 ночного?! Ночью я сплю!". Но выбор не велик, так и повелось.
Вот, живу в Сиднее уже без двух недель год. (Ого, год! Я еще от Бельгии не отвык, тут все еще в новинку, а уже год прошел! Вроде таааак тянулся, а тут бац!). Бывало, конечно, что трафика не хватало. Но редко.
А пару месяцев назад жена настоятельно предложила за дополнительные 10 долларов перейти на тариф "30 гигабайт дневного и 30 гигабайт ночного трафика". Я ей говорю: "Лена! Нафига нам в 2 раза больше дневного?! Солить, чтоли?! Про ночной я вообще молчу! 20 выбираем иногда - ну и хватает же!".
Значится, привел убедительные аргументы. Я же мертвого уговорить могу выйти из могилы и сплясать :)
Короче, полез я на сайт провайдера и перешли мы на этот тариф. Попутно я еще ползунок там нашел, регулирующий скорость... Стоял на половине.. Выкрутил его сначала на три четверти, потом полностью. Пусть. Сказано "аж до 20 с чем-то мегабит в секунду" - пусть будет.

Интересная штука - этот интернет. Расчетный месяц заканчивается у нас 13-го числа. На текущий момент скачано уже 92% дневного трафика и где-то 89-90% ночного.
Забавно. Получается, что ощущения удовлетворенности интернетом и потребности в его использовании от цифры не зависят. Адаптируются они к цифре как-то. Потому как при любом значении допустимой нормы она иногда перерасходуется, чаще не добирается...
А пользователь остается одинаково доволен! Во как...

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

Пока думаю о следующем:

1. Development Branch (Trunk/Main).
   Основная, с точки зрения разработчика, ветка. В эту ветку допускаются… check ins, commits, как это по-русски… “чекины” буду говорить. Так вот, в эту ветку допускаются чекины изменений, который с точки зрения разработчика готовы к тестированию. Кроме того, здесь фиксятся баги, найденные тестерами.
   Поэтому с точки зрения тестера эта ветка – самая нестабильная в проекте, первый этап.
2. Feature Branches (Trunk/<FeatureName>).
   Это ветки (“песочницы”, как любил говорить мой бывший коллега) разработчиков. Каждый разработчик, или группа товарищей, могут создавать себе таких веток столько, отпочковывая их от Trunk/Main, сколько им нужно. Предполагается, что в такой ветке идёт разработка какой-то фичи, новой функциональности. Когда разработчики считают, что фича готова, прошли тесты и код-ревью (у кого есть, завидую) и всё такое – они сливают свою ветку обратно с Trunk/Main, отмечают работу как “готова к тестированию” и фича переходит в руки тестеров.
3. UAT (User Acceptance Test) Branch.
   Бета, так сказать. Стабильная, уже с точки зрения тестеров, ветка. Как туда попадают фичи – отдельный разговор. Ну, например. В случае “классического” итерационного процесса (любой Agile) завершение итерации знаменуется достижением поставленных для данной итерации задач. “Достижение” – это когда фичи сделаны и тестеры довольны. И вот тут мы можем слить изменения из DEV в UAT.
   Либо же изменения вливаются “пофичево”. Фичу оттестировали на DEV – слили в UAT. Это требует больше усилий, правда. И иногда может оказаться не совсем возможным.
   Предмет разговоров, короче. Самое интересное место.
4. Release Branches (Release/<ReleaseName>).
   Стабильные, релизные ветки. Здесь всё просто: то, что прошло UAT время от времени назначается релизом. Например, когда достигнуты все цели, поставленные перед релизом, то есть, сделаны и оттестированы все необходимые фичи.
   Делается ветка для этого релиза, которая никогда больше не будет ни с чем сливаться, ни в одну, ни в другую сторону.
   Зачем тогда ветка? А просто потому, что там тоже могут оказаться баги :) Которые может быть нужно срочно пофиксить. И тогда это фиксится прямо в ветке текущего релиза. И никуда не сливается. Просто потому, что разработка идёт дальше и как сам баг, так и его фикс уже могут просто не иметь смысла в контексте текущей разработки.
   К тому же фикс в релизе может означать просто какую-то заглушку, какой-то, скажем прямо, хак. В то время, как в дивелоперской ветке этот баг, если он там имеет смысл, фиксится уже со всеми необходимыми рефакторингами и т.д.

С точки зрения “сливания” тоже получается, вроде, неплохо, однонаправленно.
Ветки разработчиков вливаются в DEV (хотя они могут и DEV в свою ветку слить, почему нет, это их право). Дальше всё строже: DEV сливается на UAT только в одну сторону. Поэтому с конфликтами тут всё очень и очень просто – их не должно быть, ибо никакой разработки в UAT не ведётся.

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

А как с этим у вас? Какие подходы применяются?