Agile *

Всем привет! Я думаю мало людей в сети не знают, что значит сленговое слово тролль. Они часто встречаются в комментариях, приходят по-ирландски, не здороваясь, а уходят по-английски, не прощаясь. Вызывают лютую ненависть, запах валерианки у компьютера и сломанные клавиатуры. Для тех, кто с ними все же не знаком таки приведу определение.

Тролль (бояр. смутьян) — индивид, занимающийся троллингом. Изначально так называлось само провокационное сообщение или действие. Целью тролля является производство лулзов для себя и посетителей, раскусивших его, за счёт менее догадливых посетителей, тратящих время, силы и кровь из задницы на срач с ним.

Цитата взята с Луркмора, советую ее кстати дочитать. Почему я заговорил о троллях? А все потому, что в последнее время очень часто сталкиваюсь с троллями от IT. Хорошо это или плохо и что с этим делать обсудим ниже.

Оценка задач

При оценке сложности задач очень часто сложно выдать абсолютную оценку. Гораздо легче оценить относительный размер двух задач, т.е., например, сказать, что задача А в два раза больше задачи Б.
При agile-процессе разработки приходится оценивать много пользовательских историй.
Используя попарное сравнение снижается погрешность в определении оценок, и более того, эту погрешность можно вычислить.

Что будет если собрать кучу народа, дать им лего, мандарины, стикеры, фломастеры? Бардак? Может быть. Но если замесить все это на agile, то может получиться очень интересно. Именно так и вышло на прошедшем AgileCamp в Самаре. Подробности под катом.

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

— Давайте не лезь в этот модуль. Код недокументирован, все начнет глючить и сыпаться, особенно биллинг.
— До нас работала команда дураков, они учились программировать на этом проекте. Если сюда лезть, в команде упадет мотивация…
— Как это работает… Это надо в код смотреть. Люди, писавшие, уже ушли, документации нет. Месяц минимум.
— Мы залили данные, и все стало тормозить. Надо спринт посвятить исследованию причин. (и так несколько спринтов подряд)

Вы понимаете, что происходит что-то странное, что проект «заболел», что можно было наверно этого избежать, если знать заранее…

Постараемся понять, кому «бить морду» сейчас и кого отмутузить профилактически когда к нам придет следующий проект — чтобы избежать подобного коллапса.

Давайте подумаем, кому нужны гуманные методологии разработки? Команда, ответственность, храбрость, доверие…

Инвестор

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

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

Менеджер проекта

Ему нужно, чтобы проект:

а) Был довольно точно описан, согласован с Заказчиком и требования не менялись. Тогда его несложно оценить, распланировать этапы работ и водопадно выполнить.

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

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

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

Бум интереса к этой методологии прошел, однако до сих пор многие молодые команды легко очаровываются теоретической магией scrum, обещанием щелкать новые требования, как орешки, и не морочиться по ТЗ, бросаются внедрять на своем производстве и тут же натыкаются на трудности. Scrum вообще родился как методология разработки ПО, если вдруг кто забыл, и для успешного использования в web-разработке требует некоторой настройки. Это отдельный вопрос, в этой заметке я хотел бы затронуть другую тему и предостеречь от очевидных, в общем-то, ошибок, связанных с формированием требований к проекту. В любом описании методологии по запросу в Google говорится про важность роли scrum master'a и изложении требований к проекту в виде историй, но никто не говорит о том, откуда берутся требования, и нужно ли вообще их реализовывать. Без понимания этого момента сделать что-то путное вряд ли получится, и методология тут ни при чем.

Тема новой встречи сообщества AgilePiter — «Инженерные практики в Agile».

Мы будем рассматривать особенности внедрения и практического использования continuous integration, парного программирования, код ревью и прочих техник, а также попробуем вместе найти ответы на ваши вопросы.
Встреча будет проходить в формате модерируемой дискуссии, без докладов. Модерируют дискуссию Михаил Карпов (Яндекс) и Роман Юферев (VIAcode).

Участие бесплатное; количество мест ограничено.
Для участия в мероприятии необходимо подтвердить своё участие:
Регистрация на встречу

Встреча состоится в следующий вторник, 14 июня, с 19:00 до 21:30 в офисе компании «Яндекс».

Место проведения: Санкт-Петербург, Свердловская набережная, 44, бизнес-центр «Бенуа» (4 этаж).
От метро «Площадь Ленина» каждые 15 минут ходят бесплатные автобусы с надписями «Бенуа» под ветровым стеклом.
Где найти остановку: http://company.yandex.ru/contacts/spb/

На проходной говорите, что вы на семинар по Agile и поднимаетесь на четвертый этаж.
При необходимости — звоните: +7 (911) 769-00-21, Михаил.

Прошедшие встречи AgilePiter:
http://habrahabr.ru/search/?q=agilepiter

Начало прозаичное. А именно — как я работаю. Приходит хозяин фирмы, рассказывает мне задачу, я ее сам дроблю и делаю. Потом у меня в команде появился еще один человек и дробить задачи я стал уже на нас двоих. Если у меня, что-то не получалось или был какой-то затык, я обращался к разработчику на другой технологии. Он мне помогал и был своего рода моим начальником по технической части. Например: когда я захотел написать новый проект на Zend, а не на Codeigniter'e (на котором у нас все проекты), он мне дал две недели: если не успею, тогда на Codeigniter'e быстренько за два дня, чтобы сделал. Единственный минус, который я видел в своей работе, так это полное отсутствие тестирования с моей стороны и тестера как такового вообще.

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

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

Поехали.

Гибкие и «жесткие»

Есть гибкие методологии разработки (Agile), такие как Scrum, простые и постигаемые за пару дней. А есть «жесткие», увесистые, требующие многомесячного погружения, такие как RUP.

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

А чего бояться-то? Сумасшедшие бородатые специалисты говорят о процессах, артефактах, матрицах зависимости (Requirements Traceability Matrix) — а мы в рубахе, босиком, раз и… запрограммируем любой интернет-проект за 3 спринта! Ура, товарищи, к победе.

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

В прошлый раз мы обсуждали работу с заказчиком и управление требованиями.
Тема новой встречи — «Проведение совещаний в Scrum».

Мы будем рассматривать особенности проведения ретроспективы, планирования, stand-up и демо, а также попробуем вместе найти ответы на ваши вопросы.
Модерирует дискуссию консультант ScrumTrek — Алексей Корсун.

Участие бесплатное; количество мест ограничено.
Для участия в мероприятии необходимо подтвердить своё участие:
Регистрация на встречу

Встреча состоится при поддержке ЗАО «Ланит-Терком» во вторник, 22го февраля, с 19.00 до 21:30.
Место проведения: 14 линия В.О., дом 29. Здание математико-механического факультета СПбГУ.
На проходной говорите, что вы на семинар по Agile.

С уважением,
Михаил Карпов, менеджер проектов, Яндекс
Алексей Корсун, представитель ScrumTrek в Петербурге
Татьяна Васильева, руководитель проекта, Ланит-Терком

Я продолжаю сериал, начатый постом «Экстремальный аджайл — танцуют все!», посвященный распространению полезных практик из гибких методологий разработки на всех, кто вовлечён в проект. Ведь это несправедливо, когда отличными практиками пользуются только разработчики. Вашему вниманию предлагается видео доклада с рассказом о том, как мы решаем проблемы недостатка ресурсов и непрогнозируемых сроков, что мы делаем, когда не знаем с чего начать разработку и каким будет следующий шаг. Кроме того раз и навсегда решается вопрос необходимости тщательного стратегического планирования :) Как всегда, все это не теоретизирование и пересказ книжек и статей, а реальный опыт работы над реальным проектом. В общем этот пост писался с мыслью: «Давайте поговорим о процессе разработки и проблемах, связанных с ним. Долой маркетинговый буллшит и пустые теоритезирования!».

Как мы избавились от отчетов о выполненных работах

История об избавлении от бессмысленной траты времени

Введение

Вам когда-нибудь приходилось работать с отчетами о выполненных работах? Заполнять их? Утверждать их? Носиться с ними по всему офису?
Было ли это похоже на время, потраченное с пользой?

Заявление 1: Отчеты о выполненных работах иногда полезны.
Заявление 2: Но очень часто ничего подобного.

Cigarettes and coffee, man, that's a combination.
© «Coffee and Cigarettes», Jim Jarmush

Сам я не курящий, однако для книжки, про которую пойдет речь, это вполне подходящий эпиграф. Потому как книжка — про соединение двух очень связанных областей — это гибкие методологии разработки (a.k.a. Agile) и управление конфигурацией (a.k.a. SCM).

Речь пойдет о книге Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed за авторством Марио Морейры (Mario E. Moreira). Название можно перевести как "Применение SCM в командах с гибкими методиками разработки: в равновесии между устойчивостью и скоростью". Что по-русски, что по-английски — одинаково громоздко, однако смысл понятен.

Перед прочтением опасался, что книжка будет похожа на героев старого анекдота про морскую свинку, однако опасения были напрасными. И про Agile, и про SCM там — в полном объёме.

В прошлый раз мы обсуждали Agile в распределённых командах, автоматические сборки и тестирование. Формат модерируемой дискуссии OpenSpace участникам понравился и встреча прошла конструктивно, так что продолжаем в томи же духе. Будем рады видеть как участников прошлой встречи, так и новичков.

Тема новой встречи — «Работа с заказчиком и управление требованиями».
Обсудим, как быть с изменениями и жёсткими ТЗ, как строить отношения с заказчиком, что делать, а также попробуем вместе найти ответы на ваши вопросы.
Модерирует дискуссию консультант ScrumTrek — Алексей Корсун.

Участие бесплатное; количество мест ограничено.
Для участия в мероприятии необходимо подтвердить своё участие:
Регистрация на встречу

Встреча состоится при поддержке ЗАО «Ланит-Терком» в четверг, 18го ноября, в 19.00.
Место проведения: 14 линия В.О., дом 29. Здание математико-механического факультета СПбГУ. На проходной говорите, что вы на семинар по Agile.
Регистрация на встречу (участие бесплатное)

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

Agile Manifesto был выпущен в феврале 2001 года, когда группа разработчиков собралась в штате Юта, чтобы найти альтернативу управляемым документацией, «тяжеловесным» практикам разработки программного обеспечения, таким как «метод водопада», являвшимся золотым стандартом разработки в то время.

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

Уже давно у нас в головах была идея создания вебинаров по Agile.
Мой коллега, Сергей Андржеевский, опытный и известный скрам-мастер, который участвует в различных конференциях и круглых столах, где делится опытом работы в Agile-проектах — много «вкусного» и интересного рассказывает своим слушателям. Именно он попросил меня опубликовать эту статью на Хабре (своего аккаунта у него пока нет здесь), т.к. мы смогли запустить нашу серию вебинаров (первый уже состоялся 27 мая — Использование Offshore Agile в Exigen Services, а 21 июня была вторая часть — Важные моменты при переходе на Agile, 19 июля будет третья — Введение в практики Экстремального Программирования (eXP).

Использование Agile методологий (SCRUM, XP и т.п.) становится все более популярным в ИТ-индустрии. Почему это происходит? И как это работает?

На сегодняшний день гибкие методологии лучше всего адаптированы к постоянно ускоряющемуся развитию технологий, появлению новых средств разработки и все более переменчивым требованиям заказчика. Гибкость приобретает сейчас особое значение в силу общих тенденций развития информационных систем — глобальные массовые интернет-сервисы, Web 2.0 с его концепцией «постоянной бета-версии», переориентация с программных продуктов на информационные сервисы (которые по определению гибче и динамичнее), популярность SOA архитектур и т.д.

Идея создать «это» пришла ко мне около года назад. По большому счету, именно задача создания подобного мультика заставила меня взять карандаш в руки, и наложила свой отпечаток на все мои последующие презентации…

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

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

Детали смотрите в мультике. Обязательно обратите внимание на саундтрек, подобранный с особой любовью.

После недавнего релиза Firefox 3.6 организация Mozilla переходит на собственную методологию программной разработки под названием Lorentz. Она сочетает и принципы классического программирования по принципу водопада, и методики Agile. Предполагается, что таким образом получится внедрять в браузер фичи более короткими итерациями, то есть релизы станут выходить быстрее.

Благодаря модели Lorentz в линейке Firefox 3.6.x будут выходить не только патчи, но и апдейты с новыми фичами. Раньше в версиях вроде 3.5.х такого не было, а все новые фичи накапливались для основного релиза. В общем, это серьёзное изменение.

По словам директора проекта Firefox Майка Белтцнера (Mike Beltzner), в связи с разделом разработчиков по модели Lorentz, основные релизы теперь будут готовиться дольше, но фичи будут появляться быстрее.

Похожий подход сейчас применяют и в разработке Linux. Например, в текущем ядре 2.6.x новые фичи выходят с каждым релизом, то есть примерно каждые три месяца.

via InternetNews.com