вторник, апреля 29, 2008

Бардак, он везде бардак

Я с интересом читаю блог Джонатана Шварца (Chief Executive Officer and President
Sun Microsystems, Inc.) Несмотря на его достаточно очевидную маркетинговую составляющую, в нем проглядывает простая человеческая непосредственность (ну или может искусно имитируется).
Последний пост называется "Выбираем свободу" и суть его в том, что на одной официальной встрече Джонатан спрашивает одного большого CTO большой Компании, "а вы используете MySQL?" (Sun купила MySQL? так что он не просто так это спрашивает :). На что большой CTO отвечает: "Конечно нет. Мы используем другую известную и дорогую СУБД". А CISO добавляет: "Мы не можем использовать какой-то там левый MySQL, потому что мы очень серьезная контора!".
И тут оказывается, что разработчики этой большой и серьезной конторы вовсю используют MySQL, и только большие начальники об этом ничего не знают.
Тут Джонатан начинает рассуждать о том как важна свобода, и поэтому Sun это здорово.
А я подумал что бардак, он и в Америке бардак. А CTO и CISO что у них, что у нас предпочитают надувать от важности щеки вместо того, чтобы заниматься делом.

среда, апреля 23, 2008

Результаты опроса "В разработке какого типа ПО вы участвуете".

Опрос проводился с течении недели. В нем приняло участие 105 человек, из них 103 занимаются разработкой софта.
Разработкой софта на заказ занимаются 41 чел.
Примерно равное количество респондентов занимаются коробочным софтом и разработкой для Интернета (22 и 20 чел соответственно).
Внутренней автоматизацией заняты 10 чел.
Самым интересным для программистов - разработкой средств разработки, и инфраструктуры занимаются четверо человек.

В виде пирога это все выглядит вот так:


В общем довольно странные и неожиданные результаты, которые вероятно следует объяснить спецификой аудитории этого блога. Дело в том, что сам я в последнее время занимаюсь разработкой заказного софта, и это естественно отражается на тематике блога, и привлекает определенную аудиторию. LAMP разработчикам здесь не интересно, равно как и 1С программистам.
Потому что по моим оценкам, самая многочисленная группа программистов, это те, кто занимается внутренней автоматизацией в десятках тысяч фирм, контор, фабрик и заводов. А следующие по распространенности, по моему, должны быть сайтостроители. За ними оффшорники, вроде меня :). Затем те, кто делает коробочное ПО (+ игры). Ну и системщиков - инструментальщиков никак не больше чем один из ста.

Интересно, есть ли где ни будь более объективная статистика на этот счет?

P.S. Зеленый пирог испечен при помощи Google Chart API

среда, апреля 16, 2008

Версионный контроль кода в Agile

Интересная статья Хенрика Кнайберга (Henrik Kniberg) Version Control for Multiple Agile Teams на InfoQ.com

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

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

Как работать с версионным контролем когда на проекте несколько Agile команд? Как избежать хаоса при этом? Для чего делать брэнчи для релизов? Каких политик придерживаться при обновлении брэнчей? Как поддерживать код в транке в рабочем состоянии? Про все это и много другое Хенрик рассказывает просто и ясно, без фанатизма, по скандинавски :)
Есть и картинки, которыми истинные аджайлисты любят обклеивать стены офиса. Наподобие этой:


В общем, рекомендую почитать.

Образование и IT. Образование или IT?

Интересная статья в PCWeek профессора Шалыто "Сохраним в университетах лучших" на тему подготовки специалистов для IT вызвала довольно оживленную дискуссию.
Автор утверждает:

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


"Дальше я пояснил, что взяв на работу лучшего, компания получает конкурентные преимущества, а отрасль почти наверняка этого человека теряет, если человек этот, как, например, Дж. Гослинг, не предложит что-то очень важное для человечества в целом. Оказавшись же в университете на преподавательской работе, он может нести “доброе и вечное” другим сильным студентам, которые как раз и пойдут работать к вам в промышленность."


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


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

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

Действительно, уровень выпускников периферийных ВУЗов откровенно слабый из-за слабого преподавания, и тут надо что-то делать. В элитных университетах (МГУ, МФТИ, СПбГУ) дают хорошую системную, математическую и алгоритмическую подготовку, но нигде не дают нормальных знаний того, что относится к технологии программной инженерии. Все знают, что выпускники превращаются в хороших специалистов лишь через два, три года работы в реальных проектах.

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

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

Суперталанты не аннигилируют в индустрии. Тот же Гослинг и его команда пришли к созданию Java долгим и извилистым путем анализа реальных потребностей рынка, а не в тиши университетских лабораторий.
Специфика IT сегодня такова, что зачастую самые мощные инновации и исследования возникают вовсе не в университетах, а в индустрии, в последовательных центрах крупных корпораций и в маленьких стартапах. Это факт, и особенно актуально это для России. У нас нет инновационных учебных центров в области IT наподобие Университета Карнеги-Меллона или МТИ.

Наладить положительную обратную связь между индустрией и университетами для передачи инноваций и опыта, вот что необходимо. Что может подвигнуть успешных профессионалов заняться преподаванием? Деньги? Вряд ли, хотя без них тоже никак, успешный профессионал стоит дорого. Престиж, общественное признание? Пожалуй. И конечно, целенаправленные партнерские усилия компаний и университетов в области обучения. Пока на этом поприще замечены в основном крупные западные компании: Google, Microsoft, IBM. Они готовы инвестировать в обучение. Российские компании, если и рассматривают варианты партнерских отношений с учебными заведении, то в основном с позиций извлечения выгоды (продавать учебные курсы, "покупать" выпускников подешевле, поднатаскав их предварительно). Ну, видимо не созрели еще...

вторник, апреля 15, 2008

Хорошие истории

Ну до чего же американцы любят звучные акронимы! Kelly Waters в своем блоге пишет: "*Invest* in Good User Stories"
Нет, это не призыв инвестировать деньги в хорошие истории. INVEST это сокращенное Independent, Negotiable, Valuable, Estimable, Small, Testable - такими качествами должны обладать хорошие user story. И далее в шести небольших постах с картинками (так, Negotiable иллюстрирует огромная задумчивая горилла) Келли объясняет все эти качества.
Можно было бы добавить, что хорошие user story должны быть непротиворечивыми, полными и, как это сказать, user friendly, что-ли... Но тогда не получится красивое слово из первых букв. Но все равно - рекомендую почитать.

понедельник, апреля 14, 2008

Коллективное владение кодом

Сегодня с утра вы увидели что билд вашего проекта не собирается. В модуле логгирования кто-то изменил сигнатуру метода и теперь компилятор выдает 286 ошибок.

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

Знакомая картина, не правда ли? Если ваш проект достаточно велик, чтобы на нем работало более двух программистов, то подобные проблемы возникают постоянно и воспринимаются как обыденные и неизбежные. Причина их в политике владения кодом (code ownership), точнее в политике персонального владения кодом.

Такая политика весьма распространена и по большей части складывается стихийно. Проводники этой политики - менеджеры проектов. Менеджер распределяет задачи между программистами. Менеджер хочет чтобы ресурсы на проекте использовались с максимальной эффективностью (если кто не в теме, для менеджера ресурсы на проекте - это люди), поэтому он старается разбить систему на блоки (вертикально, по функциональным признакам, или горизонтально по структурным) и закрепить эти блоки за конкретными программистами. Работая над одним и тем же блоком, программист будет работать быстрее, потому что ему не надо постоянно разбираться с чужим кодом. Так думает менеджер, и он ошибается.
Политика персонального владения кодом возводит в разрабатываемой системе барьеры, там где их не должно быть. Барьеры, для которых нет никаких причин, ни функциональных, ни системных, кроме причин чисто субъективных, психологических и организационных. Потери времени на преодоление этих барьеров многократно превышают полученный выигрыш. Но если бы терялось только время... Часто бывает, что устав ожидать пока программист сделает нужные изменения в "своем" коде, другой разработчик дублирует этот код в "своем" модуле, разрушая тем самым структуру и целостность системы.

Избежать подобных проблем помогает политика "коллективного владения кодом", которая зародилась в недрах методологии XP. Как и все, что пришло из XP, коллективное владение кодом поначалу вызывает недоумение. Вот довольно типичная реакция:
"Ну не может такого быть, например, при разработке фреймворка, что каждый член команды мог править код каждого. То есть вот так пришел человек в проект — взял и изменил определение интерфейса под себя, а другой под себя — в итоге код просто расползется. Все-равно у каждого куска кода будет неформальный владелец, а остальные, максимум, будут править в нем какие-то банальные ошибки".


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

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

  2. При этом каждый программист несет ответственность за весь код системы.

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

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



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

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

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

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

  • Лучшие коммуникации. Каждый программист более менее хорошо знает всю систему. Нет таких ситуаций, когда из команды уходит программист и никто не знает что делать с частью системы, которую он писал.


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

Политику коллективного владения кодом можно применять не только в проектах выполняемых по методологиям XP или Agile. Важно только понимать, что она не будет работать без определенного набора "поддерживающих" практик:

  • Должна использоваться система контроля версий исходного кода.

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

  • Должны быть модульные тесты.


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

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

четверг, апреля 10, 2008

Опрос - в разработке какого типа ПО вы участвуете.

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

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

Сразу предвидя вопросы по поводу критериев разделения на категории, объясняю. Для выделения категорий я выбрал особенности жизненного цикла ПО. Почему? Потому что особенности жизненного цикла более всего влияют на процесс разработки. Даже более чем языки, платформы и технологии. Если языки и платформы влияют в основном на проектирование и кодирование (т.е. конструирование), то жизненный цикл влияет на все, на сбор требований, проектирование, тестирование, политику выпуска версий, поддержку, управление изменениями и т.д. и т.п.

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

Почему средства разработки и инфраструктура выделены в отдельный пункт? По идее, они попадают под определение «коробочное ПО», но есть один важный нюанс. Средства разработки и платформенное (инфраструктурное) ПО это не просто коробочный продукт, это инструмент создания такого феномена как «технологическое лидерство». Вокруг средств разработки формируются свои экосистемы в виде сообществ разработчиков, продуктов построенных на данной платформе, фирм производящий ПО и оказывающих услуги, и конечных потребителей. Классический пример - Linux, который сам по себе ничего не стоит, но служит фундаментом на котором миллионы людей зарабатывают деньги разработкой, продажей и поддержкой своих продуктов.

Итак, вот описание категорий:
Внутренняя автоматизация - программа создается для использования внутри вашей компании.
Заказное ПО – программа создается для использования внутри другой компании, по заказу которой вы ведете разработку. Это может быть ПО любого типа, важно что оно будет использоваться внутри одной конкретной компании и разрабатывается по их спецификациям.
Коробочное ПО – программа создается для широкого распространения, за деньги или бесплатно, среди различных пользователей, частных лиц или компаний. В этот разряд попадают все программы, у которых нет конкретного заказчика: десктопные приложения, драйверы устройств и утилиты, игры (в т.ч. и мобильные), офисное ПО, бизнес приложения (1С, Аксапта, Парус, прочие ERP, CRM, PLM, CAD/CAM системы).
Интернет-приложения – сайты, порталы, социальные сети и прочий Web 2.0, не зависимо от того, сделаны они на заказ, или для ведения бизнеса вашей компании (или вашего собственного бизнеса).
Средства разработки и инфраструктура – средства разработки, IDE, компиляторы, библиотеки, компоненты, базы данных, операционные системы, инфраструктурные сервисы, опять же, не зависимо от того, сделаны они на заказ, или для ведения бизнеса вашей компании.
Я только учусь – но когда выучусь буду разрабатывать ПО.
Я не участвую в разработке ПО – интересно, а как вы попали в этот блог? Можете отписать в комментах.
Голосуйте, интересно будет посмотреть результаты.
Свои частные мнения и предложения оставляйте в комментариях к данному посту.

Похоже, дождались.

Но близок, близок миг победы.
Ура! мы ломим; гнутся шведы.
О славный час! о славный вид!
Еще напор - и враг бежит.

А.С.Пушкин "Полтава"


Принято решение о выпуске релиза Entity Framework (and the Entity Designer) вместе с ADO.NET Data Services в составе первого сервиспака к 2008 студии. Visual Studio 2008 and .NET 3.5 SP1. Об это сегодня сообщила Elisa Flasko, Program Manager в блоге ADO.NET team.
Однако дата выхода самого сервиспака еще не определена. Принимая во внимание довольно значительное количество багов, выявленных в 2008 студии, думаю, что MS не станет тянуть с выпуском SP1.
Учитывая нелегкую историю создания этого продукта, многие до самого последнего момента сомневались в его выходе в свет. Похоже теперь это долгожданное событие наконец произойдет. Осталось немного подождать.

пятница, апреля 04, 2008

Да прибудет с вами святой Исидор. Аминь.

Сегодня День святого Исидора (покровителя Интернета).
Католический Cвятой Исидор Севильский (Isidore of Seville), епископ Севильский (560-636), получил известность не только благодаря своему благочестию, но и любви к наукам. Он автор одной из первых книг по этимологии, первым представил работы Аристотеля в Испании, был реформатором и человеком широких взглядов.

Святой Исидор считается покровителем учеников и студентов, а в 1999 году папа Иоанн Павел II официально назвал святого Исидора покровителем пользователей компьютеров и Интернета.


Даже не знаю, напиться что-ли в честь праздника?

Adobe Photoshop Express on-line

Adobe начала бета тестирование онлайн версии своего флагманского продукта Photoshop. Называется это все "Adobe Photoshop Express".
Просто поразительно, сколько времени понадобилось Adobe, чтобы додуматься до простой идеи объединить возможности двух своих продуктов Flash и Photoshop.
Получилось неплохо. Элементарные возможности редактирования изображений, хранимых в сети, при помощи flash в браузере. Там есть все что надо для придания фотографиям божеского вида. Такой-же набор возможностей редактирования есть, например, в Picasa. Так у меня с тех пор, как я стал пользоваться Пикасой, перевелись на компьютере все редакторы изображений. Мне, как непрофессионалу, хватает Paint-а и Picasa.
Photoshop Express позволяет все это делать в браузере, правда только с фотографиями загруженными в сеть. Весьма удобно.
Мне одно непонятно. Как на этом Adobe деньги делать собирается? Может кто знает?

среда, апреля 02, 2008

Vision

или чем знимается разработчик во время анализа требований

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

Но с другой стороны, прежде чем преступить к работе, надо понять, что же мы собираемся сделать. В среде Agile, бытует мнение что подобной проблемы не существует. Что делать решает заказчик. Что скажет, то и сделаем. Это прискорбное заблуждение. Во первых, как сказал один мой уважаемый читатель, "Клиент никогда не знает точно, что ему надо". Во вторых пресловутый коммуникационный барьер, с которым борется Agile, еще никто до конца не поборол. Заказчик рассказывает вам, что он хочет, вы интерпретируете его рассказы с позиции своей не компетенции, все это искажает картину.

Agile не отменяет анализ требований, он его усложняет. Усложняет тем, что не дает никакой внятной методики того, как это делать. Игра в планирование, из XP, это в большей степени планирование, чем анализ.

Для начала работы нам надо иметь видение - vision. В разных проектных методиках есть документ с названием Vision, но для разработчика или проектировщика vision - это несколько иное. Для разработчика Vision - это целостное видение проблемы, и путей ее решения. Заметьте, не будущей системы, а именно проблемы. Часто бывает ровно наоборот. Вспоминая, как начинались мои прошлые проекты, я всегда могу припомнить момент, когда менеджер или представитель заказчика говорил, "нам надо сделать систему..." и далее в одном предложении, что надо сделать. Это затравка. Молодой и неопытный разработчик клюет на нее как голодный карась, и уже через минуту он готов рассказать как он все сделает. Так когда-то поступал и я, пока не стал ленивым и флегматичным :) В этот момент в голове разработчика создается устойчивый стереотип. Потом, когда выяснится истинная сущность проблемы, этот стереотип может сыграть с нами злую шутку. Это классический пример того, когда дизайн бежит впереди требований. Потому я и говорю, что vision - это прежде всего целостное видение проблемы. Необходимо понять, суть автоматизируемого процесса, его смысл. Выделить сущности и их связи. Понять как будущая система улучшит процесс. В общем, обычный системный анализ, описанный во всех книжках.

Если вы можете описать заказчику сущность будущей системы в трех - пяти предложениях, значит у вас естьвидение. Запишите эту формулировку, она вам пригодится (например, хороший стиль - начинать с этой формулировки документы, описывающие архитектуру). Это уже синтез, о котором нигде не пишут. На этом этапе вы хорошо понимаете что надо сделать, и примерно понимаете, как это сделать. По поводу "как" у вас может быть полная ясность в случае простого типового проекта, или большие сомнения, если проект сложный или уникальный. Но в любом случае, это отправная точка, с которой можно начинать разработку. Заметьте, это далеко не 100% требований. Я затрудняюсь определить это число в процентах, может быть 20% (пресловутая пропорция 20/80), а может немного больше.

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

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

Второе, это proof of concepts (или, по русски, доказательство реализуемости). Почти всегда, в образе будущей системы есть такие мутные места, что не понятно как это сделать, будет это работать или нет. Лично меня они более всего раздражают. Proof of concepts нужны, чтобы понять, можно реализовать ту или иную фичу, и как это сделать. Подобно прототипам, proof of concepts снижают неопределенность на этапе анализа, но мы пишем их не для заказчика, а для себя. Это не должен быть кусок будущей системы, вы должны проверять только принцип, делать все максимально абстрактно. Выполнять proof of concepts поручают лучшим разработчикам команды. Опять же, полученный код лучше выкинуть. Дело в том, что часто в этом коде не проверяются входные параметры, не обрабатываются исключения и т.д., т.е. не соблюдаются стандарты и соглашения, по понятным причинам. Так что проверили, и выкинули :)

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

Вот так, итеративно дорабатывая прототип, устраняя сомнения по поводу реализуемости отдельных частей и создавая компоненты инфраструктуры, мы параллельно проясняем требования и детали будущей системы. В XP для этого есть термин нулевая итерация, в RUP это фаза Elaboration - анализа и проектирования (помните как на известном раповском графике в этой фазе нарастает активность выполнения :). Все эти активности плюс активное взаимодействие с заказчиком, а вовсе не груды Use Case и UML диаграмм, залог получения полных, достоверных и непротиворечивых требований. Впрочем, фиксировать требования тоже необходимо, но вовсе не для достижения просветления. Они вам потом понадобятся...

вторник, апреля 01, 2008

Google Cash - специально для россиян

Google шутит. Если в прошлом году речь шла о беспроводных сетях на базе комаров и Mosquito Lisp, то на этот раз Google решил постебаться над нашей страстью к наличным.
"Теперь вы можете установить портативный купюроприемник Google Cash прямо у себя в офисе или дома и вносить платежи за рекламу наличными рублями".

Купюроприемник, кстати, на картинке получился симпатичный :)