Archive | Жизнь RSS feed for this section

Встреча: AgileEE Retrospective

17 октября в 19:00 состоится встреча сообщества Agile.by, посвященная прошедшей конференции AgileEE. Видео некоторых выступлений и презентации уже доступны на сайте конференции.

UPD: Встреча пройдет по адресу: Минск, Революционная, 11, 3й этаж, комната 303. Помещение “Инфопарка”.

Но есть люди, готовые встретиться, рассказать, подискутировать на темы, прошедшие на конференции.

Наш докладчик:

imageНиколай Фролов, EPAM Systems.

Планирует рассказать:

  • Обзор докладов на Agileee. Тренды Agile сообщества
  • Подробно о докладе – Agile Testing by Elisabeth Hendrickson

Регистрируйтесь на мероприятие (коллеги, кажется я обфакапился и забыл вставить в предыдущую форму e-mail – не могу отправить вам письмо с подтверждением…):

Read full storyComments { 2 }

Agile.by: Новый сайт, новые встречи

Камрады, в октябре пройдет 2 встречи сообщества Agile.by.

Первая встреча: AgileEE Retrospective

UPD: 17 октября

Буквально 2 недели назад прошла самая громкая agile-конференция в восточной Европе AgileEE. Говорят было интересно. Будет интересно послушать, куда движется agile-мир.

Докладчик-декламатор: Николай Фролов, EPAM Systems. Наш постоянный участник.

Ездили? Хотите рассказать? Обращайтесь, включим в программу.

Регистрация на мероприятие | Страница мероприятия на Facebook

Вторая встреча: I’m agile!

27 октября

Читая тренинги по Scrum, общаясь с командами я заметил, что есть те кто берет и работает по agile, есть те кто морщит лоб и нудит о том, что это какая-то модная идиотская хрень. Agile подходит не всем проектам, agile подходит не всем командам и не всем разработчикам.

Хотите присоединиться? Обращайтесь, включим в программу.

Регистрация на мероприятие | Страница мероприятия на Facebook

Ах, да, кстати…

Мы переделали сайт.

  • Теперь он новый, светлый и скоро появится новый логотип.
  • Теперь вы можете оставить свой комментарий, воспользовавшись своим аккаунтом в Facebook или Twitter.
  • Подпишитесь на рассылку (форма справа в сайдбаре) и получайте новости сообщества и agile-мира
UPD: Исправлена ссылка на регистрацию на AgileEE Retrospective. Сейчас работает. 
UPD2: Встреча AgileEE Retrospective состоится 17 октября.  Пожалуйста, регистрируйтесь!
Read full storyComments { 0 }

Благоприятное время для развития

В преддверии Форума SEF.BY-2011 его организаторы делятся ожиданиями о реалиях и перспективах белорусской софтверной индустрии. Нашими собеседниками стали президент и председатель Совета директоров компании EPAM Systems Аркадий Добкин (А.Д.) и директор по развитию бизнеса Itransition Иван Левченко (И.Л.).

Обращение Аркадия Добкина к участникам Форума

В чем отличие этого форума от предыдущих?

А.Д.: Безусловно, организаторы стараются каждое следующее событие сделать лучше, вынести из уроков предыдущего что-то важное для аудитории. Я ожидаю, что в этом году уровень докладов будет выше, а сами доклады – интереснее. Если раньше доклады собирались достаточно сложно, то в этом году часть исключается из списка, потому что невозможно всё включить в программу, что отражает и уровень интереса, и значимость события для самих специалистов. Другим отличием становится то, что многие компании, EPAM в том числе, привозят докладчиков не только из Беларуси, но и со всего мира – Америки, из Европы, России и Украины.

И.Л.: Если говорить о количестве и составе участников – Форум, безусловно, повзрослел. Если бы положительной динамики не было, то не было бы и такого конкурса среди докладчиков, не было бы такого интереса со стороны аудитории. Так получается, что Форум посещают, в основном, люди достаточно опытные, знаний которых уже достаточно для того, чтобы они прямо сейчас выполняли свою работу качественно. Хотелось бы видеть среди его участников большее количество студентов и тех, кто только начал свои шаги по карьерной лестнице в сфере ИТ. Мне приходилось наблюдать за работой программного комитета при отборе докладов, и нужно отметить серьезный уровень обсуждения. Количество докладов, не принятых для выступления, было значительным – в случае даже минимальных сомнений в том, что предложенное выступление не будет интересно большей части аудитории, оно тут же отдавалось на доработку.

(more…)

Read full storyComments { 0 }

“Хрен и палец – это одно и то же!”, или тэйлористам аджайла посвящается

clip_image002

Любопытное дело – среди людей, которые попробовали работать в true agile компаниях типа FogCreek, не остается равнодушных – и загадочным образом всем нравится! Но есть другой лагерь – тех, кто однозначно уверен, что аджайл – это сакс, новое модное слово которое прикрывает все те же старые добрые приколы – овертайм, выходы в субботу, меняющиеся требования, “давай-давай!” менеджеров. Ну то есть это тот же бегемот – просто раньше показывали только морду, а теперь открыли вид сзади-сбоку и его узаконили. И этих людей – почему то не в разы, а на порядки больше. Как это получается? Ответ простой: благодаря тому что аджайл – это фрэймворк, а не методология. Как это наносит предательский удар по аджайлу? Почитайте вот эти рассуждения, и затем давайте пройдемся по рассуждениям автора и разберемся, как очередные благие намерения становятся дорогой в ад.

(more…)

Read full storyComments { 45 }

Сравнение подходов к организации разработки (Автор: Павел Веллер)

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

Read full storyComments { 8 }

Воздействие внешнего окружения на Agile – ISV и корпорации (автор: Павел Веллер)

Обсуждая agile техники и подходы к разработке и управлению проектами, мы, как правило, смотрим на проблему изнутри команды, говорим о том, как команда должна быть организована и каковы основные ингредиенты успеха. При этом мы зачастую опускаем внешнее окружение или предполагаем, что внешнее окружение легко прогнется под воздействием команды под ее нужды и мировоззрение. А так ли это? Очевидно, что ответ зависит от контекста, в котором работает команда. В условиях совместной с клиентом разработки (co-development) пренебрегать внешним окружением нельзя, и, не понимая его, считаться с ним эффективно не получится. Давайте разбираться на примерах. (more…)

Read full storyComments { 43 }

Почему меня настораживают MacBookи, или кого не должно быть в команде

Вообще я давний пользователь Macовской техники – во времена оны я трудился наверное на одном из первых “переносных” маков в Украине, и несказанно радовался четкости монитора и удобству интерфейса. Сейчас вполне довольный пользователь iPodа. Office 2008 на маке мне нравится гораздо больше своего аналога на пэцэ – особенно Outlook, виджет для рабочего стола просто drives me crazy. То есть я вообще вполне лояльно отношусь к брэнду и его продукции, хотя сам и не перешел.

Но вот люди, которые его пользуют у нас и их цели – они меня серьезно удивляют.

Встречался на днях с дизайнером – надо заделать дизайн к новому блогу, который я собрался заделать осенью. Камрады, которые вызвались делать, в дизайне ни ухом ни рылом о чем сразу предупредили. Возникла идея взять на время внешнего чувака, соответственно решили встретиться и посмотреть на предложенного камрада. Пришедший чувак меня сразу несколько насторожил – уж слишком броско одет (наблюдение из жизни: как правило если кто не может быть уникальным в творчестве – самовыражается “уникальным” через одежду). Чувак меня не разочаровал – зажигал напалмом. (more…)

Read full storyComments { 9 }

Про UML, холивар и последующий холишит

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

Когда писался agile manifesto, все были утомлены фанатиками имеющихся на рынке методологий. Структурный подход и имеющиеся методики стали настолько тяжелыми, что рухнули практически везде. Но надо помнить, что изначально они были вполне работоспособными. По ним жили десятки лет, но однажды поняли, что накладные расходы на эти методологии слишком велики. Такова судьба любой хорошей методики – она обрастает деталями, диаграммами, чеклистами, чтобы разобраться во всем этом деле пишут инструкции, инструкции сводят в подборки документов, подборки перерабатывают в процессы – и оба-на! мы получили очередную мегатяжеловесную Методологию, доведенную до идиотизма детализацией и оснащенную армией фанатиков, которые борются уже не за успех проекта, а за чистоту канона – чтоб все было Как-Завещал-Великий-Ленин, и если проект от этого загнулся – тем хуже для проекта.

Похоже, то самое начинается с аджайлом. Мы недавно запускали новый проект. Проект со старта имеет довольно развесистую структуру. Представить графически эту развесистую структуру – довольно сложно. Однако для релиз плэннинга надо не только структуру представить, но и рамки очертить. Мы использовали для этого UML и Sparx Enterprise Architect. UML потому что юзкейс-диаграммы все с грехом пополам читают, Sparx – потому что удобно рисовать и все отрисованные юзкейсы можно поддерживать в синхронизации с Visual Studio Team System 2008, который используется на проекте. Соответственно затем пользуясь интеграцией Team System + Microsoft Office делаем релиз плэннинг – хоть в Excel, хоть в Project.

Подход исключительно прост, польза для проекта очевидна, удобство для команды знакомой с UML и Sparx – тоже очевидно. Рассказал про это камрадам в Питере. Что тут было! ЕСЛИ ВЫ ИСПОЛЬЗУЕТЕ UML, ЗНАЧИТ У ВАС НЕ АДЖАЙЛ! ИБО В АДЖАЙЛЕ СКАЗАНО – НИКАКОЙ ДОКУМЕНТАЦИИ! Дорогие камрады, это распространенное заблуждение. На самом деле:

  1. Если посмотреть множество диаграмм с примерами, хотя бы из книжек Бека или специальных изданий, то становится ясно – диаграммы вообще и UML-диаграммы в частности как визуальное средство коммуникаций очень ценились отцами-основателями.
  2. Аджайл не требует отсутствия документации. Если бы требовал – фотографии доски тоже были под запретом, потому что это хоть и кривая, но тоже документация. Аджайл требует минимальной и достаточной документации – и UML-диаграммы (при условии что у вас их все умеют читать) отлично эту задачу решают.
    С частным вопросом разобрались легко, но этот частный вопрос – следствие попытки превратить аджайл в некий догмат, довести его до абсолюта, и все что противоречит догмату – объявить неверным. Затем – требующим искоренения.
    Коллеги, напоминаю: изначальный посыл аджайла – ставка на умных людей и их умение думать, а не на процесс. То, что хорошо для проекта – это и должно входить в вашу методику. Все остальное – от лукавого.
Read full storyComments { 4 }

Оценка. Примеры

Теория от практики на практике отличается гораздо больше, чем в теории.

После всех теоретических рассуждений о разных способах оценки (смотри Оценка. Часть 1 и Оценка. Часть 2) давайте рассмотрим примеры оценки нескольких гипотетических проектов.

Проект «МегаХ»

Большая система, time & materials. Заказчик за Scrum, но просит изначально оценить примерные затраты и хочет иметь возможность видеть общий прогресс проекта. Хороший заказчик.

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

Для оценки всего проекта решено выбрать story points. Учитывая свой предыдущий опыт, PM рассказывает команде, почему именно story points и что они дадут (иначе команда будет считать в днях и просто называть их story point). Уф, команда за story points – тем более, что у некоторых уже есть опыт. Проводится небольшой тренинг по оценке.

(more…)

Read full storyComments { 0 }

Практика внедрения Agile

Статья написана Виктором Прокопеней в апреле 2007 года. Печатается с любезного разрешения автора. (прим. ред.)

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

Read full storyComments { 0 }