Archive | March, 2008

О некоторых ограничениях в Agile

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

Владимир Машков «Как я был вундеркиндом»

«Люди – самая большая ценность» – именно эта идея изначально заложена в фундамент практик Agile, и наверное потому Agile нравится людям :-)

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

Ограничение номер один – участники команды должны обладать личностной зрелостью. Что это такое? Поиск в Яндексе вернул ссылки (в первую очередь) на статьи про личностную зрелось: а) родителей б) детей в школе и студентов в) педагогов и г) психотерапевтов. В принципе, неудивительно, потому что термин сам по себе активно эксплуатируется психологами. Психологи сосредоточены на работе с родителями, их детьми и вообще с подрастающим поколением, конечно же много внимания уделяется учителям ну и собственно самим психологам и смежным специальностям ибо “medice, cura te ipsum”. Однако нам ничего не помешает повзаимствовать и принять в обиход ёмкий термин «личностная зрелость» из психологии – пусть и, казалось бы, столь далёкой от IT.

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

Второе ограничение – участники должны обладать еще и профессиональной зрелостью. Можно подумать, что речь идет о глубоких познаниях тонкостей современных технологий? Увы, это не совсем так. Строго говоря, это совсем не так. Например, у студента-отличника медицинского ВУЗа третьего курса, вероятнее всего, имеются прекрасные знания в нормальной анатомии, и он, будучи разбужен ночью, наверняка выдаст вам всё про бугорки и ямки os pterygoidea (крыловидной кости), но. Но вряд ли найдутся желающие обратиться к нему за помощью, случись у них ангина или о. бронхит. С другой стороны, пользующийся заслуженным уважением доктор повседневно решает проблемы посерьезнее о. бронхита, и вот тут я готов спорить – доктор не помнит назубок все тонкости строения той же крыловидной кости! Нашему доктору помогает в работе нечто другое. Я определил бы это другое как совокупность эрудиции, интуиции и профессионального опыта, что порождает способность решать проблемы (сразу вспомнился мистер Вульф из “Криминального Чтива” :-) Шучу…)

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

Так вот: зя! Позволю себе напомнить – в Agile нет разработчиков, тестировщиков, аналитиков и архитекторов, и здесь каждый должен уметь проектировать, программировать И тестировать так же хорошо, как он программирует и проектирует! В противном случае начнется специализация. «Пойду поговорю: зачем наши девелОперы такое учудили…» «Ну я ж не знаю как там это у вас у тестеров происходит…»

«Специализация – удел насекомых» (с) Р. Хайнлайн

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

Read full storyComments { 0 }

Просто ли делать Agile?

Agile, особенно SCRUM – отличный способ организовывать разработку. Agile прост и элегантен, быстр и дешев. Он позволяет делать продукты, максимально близкие к ожиданиям Заказчика. Но это сложно. Да, это сложно! Первая статья в серии про agile – почему это не так просто, как кажется. На очередной выездной сессии обнаружил у коллег страшное заблуждение – многие считают, что agile – это очень просто, гораздо проще чем например RUP. И раз это очень просто, то делать agile в распределенной среде – это тоже очень просто. Караул! Разбираемся по порядку – первая часть заблуждения: agile – это очень просто (про вторую напишу отдельную статью). Давайте будем мыслить инженерно. У всего на свете есть смысл (даже если кажется, что его нет). В чем смысл Менеджера Проекта? Команда проекта делает продукт «софт». Зачем нужен менеджер? Поставить (произвести) процесс. Соответственно «процесс» – это продукт, производимый Менеджером Проекта. Соответственно чем процесс легче, мощнее, быстрее – тем он лучше: тем совершеннее будет «софт». Дальше – отделим процесс как продукт от его «производства». Соответственно производство должно быть простым, легко организуемым, не требующим большого объема знаний (в таком случае говорят, что производство технологично). За «производство» продукта «Процесс» отвечает Менеджер Проекта. (см. Иллюстрацию ниже – команда производит продукт по процессу, менеджер производит процесс для команды (или помогает команде его произвести).

Рис. 1. Команда делает софт, Менеджер делает процесс, по которому делается софт. А теперь внимание. Посмотрите на картинку внизу – что проще?

Рис. 2. Какой из этих двух усилителей проще?

Микросхема – устроена просто, легче, удобнее, быстрее, мощнее. Как продукт она безусловно совершеннее. Ламповый усилитель – устроен сложно, тяжелее, неудобнее, медленнее, слабее. Как продукт он безусловно хуже. Понимаете, о чем я говорю? Результирующий продукт микросхемы – эффективней по всем параметрам, но чтобы произвести его, требуется гораздо большая сумма знаний, технологий и оборудования. Agile – он как эта микросхема. Он отличный, замечательный – но в состоянии ли вы его сделать своими руками? Традиционные итеративные подходы – они почти всегда хуже. Но зато у них есть огромное преимущество – ламповый усилитель вы при желании легко соберете дома. Тот же RUP предоставляет вам кучу шаблонов, заготовок, «хауту», примеров и указаний. Так что получается что agile – да, во многих случаях он лучше. Дешевле и эффективней. При условии, что вы обладает набором необходимых знаний, технологий и оборудования – иначе попытки его использовать – это бесплодные фантазии. То есть для того, чтобы agile заработал, вы должны иметь быть в состоянии его запустить – а значит, обладать большими, нет, БОЛЬШИМИ знаниями во всех областях, связанных с его запуском. В первую очередь это управление ожиданиями заказчика, работа с требованиями, SCM, тестирование. Ну и конечно – плюс требования к знаниям команды, Заказчика и конечно – технологии. Мой совет – пока не научились работать традиционным итеративным подходом и давать устойчивый результат – не трогайте agile. Разберитесь в принципах работы усилителей и соберите простейший – прежде чем пытаться создать ультралегкие новинки. И еще одно – не используйте слово agile для обозначения бардака. Потрудитесь открыть любую книжку по любому agile-методу – там есть довольно большой требований, которые нужно выполнить, чтобы вы могли сказать «мы работаем по XP» или «мы работаем по SCRUM». Это не я говорю, это слова Бека и Швэйбера.

Материал с www.seadmex.ru

Read full storyComments { 2 }

Процесс разработки проекта становится гибче

Некоторое время назад у нас начался большой проект, который потребовал внедрения новых методик работы. Классический “водопад” не может обеспечить быстрое и безболезненное внесение изменений в проект. А это плохо. В условиях не четко поставленной задачи (а она и не может быть четко поставлена) требуется быстро вносить изменения, дополнения, новые требования клиента.

Похоже, что работа над подобными проектами, а также просто работа с разнородными задачами клиентов убеждает меня в том, что я бы не осмеливался сказать еще пару-тройку лет назад:

написать большое и всеобъемлющее ТЗ на крупный проект не реально.

Т.е. я хочу сказать, что это или не реально сложно или вообще не реально. Да я писал большие толстые ТЗ, которые описывали с точностью до запятой, как должен работать сайт, где у него какая информация и на какую кнопку надо нажать и вписать, чтобы он сообщил: “Такой формат e-mail недопустим”. (more…)

Read full storyComments { 0 }

Разработка через тестирование

На первой встрече Agile.by было задано много вопросов по тестированию. Я нашел замечательную презентацию, которая может прояснить многие моменты TDD. В презентации также делается обзор средств для написания модульных тестов на различных языках: PHP, Ruby, Python, Java, Perl, C/C++.А вот и сама презентация:

[slideshare id=181371&doc=test-driven-development-tutorial-11961285135562-4&w=425]

Для “погружения” в тему можно прочитать книгу Кента Бека “Экстремальное программирование: разработка через тестирование”.

Read full storyComments { 12 }

А вот кому backlog в Excel! :о)

Рано или поздно приходит мысль, что пора перейти от стопки бумажных карточек к цивилизованному бэклогу в Excel или Calc. Переходим. Получаем автофильтры, суммирование эстимейшнов и всякие другие вкусные и полезные вещи.Но! Теряются сами карточки, исчезает физический объект торговли. При общении с некоторыми заказчиками это может быть фатально :о)А вот этот эксельный бэклог позволяет вести  бэклог в Excel, но одним кликом печатать бумажные карточки. При необходимости его можно легко подсоединить к Windows SharePoint Services и поиметь еще и веб-интерфейс. Чувствуете мощь?  :о)

Read full storyComments { 10 }

Приглашаем авторов!

Если у тебя есть что сказать и показать – то добро пожаловать! Стесняешься выступать публично? Это достаточно легко и приятно, так мы все очень благожелательно настроены :o )Если хочешь, то перед тем, как говорить, то я с удовольствием устрою для тебя мастер-класс и мы отработаем твое выступление :o ) Пиши мне на dpetelin@gmail.com.

Read full storyComments { 0 }

Привет участникам первого сбора! :)

Привет всем!

Итак, обещанный комплект материалов:

  1. Тем, кто хочет краткую вводную в SCRUM, внятную и без булшита, рекомендую идти сюда.

  2. Тем, кто хочет проверить, делает ли SCRUM, либо он делает что-то еще, рекомендуется следующий чеклист.

  3. А это обещанный Project 2003 Tool: Scrum Solution Starter. Для тех, кто пользуется Team Foundation Server, есть специальный плагин eSCRUM, который ставится прямо на TFS.

  4. Это обещанный тэпмлейт из проджекта. SCRUM – пример MPP-файла

  5. А это презентация с моего доклада. Собственно презентация

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

Read full storyComments { 0 }