«То, что в первом приближении может очень походить на agile на самом деле может быть просто хаосом и способом траты денег, не имеющих четких целей и демотивирующих проектную команду.».

Алексей Кривицкий, тренер SCRUMguides

Гибкие (agile) методологии разработки ПО в последние годы активно набирают популярность. Они позволяют снизить риски проекта, уменьшить объем «бумажной волокиты» и попросту удешевить разработку.
Однако облегченность (например, в сравнении с «моделью водопада») этих методологий вовсе не означает, что их можно применять не разобравшись до конца в самой сути agile-процесса.

Данная история — пример хаоса, возникающего при неправильном обращении с agile-методологиями.
В прошлом году я участвовал в нескольких проектах, которые формально делались по методологии Scrum. Проекты были аутсорсинговыми, наш клиент продавал их своему клиенту как Scrum, соответственно, контракта с фиксированной оплатой не было, оплата шла повременная. Схема разработки была итерационной, каждая итерация включала в себя демо-версию продуктов и сессию планирования следующей итерации. Приоритеты требований менялись в зависимости от результатов демо. Так что же было не так?

  1. Начнем с того, что проекты были крупными и распределенными. Над одним проектом могло работать 35-45 человек, находящихся в разных офисах в разных городах в разных часовых поясах. Согласитесь, серьезное осложнение для процесса, где по канонам все должны работать в одном офисе (в идеале — в одной комнате), ведь живое общение — одна из основ agile-процесса: именно живое общение снижает уровень бумажной бюрократии.
  2. В первую очередь, наши клиенты восприняли Scrum с его ежедневными «стоячими совещаниями» как отличный способ получения отчетности (одна из величайших проблем крупного бизнеса в том, что отчитаться о проделанной работе часто важнее, чем эту самую работу качественно выполнить). Выглядело это так: каждый день для общения по телефону собирались руководители разработки из разных офисов и докладывали американскому руководству о состоянии текущих задач и дальнейших планах, после чего координировали работу со своими командами. Но у этих руководителей было по несколько групп разработчиков, а это в сумме — 20-25 человек на каждого... Реалистично отчитаться о задачах каждого из них — задача нетривиальная, потому к совещаниям вскоре подключили и руководителей команд. Даже для тимлидов не всегда было по силам досконально описать ситуацию в текущих задачах и способы ее решения, потому к совещаниям время от времени стали подключать и ключевых разработчиков. В итоге, большинство ключевых сотрудников стало отвлекаться на час-полтора каждый день, чтобы посовещаться. Это называлось «daily scrum» (который по правилам длиться должен не более 15 минут) и не могло не вредить общей продуктивности.
  3. Вскоре клиенты признали — такой подход не годится. Ведь больше всего о конкретных задачах проекта знают сами разработчики — значит они и должны отчитываться о своей работе, как это написано в книгах по Scrum'у. Но в команде проекта 30-40 разработчиков, притом, работающих в разных офисах, выслушать их всех и не потерять нить обсуждения крайне трудно. Выход был найден: вместо телефонных разговоров стали использовать групповой чат, логи которого всегда можно было перечитать. Но теперь уже не только ключевые сотрудники, но и вся проектная команда тратила ежедневно 1-2 часа на отчетность.
  4. Отчетность эволюционировала: когда стало понятно, что 1-2 из 8 рабочих часов ежедневно — это неприличная роскошь, схему пришлось изменить. Теперь разработчикам просто задавали подряд 3 классических для Scrum вопроса: «Что сделали за прошедший день?», «Что делаете теперь?», «Есть ли у вас препятствия на пути?», а разработчики должны были синхронно ответить на эти вопросы в чате. Больше никаких индивидуальных обсуждений... Позже американское руководство анализировало логи этих чатов... Зато все успевали «выговориться» за 15 минут. Было понятно, что подобные «daily scrum'ы» — чистый формализм, к счастью, разработчики воспринимали этот идиотизм с юмором.
  5. Впрочем, отчеты разработчиков вовсе не освобождали локальных руководителей разработки от собственных отчетов (еще более формальных) и за каждую итерацию, и за каждый день в отдельности. Я до сих пор не могу понять, где наши американские коллеги находили время для чтения всех отчетов.
  6. Все без исключений agile-методологии итеративны. В конце итерации (в Scrum они называются спринтами) мы получаем билд продукта, готовый к демонстрации. Создатели методологии XP предпочитают короткие итерации в 1-2 недели, Scrum — длинные в 1-2 месяца. Наш клиент решил сделать итерации максимально короткими — 1 неделя, то есть 5 рабочих дней. А иногда у нас бывали и микро-итерации — 2-3 дня... Клиент надеялся таким образом иметь больший контроль над процессом: ведь 1 неделя работы в неправильном направлении не так губительна, как две или даже четыре недели. Кроме того, если итерации недельные — значит и отчеты о результатах итерации можно получать каждую неделю. На практике же недельные итерации приводили к спешке: разработчики торопились, чтобы успеть закончить хоть что-то значимое в столь короткие сроки (впрочем, это скорее ошибка менеджмента), из-за чего уделяли минимум времени тестированию собственного кода. Осложняло ситуацию еще и то, что из 5 дней спринта реально на разработку оставалось всего 4, так как день уходил на «разворачивание» продукта, подготовку демо-версии и.т.п... Каждый новый билд кишел глюками и мелкими недоработками.
  7. Роль тестировщиков в agile-процессе до сих пор слабо освещена. Клиента это нисколько не смущало, потому тестировщики у нас не были интегрированы в процесс разраб
    отки, а разработчики — в процесс тестирования. Если демо у нас в проектах проводилось каждый понедельник, то тестировщики (находящиеся не в тех же офисах, где работали разработчики) приступали к работе над тестированием нового билда лишь во вторник. Сессии планирования (стоит ли рассказывать, что, вопреки принципам Scrum'а, рядовые сотрудники в них не участвовали?) у нас проходили по четвергам, тестирование последнего билда в это время все еще длилось. Таким образом, просто не получалось составить план следующей итерации так, чтобы сначала исправлялись глюки, а лишь затем разрабатывался новый функционал. Можно было лишь предполагать что-то вроде «40% времени мы потратим на исправление ошибок». Такой подход вел к неконтролируемому распространению глюков.
  8. Сами заказчики продуктов были удалены от проектных команд. Такой инструмент гибких методологий как «пользовательские истории» тоже не использовался. Таким образом, заказчики и конечные исполнители не находились «на одной волне» и нередко воспринимали одни и те же требования по-разному. А ведь это одна из проблем, которую должны решать гибкие методологии.
  9. Не было и «ретроспектив». В конце каждого спринта команды не собирались вместе, чтобы обсудить слабые стороны итерации и решить, как можно улучшить процесс: распределенная природа разработки этого не позволяла. Иногда такие вопросы обсуждались руководителями на сессиях планирования, но решались лишь локальные вопросы — глобальные (а их было большинство) требовали многократного утверждения высшим руководством в США и «повисали» на неопределенный срок.

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

В последующих проектах совместно с клиентом нам удалось изменить стратегию, мы масштабировали agile-процесс для работы распределенных команд, отказались от понятия «Scrum» и побороли большинство проблем, описанных в этой статье, что увеличило продуктивность работы в несколько раз. Хотите узнать, как мы этого добились, как внедряли изменения? — это тема следующей статьи.

«Сначала тебя игнорируют, затем над тобой смеются, затем с тобой борются, затем ты побеждаешь».

Махатма Ганди

Давайте мысленно вернемся в 2003—2004 годы: еще не существовало понятие AJAX, еще не было блога у каждой третьей студентки в большом городе, закругление уголков и зеркальное отражение логотипов еще не стало модной тенденцией веб-дизайна, а сайты с возможностью поиска одних пользователей другими еще не называли социальными сетями. В эти же годы со словом «фотобанк» в интернете ассоциировались Getty Images и Corbis.

Фотобанками пользовались и пользуются студии дизайна, рекламные и туристические агентства, издательства и многие другие, кому нужны фотографии на заданную тему, но не хочется (или нет возможности) нанимать для этой цели фотографов. В интернете фотобанки являлись логичной эволюцией информационных агентств вроде ИТАР ТАСС или Рейтерс.
Подход у этих служб был соответствующим: например, Corbis (основаный в 1989 году Биллом Гейтсом) не работал со сторонними фотографами, предпочитая все делать собственными силами, либо скупать традиционные информационные и фото-агентства. В Корбисе был целый штат аналитиков, следящих за мировыми тенденциями в политике, спорте, культуре, науке... и решающих, какие темы и стили фотографий будут наиболее ходовыми в ближайшее время. Наготове всегда был штат фотографов и моделей, светотехников, гримеров и костюмеров, экономистов и юристов. Если в Корбисе хотели снять фотосессию на медицинскую тематику — они просто арендовали настоящую больницу на ночь, привозили туда оборудование, моделей, часть декораций и проводили сессию.
Как видите, накладные расходы получались астрономическими, но фотобанки компенсировали это высокой стоимостью самих фотографий. Сколько я помню, 100-200 баксов за фотографию в низком разрешении считалось нормальной ценой.

На фоне этих гигантов возник проект iStockPhoto — фотобанк, являющийся посредником между фотографами и потребителями фотографий. Его цены были мизерными по сравнению со старшими братьями и составляли всего 1-20$ за фотографию. Большинство серьезных фотографов, игнорировали фотобанк, считая ниже своего достоинства продавать фотографии за 1-20$ (не считая комиссионных iStockPhoto). Игнорировали его и «старшие братья». Но фотобанк рос, набирая базу за счет любителей и средненьких фотографов.
Оказалось, что «любительские» фотографии тоже сильно востребованы и нередко оказываются по качеству не хуже «профессиональных» при значительно меньшей стоимости.
Вскоре бизнес-модель iStockPhoto стали копировать и появились новые фотобанки, такие как Dreamstime, Shutterstock (предлагающий абонементы вместо поштучной оплаты фотографий). Вслед за ними на рынок вышли Fotolia, StockXpert, BigStockPhoto... Этот тип фотобанков назвали «Микростоками» (Microstocks), и являлись они типичными представителями того, что сейчас принято называть «web 2.0».

Осенью 2005 года Киеве проходила презентация Zefa/Corbis. В это время я руководил разработкой Fotolia и, конечно же, хотел побольше узнать о конкурентах. Я спросил у представителя Corbis, как они относятся к конкуренции со стороны микростоков. Представитель улыбнулся и объяснил, что микростоки с их качеством фотографий не являются конкурентами Corbis и Getty Images.

Сейчас 2008 год. По данным Alexa iStockPhoto (проданый 2 года назад Getty Images) по своей популярности значительно обошел все остальные фотобанки — как микростоки, так и крупные. Затем идет Getty Images, с небольшим отрывом от нее следуют Fotolia и ShutterStock. Замыкает пятерку Corbis, запустивший собственный микросток — Snap Village.

Именно так энергичные стартапы побеждают «корпоративное зло», простые гибкие методологии разработки постепенно вытесняют бюрократизированные так же, как динамические языки программирования вытесняют статические.

Вслед за февральским обзором сайтов, прошедших через мою RSS-читалку, с небольшим опозданием публикую мартовский.

Успешно прошли

  • Блог Henrika'а Kniberg'а — лучшее из всего что видел за последний год по теме гибких методологий разработки ПО. Хенрик умещает все основы методологии Scrum в один mindmap, описывает схемы работы с системами контроля версий при итеративной разработке, интеграцию тестировщиков в agile-процесс и многое другое.
  • Микромаркетинг — очень приятный сайт о маркетинге и бизнесе. Все написано простым понятным языком. Прочитал этот сайт «от корки до корки».
  • Ukrainian SCRUM Portal — продолжатель дела Agile Ukraine. Наиболее качественный украинский сайт со статьями о гибких методологиях разработки.
  • Персональные вопросы — интересный блог о тонкостях работы кадровых отделов (в IT).
  • Интернет нового века — автор этого блога недавно выступал на семинаре Exception 07, его доклад мне показался поверхностным и непродуманным... в то же время его блог о разработке с использованием фреймворка Django оказался значительно глубже и статьи несут практическую пользу.
  • Блог об IT бизнесе — интересный и толковый авторский сайт об IT, один из лучших подобных сайтов, как мне кажется. Минус всего один — автор болен «синдромом блоггера»: пишет довольно часто, но разбавляет классные продуманные статьи откровенной халтурой. Если бы статей стало в 3 раза меньше и оставались только хорошие — стало бы гораздо лучше.
  • Дедлайн как стиль жизни — толковый менеджерский блог. Освещаются темы управления проектами, мотивации, самоорганизации и различных «лайфхаков». К сожалению, как и большинству других менеджерских блогов, этому не хватает одного — изюминки.

Не прошли карантин

  • Urbansheep — пишет только в LJ. Там его и читаю.
  • Amazing development — никакой активности вот уже месяц, думаю, сайт сдох.
  • GeoSpot — «много букф». И сайт явно рассчитан больше на туристов чем на путешественников.
  • Agile Ukraine — теперь все полезное идет на scrum.com.ua.
  • Аналитика Cnews — сухая подача материала из мира больших корпораций.
  • How To Change the World — уже пару месяцев от Гая Кавыасаки никаких практических материалов, никакой пользы.
  • IT и Бизнес, сайт превратился в помойку «корпоративных новостей» крупных компаний бывшего СССР.
  • Overclockers Software — новости о софте для виндовс больше не интересуют.
  • Алена C++, наверное, я слишком далек от мира C++ и компьютерных игр, потому что посты жены Сагалаева совсем не цепляют.
  • Блог про Google Apps — все это и так публикуется на Хабрахабре.
  • The Meanwhile — словил себя на мысли, что в последние месяцы читаю блог Ильи Бирмана «на автомате», а чего-то полезного для себя не нахожу.
  • Agile Dokuwiki — проект морально устарел на пару лет и почти не обновляется.
  • Sitepoint Blogs PHP — мало аналитики, много информации для новичков PHP. Мне такое не нужно.
  • Блогбастер — блог о блогах. Довольно слабый и с малым количеством собственного контента.
  • ITC.ua — сайт о компьютерах. С одной стороны новостей много и адекватных, с другой — тут вперемешку и новости «софта», и «железа», и интернета, что прилично раздражает, хочется читать только определенную тематику.
  • XHTML.RU — сайт о верстке. Ничего плохого, но о самых интересных вещах все-равно читаю на «Хабре».
  • У Wadа — об этом сайте я уже писал в прошлом обзоре. Увы, автор мешает интересные статьи о бизнесе, обществе потребления и.т.п. с историями «как я катался по Америке на авто»... последнего, к сожалению, больше.
  • GUI.RU — неплохой сайт о юзабитили, но все его материалы, как оказалось, дублируются на «Хабре», так зачем же плодить сущности?

Временно в карантине

  • Популярная веб-механика — довольно перспективный, на первый взгляд, блог о веб-разработках, но с мизерным количеством контента. Посмотрим: умрет ли сайт или будет жить.
  • SitePoint — известный ресурс о веб-разработках: дизайне, верстке, программировании, управлении проектами и маркетинге. Читаю его уже 4 года, но в последнее время толковых статей становится все меньше и меньше, в основном публикуют довольно поверхностные материалы уровня «для чайников».
  • Пепелсбей.net — сайт о верстке с приятным дизайном. Негатива не вызывает, но статей на сайте пока слишком мало чтобы сформировать окончательное мнение.
  • Антикорпоратив — интересный блог о бизнесе, корпоративной среде (вернее, о ее вреде), «лайфхаках». Наиболее полезен работникам больших бездушных компаний. Серьезно смущает, разве что, обилие ненужных картинок к постам.
  • Управление проектами в картинках — забавный менеджерский сайт. Картинки со схемами с него мне нравятся, а вот тексты — так себе...

В прошлом я пользовался разными «standalone» wiki-системами: WackoWiki, MediaWiki, DokuWiki, Confluence (по работе пользуюсь ей и сейчас).
Постепенно решил отказаться от использования standalone wiki в личных целях. Вначале перевел большую часть информации в Google Docs & Spreadsheets... Но вскоре выяснилось, что информацию в нем удобно редактировать, хотя ориентироваться в ней неудобно – D&S все-таки офисный пакет, а не wiki. Вскоре я нашел сервис WikiDot. Сервис показался довольно качественным, и через него можно было даже повесить wiki на собственный домен через DNS. Однако с удобством навигации в WikiDot явно прогадали: вместо иерархической структуры страниц авторы предпочли плоскую + теги... да и дизайн часто раздражал своей неаккуратностью.
В общем, я все еще искал альтернативу.

Около месяца назад в Интернетных Штучках написали о запуске нового сервиса Google Sites — и я решил попробовать.

  • Google Sites обладает приятным внешним видом, хотя и без изысков. На выбор дается несколько тем оформления. На мой взгляд, тема по умолчанию наиболее приятна.
     
     
  • Сама Google не позиционирует Sites как wiki, потому здесь нет wiki-разметки, зато есть удобный и функциональный WYSIWYG-редактор.
     
     
  • На выходе WYSIWYG дает HTML-код, который можно редактировать и вручную.
     
     
  • Текст на страницах можно размещать как в одну, так и в две колонки.
  • Sites может вставлять в страницы оглавление (table of contents) — это очень удобно, когда у вас в wiki находятся страницы с большим количеством разных подзаголовков.
  • Кроме оглавления, можно вставлять множество объектов из других сервисов гугла: Calendar, Docs&Spreadsheets, youtube, Picasa Web Albums...
     
     
  • На мой взгляд, это особенно удобно для вставки данных из Google Spreadsheets.
     
     
  • Также можно вставлять и гаджеты iGoogle — будь то прогнозы погоды, свежие ролики с youtube или новости сайта wired.
  • Система ссылок в редакторе хорошо продумана — в модальном окне можно выбрать внутреннюю страницу либо ввести внешний адрес.
     
     
  • Управление главным меню сделано схожим образом — из дерева разделов мы можем выбрать основные ссылки.
     
     
  • Помимо простых страниц, в Sites можно создавать страницы новостей «Announcements», файлохранилища «File Cabinet», страницы-агрегаторы типа «Dashboard» и страницы списков «List».
     
    Если с первыми двумя все понятно, то о последних двух стоит рассказать подробнее. Dashboard представляет собой страницу с несколькими местами для вставки гаджетов iGoogle и прочих внедряемых компонентов, как в меню «Insert» wysiwyg-редакторв. List позволяет создавать списки с разными наборами полей и сортировать их: это удобно для списков задач, покупок, сотрудников и.т.п.
     
     
  • Как и WikiDot, Sites можно прикрутить через DNS к вашему домену, правда, вас все равно перебросит на http://sites.google.com/a/siteaddress.
  • Есть в Sites и серьезные недостатки. Главный, как мне кажется, — невозможность изменить URI страницы: представьте, что вы создали страницу «GoodPage» — адрес для нее будет вида http://sites.google.com/a/siteaddress/sitename/goodpage/. Если сменить название, например, на «BadPage» — адрес страницы все равно останется прежним — http://sites.google.com/a/siteaddress/sitename/goodpage/. С русскими названиями страниц проблем еще больше — приходится сначала давать странице название латиницей для URI, а затем переименовывать на русский. Думаю, это ограничение в гугле ввели, чтобы упростить работу с деревом сайта, но с точки зрения пользователя оно очень мешает. Надеюсь, что в будущем ограничение уберут.
  • Второй серьезный недостаток — негибкая система прав доступа. Вы можете менять права доступа на разные Site’ы, но управлять правами конкретных разделов и страниц нельзя. Конечно, можно немного смягчить эффект, используя несколько «сайтов», например, публичный и частный. Но это всего лишь «костыль» и целиком проблему не решает.
  • Третий недостаток — продукт является частью Google Apps (for your domain), потому недоступен бездоменным.
  • Странно, что Google не внедрила в Sites такие свои сервисы, как Analytics и AdSense.

Итог

У Google (или JotSpot?) получился качественный и «человечный» продукт для малого бизнеса (для среднего и крупного бизнеса я рекомендовал бы Confluence) и частных лиц. Продукт, рассчитанный, в первую очередь, на обычных пользователей, а не гиков...
Сервис очень хорош — более удобной wiki-системы я не встречал, но советовать его всем и каждому не стану из-за мелких недоработок и ограничений функционала.

Приходит Петька к Василию Ивановичу: «Васильываныч, хочу быть тимлидом!..»

Неоднократно мне приходилось читать (например, на DOU), как при обсуждении той или иной IT-компании, люди хвалят или ругают работодателей за их отношение к профессиональному росту персонала: «Отличная компания, я пришел сюда разработчиком, а недавно стал тимлидом!» или «Лучше сюда не идите, в компании стараются брать руководящие кадры со стороны вместо того, чтобы повышать своих рядовых сотрудников».
Я успел побывать как в роли повышаемого, так и в роли повышающего. Потому уверен, что подобные заявления достаточно наивны. На самом деле, в большинстве IT-компаний (кроме самых маленьких) проблема состоит не в том, что расти программисту некуда, а в том, что «двигать» некого.

Работодатели

В принципе, любой работодатель заинтересован в продвижении проверенных сотрудников, а не в приглашении на руководящие посты людей со стороны. Притом, исходит он не из этических соображений, а из очень даже меркантильных: новый человек в команде — это отчасти «кот в мешке» — до конца не знаешь, что он собой представляет (в отличие от проверенного своего сотрудника) — вот почему и существует испытательный срок. Недобросовестный руководитель проекта или тимлид может нанести бизнесу гораздо большие убытки (даже в течение испытательного срока), нежели рядовой сотрудник. Именно потому, ради уменьшения рисков, стараются повышать своих, а не приглашать новых. Если же руководящие кадры приглашаются со стороны — это, скорее всего, означает, что руководство компании не видит достойных претендентов среди собственного персонала.

Что делать?

Итак, вы все-таки хотите стать тимлидом:

  1. Для начала подумайте, нужно ли вам это? Если вы очень любите программировать — знайте, что на программирование у вас останется гораздо меньше времени. С расширением полномочий уровень ответственности тоже увеличится: придется отвечать не только за себя, но и за всех членов своей команды. Стрессов станет побольше, особенно, в первое время и при сдаче проектов. А зарплаты тимлидов, замечу, не выше обычно, чем у ведущих специалистов.
  2. Вам придется научиться говорить «нет», проявлять твердость характера: кому нужен тимлид, которому сотрудники «садятся на голову»?
  3. Беритесь за организационную деятельность: неважно — будет ли это нечто связанное с текущими проектами, общим рабочим процессом компании или банальной организацией «пьянок» для сотрудников. Главное — чтобы это приносило пользу компании.
  4. Необходимо не только проявлять активность, но и брать на себя ответственность: подход «все пидорасы — один я д'Артаньян» вряд ли приблизит вас к поставленной цели.
  5. Помните, что ваше руководство — не телепаты: сообщите им о своем желании стать тимлидом. В этом нет ничего зазорного или унизительного. Зато руководство будет знать о вашей цели и может посодействовать — подсказать, чему стоит подучиться.
  6. Необходимо качественно выполнять свою текущую работу: если вы регулярно нарушаете дисциплину, срываете сроки и недобросовестны — вас скорее уволят, чем повысят.
  7. Постарайтесь заслужить уважение коллектива: если «коллеги по цеху» не считают вас профессионалом и приятным человеком — не воспримут и как реального руководителя.
  8. Очень важно хорошо говорить и писать. Как правило, в полемике выигрывает лучший оратор. Руководитель, слабый в дискуссиях и спорах, легко может растерять авторитет.
  9. Учитесь не только программированию, но и методам управления. Для этого придется штудировать, кроме книг по «паттернам» проектирования и языкам программирования, также книги и статьи по менеджменту, методологиям разработки, работе с рисками, несомненно, по человеческому фактору...
  10. Тимлиду в аутсорсинговой компании может понадобиться и свободное владение английским.

Такого набора качеств и действий, в принципе, достаточно, чтобы вас заметили и повысили.
Дерзайте!

Наверх