Archive | January, 2009

Мы открылись! Опять.

by on 6:12 pm in Жизнь, Новости

Пришла пора меняться. Менять сайт и менять что-то в себе.

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

Но сайт не главное. Главное для нас сообщество, встречи и общение практиков.

Что есть в сущности сайт для сообщества Agile-практиков?
Кто-то скажет, что это просто контактная страничка, где можно узнать время новой встречи сообщества. Кто-то скажет, что сайт это склад контента и ссылок по тематике сообщества, а следовательно и дизайн там не важен. Третий объяснит, что по дизайну будут судить о серьезности наших намерений… Когда мы внутри обсуждали наш будущий дизайн и будущий сайт мы также столкнулись с целом рядом мнений и требований. (more…)

Read full story • Comments { 1 }

Как разочароваться в Agile

by on 4:42 pm in Жизнь

Самый простой и легкий способ разочароваться в Agile это начать врать своей команде, что мы работаем по Agile. Больше ничего и делать не надо.

Такая ситуация далеко не редкость. Ко мне регулярно приходят на собеседование программисты, которые жалуются на проблему устроенности процессов в своей бывшей компании. И ладно бы просто был бардак… Хуже. Этот бардак менеджеры называют agile’ом.

Именно так.

Не так давно мы общались с одним разработчиком, который рассказывал о подобной проблеме. Я попросил его более подробно изложить, как у них устроен процесс. Оказалось, что для управления софтверным проектом используется BaseCamp (wtf!), куда заказчик выливает поток сознания в виде messages. Этот поток сознания обрабатывается тим-лидом, который распределяет работу сам на имеющихся разработчиков. Готовый результат заливается на хостинг. Ни итераций, ни управления требованиями, ни толкового планирования, ни митингов не происходит. Судя по всему и биллинг также сопряжен с проблемами, когда по факту месяца приходится выискивать в байзкамповских отчетах сколько стоила для клиента та или иная фича. Типичный саппорт с арендой ресурсов гордо именуется Agile-методикой.

Т.е. я не хочу сказать, что саппорт с арендой ресурсов не может работать по аджайлу. Может. Но в чем смысл называть подобный метод разработки, скажем, скрамом, если каждый разработчик может в любой момент прочитать статью в интернете и узнать, что такое действительно Скрам?

Read full story • Comments { 2 }

Забавная хрень о субъективности и мнениях

by on 1:54 pm in Жизнь

Мне в пятницу сообщили, что я мол не принимаю идеи, если они не мои собственные. В пятницу же вечером произошел забавный случай.

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

Потом я попросил камрада здесь подкрутить, тут убрать, там добавить, прогресс бар нарисовать – и глядишь, софтина выросла в мааааленький такой продуктик, который мы решили предложить миру как beta (c прицелом что если будет много пользователей – накосить на нем денег, ага. Типа feasibility study.)

Суть не в этом. Вначале продукт назывался Linky (придумал камрад). Потом BaseLook (по факту назвал я). И вот мы стали думать как назвать финальный продукт. И в пятницу бились чуть не до 10 часов – какой из вариантов названия выбрать. При этом камрад отстаивал название BaseLook, а я – Linky. Инверсия предпочтений, так сказать :)

Read full story • Comments { 4 }

Логотип сообщества

by on 8:41 am in Новости

Дамы и господа,

нужна ваша помощь – координаторы намерелись определиться с логотипом и символикой. Если вам это интересно, и вы располагаете идеями – поделитесь, пожалуйста, письмом по адресу kanstantin (собачка) gmail.com. Что нужно: оригинальное графическое начертание “agile.by” плюс, опционально, знак (эмблема), символизирующее сообщество. Актуально до пятницы, 30-го января, включительно. На следующей неделе проведем голосование и выберем лучший вариант.

Заранее благодарим.

Read full story • Comments { 0 }

Распределенный agile и вопросы коммуникаций

by on 10:09 pm in Практики Agile

В Гродно на меня работает отличная команда разработки. Я их всех нежно люблю. Виталий Брейда – это надмозг, сочетающий лучшие качества разработчика с въедливостью тестера. Оля Махнач – бизнес-аналитик, который пишет юзер сториз так, как я бы писал сам. Причем используя мои собственные термины типа “отлуп” и “дрючок” – временами не мог отличить, где писал я, а где она. Марина Василюк делает так, что при выходе чудо-софтины багов в ней – минимум. Это при том, что многие вещи мы обсуждаем и меняем чуть ли не перед релизом. Женя Парахневич как знатный скрам-мастер неуклонно бдит над тем, чтобы все работало, молчаливо присутствуя на всех коллах. И вот про коллы я и хотел поговорить.

P1130353Я думаю, все уже поняли, что команда, которая работает – исключительно матерая. На удаленных коммуникациях – собаку вроде бы съели. На инструментах – не экономим, используем GoToMeeting, голосовые конференции, ну и все как положено, см. картинку. (more…)

Read full story • Comments { 16 }

Agile – для fixed bid?

by on 12:05 pm in Управление проектами

Вообще я яростный противник fixed bid-проектов. Fixed bid-проект обычно оставляет и у Заказчика, и у Исполнителя чувство обоюдного проигрыша – Заказчик недополучил функционал, Исполнитель недополучил прибыль (если очень упрощенно). Для того, чтобы этого не произошло, требуется несколько заходов танцев с бубном – во-первых, нужно вдумчиво поработать над концепцией и ТЗ, используя дорогостоящего аналитика и отвлекая (тоже недешевых) ключевых специалистов Заказчика для сессий JAD; во-вторых, нужно установить процесс управления изменениями; и в-третьих, даже при всем при этом чтобы корректно посчитать этот самый fixed bid нужно иметь историю работы команды или релевантную статистику по организации – чтобы перевести полученный юзкейсы и вайрфрэймы в часы работы и календарные дни длительности (из чего и складывается в конечном итоге цена). Ну и в добавок требуется увязать это все в контракте, создав доброжелательную обставновку вооруженного перемирия и взаимного недоверия. Но проект сделать можно. Следствием такого проекта (при условии того, что оговоренный в контракте процесс не похерят в процессе работы) с весьма большой долей вероятности будет адекватная качественная система. (more…)

Read full story • Comments { 5 }