Максим Ганнутин

Моя статья Истории из практики TDD на сайте agilerussia.ru.

Случайно натолкнулся на презентацию из JPMorgan Chase: http://www.sei.cmu.edu/cmmi/adoption/pdf/jarvis-gristock.pdf

• В рамках одного проекта работает XP

• В итерациях - процессы CMMI, техники XP

• Между проектами работает SixSigma, для определения состояния дел и нахождения возможностей для улучшений.

Неожиданное сочетание. 

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

В первом приближении виден очевидный рост зарплат разработчиков. Некоторые небольшие компании вышли на порог интересности проектов.

Есть еще один взгляд из Штатов. Оффшор и аутсорсинг интересен прежде всего крупным компаниям. И СПб сложно конкурировать с индийскими разработчиками, которых много. Заказчиков очень раздражает частая смена работодателей индийцами, но эту проблему решают нанимая «целые деревни». В результате, зависимость проектов от персоналий становится очень низкой.

Интересно, перевод разработок в другие регионы России, поможет аутсорсингу хотя бы по первой проблеме?



 

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

• Формальной цели
• Проактивности

Цель

Были занесены в цели “оптимизация текущего процесса разработки”. Также еще более обобщенно и расплывчато: “do the right things”. Конечно все интуитивно понимают что на практике лежит за этими словами, но если оставить подобные формулировки, то у евангелиста есть серьезный риск впасть в грех узкой специализации: формальный метод может стать самоцелью. Описания техник могут казаться deliverables, хотя это не так.

Цель должны быть такая, чтобы она могла заставить сказать евангелисту сказать “стоп! Scrum не работает. Переключаемся на что-то другое.” Цель должны быть осязаемой. И в идеале должны быть возможность в реальном времени оценивать приближенность к цели.

У нас не очень эффективное и качественное производство. Может быть найден простой параметр который, пусть и однобоко, опишет наше качество. Например кривая багов? Улучшение этой кривой и станет целью евангелиста.

Есть мнение ,что “ С самого начала у нас нет базиса для того, чтобы строить формализованную систему оценки, контроля, методик и т.д. ”.

У нас нет, но у индустрии есть. Надо посмотреть.

Проактивность

“Я бы пошел по пути экспериментирования, чтобы для начала «почувствовать», как это работает в нашем коллективе”.

То есть в очередной раз мы просто пробуем. А значит напрягаться особо не надо, ведь это ”эксперимент”. Не получится – не страшно. То есть вкладываем какие-то усилия, инвестиции. Но так как у нас нет цели, мы не знаем – какие инвестиции минимально необходимы, не защищаемся от рисков. Это значит что любая неблагоприятная конъюнктура сделает попытку неудачной.

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

Может не плыть по течению, надеясь что занесет в теплые края, а наметить цель и добраться до нее осознанными шагами?

Будем искать конректику.

Недавно, в нашей компании обсуждалось состояние дел с процессами разработки. Неожиданно выявилось, что многие элементы процесса «провисают», процедуры выполняются не всегда и не всеми. Почему это происходит даже с грамотным project manager'ом и хорошими разработчиками?

Это происходит так как каждый занимается своим делом. Теоретически, это задача менеджера, но что происходит на самом деле? Руководитель проекта- это executive, человек корпоративный. Корпорации оцениваются по цифрам. Не важно спасает ли корпорация мир или это корпорация зла, на самом верху есть цифра «earning per share». Если копать глубже, разбираться с тем как эта цифра формируется, то получатся еще цифры, еще и еще. Но в какой-то момент должно появиться реальное наполнение деятельности компании, которое не всегда удается отразить цифрами.

Процесс и метод не должны подменять конечный результат разработок – продукт. Но «приподнятие» цифр за счет качества процесса является синдромом любого executive. Он тоже прав – нельзя же оправдать задержку релиза тем, что недели ушли, например, на «UnitTest mock» - на нем компания денег не заработает. Но и ясно насколько эти «срезания углов» вредны в долговременной перспективе, особенно в проектах живущих 5 и более лет.

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

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

• Максимально короткие сроки
• Гарантии выполнения этих сроков
• Если сроки работ не вписываются в бизнес-рамки, то проект должен быть отменен\приостановлен до основных затрат

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

Основная критика водопадной модели сосредоточена вокруг изменчивости требований: заказчики не имеют представления о том что им нужно. В нашем случае это не так. Функциональная спецификация продукта полностью задана предыдущей версией, ни о каком feature cut'е и речи не может быть. Весь функционал используется заказчиками, и нам нужен прозрачный для клиентов переход на новую платформу.

С другой стороны, нам нужны минимальные сроки отвлечения команды разработчиков от других заказов. Это достижимо только через тщательное планирование. За счет полной проработки системы на этапе планирования, ранних прототипов и исследований будет решена проблема лишнего кода. Этот оверхед кода и работ по его рефакторингу появляется из-за слишком маленького горизонта планирования в agile методах.

Таким образом наша компания согласилась со следующей последовательностью действий:

• До того как разработчики начнут производить код, должны быть высокие гарантии что проект будет успешен, цели достигнуты в запланированное время. Для этого небольшими силами проводится планирование проекта. Планирование с максимальной детализацией проводится для всего проекта сразу, в waterfall стиле.
• Если расписание работ покажет невозможность выполнение проекта, то он будет отложен
• После завершения планирования и позитивной оценки плана, начинаются работы по реализации, при этом используются некоторые agile техники, например UT.
• Как только ситуация потребует изменение спецификации, waterfall на этом и завершится.

Мы попытаемся воспользоваться теоретическими плюсами plan-driven разработок, но, на всякий случай, все будет готово к возврату в agile.

У каждого проекта есть свое начало, а есть и свой конец. Но иногда появляется возможность дать проекту второе рождение – переписать его с нуля.

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

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

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

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

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

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

 

Некоторое время назад, было принято решение об отказе от собственного сервера приложений и переходе на IIS\ASP.NET. Это иронично, что с радостью выбросив собственную платформу, ее PUSH модель событий и перебежав в лагерь REST, мы очень быстро столкнулись с потоком беженцев навстречу. Желание “Web’овцев” через хак, реализовать то что нам давалось так легко, и что мы так легко бросили, навивает на мысли об отсутствии счастья на земле.

Было проведено небольшое исследование реализации PUSH технологии в AJAX приложении на примере интеграции GTalk c GMail. Короткое изложение реализации выглядит так:

1. Есть коммуникационный iframe, который создает HTTP сессию
2. В HTTP сессии выполняется запрос на JavaScript
3. Все современные броузеры поддерживают прогрессивную загрузку, а значит как только подзагружается очередная порция скрипта, она выполняется.
4. Сервер ничего не пишет в этот канал до возникновения события.
5. Если пользователю пришло GTalk сообщение, в соединение немедленно пишется JavaScript фрагмент, содержащий все необходимые данные для работы AJAX кода в броузере.
6. Если ничего не происходит, сервер по таймауту пишет сообщение «Ничего нет»

Таким образом, клиент должен уметь обрабатывать приход контента по кускам, а веб сервер должен уметь держать соединение, сокет и поток.

Чем же хорош Comet, чем PUSH лучше POLL? Видимо это два пункта:

1. Для пользователя, это прежде всего повышение скорости реакции клиентского приложения на события, а значит и более комфортабельная работы в наших collaborative и monitoring сценариях.
2. Более эффективное использование ресурсов сети и клиентского приложения. Не будет постоянного шквала POLL запросов к серверу. А в нашем случае, еще и исчезнет необходимость гонять по сети ресурсы целиком, вернется возможность отправлять с сервера на клиент только измененные данные.

Первый пункт мне кажется более значимым. Но его важность зависит о характера приложения в котором задействован PUSH. В случае GTalk очевидно, что скорость получения клиентом сообщения очень важна, ведь это Instant Messaging.

Теперь рассмотрим очевидные недостатки, их три:

1. Реализация fault-tolerance становится сложнее. Клиенту необходимо указывать интересные ему каналы для прослушивания. В старом решении, мы использовали хранящиеся на сервере списки, которые клиент модифицировал запросами Subscribe\Unsubscribe. Необходимость в них отпадет если клиенты будут сами формировать списки и указывать их в качестве параметра в каждом «слушающем» HTTP запросе. Если сервер упадет и перезагрузится, клиент просто пересоздаст HTTP соединение и укажет в нем интересные ему каналы.

2. Работа а кластере становится проблемной. Ситуация, когда изменения данных обрабатываются на одном узле, а HTTP сессия клиента находится на другом узле, вполне ожидаема. Как в этом случае клиент получит сообщение об изменении данных? Вопрос открыт.

3. Возможны проблемы на стороне IIS\ASP.NET. Использование Comet подразумевает длительное время жизни сокета и треда на веб сервере. Скорее всего, последние версии IIS'a прекрасно справляются с этим, но нужно перепроверить.

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

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

• Уведомление клиентской программы о том произошло событие
• Передача дельты изменений

Сейчас мы выбрали POLL запросы, а значит уведомление будут приходить клиенту с точностью в 1-10 секунд, а изменившиеся ресурсы будут приходить на сервер целиком. Это не оптимальное, но заведомо более простое и дешевое решение.

Если требования по скорости уведомления клиентов резко возрастут, нам придется снижать время между POLL запросами. Возможно что ресурсы начнут очень часто меняться, и размеры этих ресурсов будут велики. Тогда и клиент и сервер начнут задыхаться из-за потока запросов и данных.

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

 

 

http://www.irishdev.com/NewsArticle.aspx?id=2166

http://www.xulplanet.com/tutorials/mozsdk/serverpush.php