Был тут на agile labs очень понравилась дискуссия Вячеслава Панкратова и Асхата Уразбаева на тему "Agile vs non-Agile". Оппоненты agile'a активно доказывали , что Agile = подмножество rup'a и, что вся эта шумиха вокруг agile'а не более чем маркетинговая разводка. Когда был поднят вопрос о том, а что же такое Agile и чем он отличается от RUP'a сразу вспомнилась памятная встреча Agile Russia сообщества на тему "Какие проекты считать Agile проектами" в итоге четкого определения так и не вывели :)
На основании этого был сделан простой вывод - Agile - это религия , в нее надо верить чтобы ее использовать.
По своей команде могу сказать , что внедрить Agile в команде, которая в него не верит невозможно просто по причине того , что они продолжают работать по старинке успокаивая менеджерами DSM'ами.
Нужна ли нам такая методология больше похожая на религию ? Я думаю, что нужна , т.к. сам процесс разработки не является настолько строгим и четким процессом как бы этого хотелось поклонникам RUP'a , поэтому методология основанная на вере вполне оправдана.
воскресенье, 5 апреля 2009 г.
среда, 11 февраля 2009 г.
Agile part 2
Вводная
Итак начнем сводку номер 2 с небольшого отступления в сторону.
Собственно Agile как методология предполагает максимальную гибкость по отношению к вечно изменяющиемуся мнению заказчику при разработке для него ПО.
Вопрос тут собственно не в гибкости, а в разработке.
Применим ли Agile для поддержки систем, bugfixing'a?
С одной стороны поддержка систем не является настолько детерменированным процессом в котором можно просто выделить задачи на итерации ,т.к. ошибки, требущие срочного решения могу возникать и по ходу итерации. Поэтому от правила на не добавление задач в sprint backlog во время итерации приходиться отступать. К тому же многие инженерные практики очень сложно применять в условиях поддержки , а не разработки. Для примера TDD сложно применять в таких проектах так как по сути тут все зависит от того насколько преокт тестируемые в данный момент , если в проекте нету тестов то TDD применить при поддержке такого проекта будет очень сложно.
Одна из немногих практик, которая активно используется для всех команд - Continuous integration
Для этого используются ежедневные сборки версий и тестирование этих сборок. В соотвествии с результатами тестирования сборка признается рабочей или не рабочей.
Вот так на практике выглядит отчет о тесте сборок:
Интересной особенностью данных сборок является то, что сборка производится только нескольких веток контроля версий.
При этом данные ветки являются сборной версией из результатов работы практически всех команд по данному проекту.
Таким образом, у нас обнаруживают возникщее проблемы с изменениями сделанными разными командами за долго до того , как продукт дойдет до конечного пользователя.
Возвращаясь к Agile практикам можно отметить , что упомянутый мною excel backlog начинает по-тихоньку обнажать свои существенные недостатки:
Итак начнем сводку номер 2 с небольшого отступления в сторону.
Собственно Agile как методология предполагает максимальную гибкость по отношению к вечно изменяющиемуся мнению заказчику при разработке для него ПО.
Вопрос тут собственно не в гибкости, а в разработке.
Применим ли Agile для поддержки систем, bugfixing'a?
С одной стороны поддержка систем не является настолько детерменированным процессом в котором можно просто выделить задачи на итерации ,т.к. ошибки, требущие срочного решения могу возникать и по ходу итерации. Поэтому от правила на не добавление задач в sprint backlog во время итерации приходиться отступать. К тому же многие инженерные практики очень сложно применять в условиях поддержки , а не разработки. Для примера TDD сложно применять в таких проектах так как по сути тут все зависит от того насколько преокт тестируемые в данный момент , если в проекте нету тестов то TDD применить при поддержке такого проекта будет очень сложно.
Engineering or not engineering. That is the question.
Как могли понять поддержка это иммено чем занимается наша команда. Поэтому рассказать при инженерные практики можно очень мало.Одна из немногих практик, которая активно используется для всех команд - Continuous integration
Для этого используются ежедневные сборки версий и тестирование этих сборок. В соотвествии с результатами тестирования сборка признается рабочей или не рабочей.
Вот так на практике выглядит отчет о тесте сборок:
Интересной особенностью данных сборок является то, что сборка производится только нескольких веток контроля версий.
При этом данные ветки являются сборной версией из результатов работы практически всех команд по данному проекту.
Таким образом, у нас обнаруживают возникщее проблемы с изменениями сделанными разными командами за долго до того , как продукт дойдет до конечного пользователя.
Agile is not a team ?
Возвращаясь к Agile практикам можно отметить , что упомянутый мною excel backlog начинает по-тихоньку обнажать свои существенные недостатки:
- Плохо связан с системой отслеживания задач(xplanner), зачастую приходиться записывать номера задач из excel'a и потом перебивать их вручную в xplanner.
- Разбиение в центральной колонке сделано по людям, а не по задачам как принято обычно в taskboard'ах. Таким образом плохо формируется команда, т.к. у каждого свои задачи по сути понятия командных задач нету.
- Неудобство обновления данного файла,т.к. excel не позволяет одновременный доступ к документу, приходиться обновлять файл только ScrumMaster'у что фактически выключает команду из игры , а ведь agile это fun , тут его нету :(
Sprint planning
В любой Agile команде есть так называемый Sprint planning meeting, а именно встреча на которой присутствует вся команда и Product Owner. Наш непосредственный PO таких встреч делает не хочет поэтому у нас sprint planning выглядит по сути никак, т.е. мы садимся командой долго смотрим на список задач Estimate которых проставлен не нами и думаем какие из этих задач мы можем взять на текущий спринт, при том, что у всех задач один и тот же приоритет.
Oh no, it's dead.
Со временем у меня начинает создаваться впечатления , что Agile возможен только в теории. Так как слишком много подводных камней и людей, которые настолько привыкли к работе в waterfall режиме , что любые попытки перевести их на Agile оказываются бесполезными в силу устраивания мини waterfall'а или скатывания в RUP. Донести понимание того, что Agile не является итеративной разработкой, а в первую очередь КОМАНДНОЙ разработкой , где есть командная отвественность , а не отвественность каждого отдельного члена, является не тривиальной задачой , но без нее RUP = Agile.
вторник, 3 февраля 2009 г.
Вводная
Итак, в первой сводке, я расскажу немного о компании и об особенностях Agile'a, применяемого в нашей компании.
Поэтому для меня большим удивлением была вакансия с ключевым словом Agile в описании назовем компанию, разместивщую данную вакансию компания RR.
После первого собеседования мне показалось, что вот она Agile компания!
Тут возник вопрос , а откуда они узнали об Agile?
Ответ был достаточно простой - внедрил Agile в этой компании ее заказчик.
Agile in Russia , Impossible!
При поиске работы я обнаружил одну странность - российских компаний, работающих по Agile методологии практически нет на рынке.Поэтому для меня большим удивлением была вакансия с ключевым словом Agile в описании назовем компанию, разместивщую данную вакансию компания RR.
После первого собеседования мне показалось, что вот она Agile компания!
Тут возник вопрос , а откуда они узнали об Agile?
Ответ был достаточно простой - внедрил Agile в этой компании ее заказчик.
Заказчик - иностранная компания, занимающаяся разработкой встроенных систем назовем ее компания AA, для конспирации :).
Собственно в моем случае компания RR предоставляет ресурсы в качестве команды разработчиков компании AA.
При этом управление командой разработчиков осуществляется непосредственно менеджерами из компании АА , так что это не совсем типичный вид аутсорсинга.
Собственно Agile методологию(а точнее Scrum составляющую) активно внедряет менеджер из компании AA во всех своих командах и в нашей команде в том числе.
Период притирки команды уже завершился(команде более года), так что скидок на то, что команда только познакомились с Agile можно не делать.
Remote Agile. Pain in the Ass!
Как я писал выше наши заказчики из компании AA управляют командой разработчиков сами. Поэтому наш Agile довольно специфичен все таки удаленный Scrum Master это нелегко.
Первый вопрос который возникает как в таких случаях рулить несколькими командами, если очень сложно управлять большим коллективом удаленно? Как контролировать сроки поставки продукта, имея несколько команд различных по численности и уровню ?
Решение оказалось достаточно простое:
Каждая Scrum команда занимается отдельно своей функциональностью по проекту, максимально изолировано от остальных команд(естественно изоляция это в идеале иногда требуется взаимодействие членов разных команд).
Как это не странно в таких условиях работает большая часть практик Scrum'a.
Product Backlog
Product backlog - это список задач, описанных с точки зрения бизнеса, называемых User Stories.
Пример : Как пользователь я хочу иметь возможность сохранять сообщение без его публикования.
Так же у нас в Product Backlog заносятся так называемые Tech Stories - задачи технического характера, Пример: Настроить сервер сборок.
Пример : Как пользователь я хочу иметь возможность сохранять сообщение без его публикования.
Так же у нас в Product Backlog заносятся так называемые Tech Stories - задачи технического характера, Пример: Настроить сервер сборок.
Product backlog представлен в 2х сущностях:
- в электронном виде в Xplanerr'e
- в виде укрупненных User Stories(задачи с точки зрения заказчика в Scrum'e) на TaskBoard'e.
Причем так как у нас нет возможности использовать типичный TaskBoard(хотя первое время пытались) было найдено следующее решение в виде Excel'a файл,
Daily Scrum
Daily Scrum - ежедневная встреча для обсуждения трех вещей:
Что сделано ? Что запланировано на сегодня ? Что мешает работе ?
Встреча ограничена по времени - максимум 15-20 минут.
Поэтому ее традиционно проводят стоя, долго на ногах не простоишь просто :).
Удаленный Daily Scrum Meeting отличается только тем, что проходит по Skype'у и не проводиться стоя, в остальном все тоже.
Про остальные Scrum практики, используемые в нашей команде я расскажу в следующей сводке.
Что сделано ? Что запланировано на сегодня ? Что мешает работе ?
Встреча ограничена по времени - максимум 15-20 минут.
Поэтому ее традиционно проводят стоя, долго на ногах не простоишь просто :).
Удаленный Daily Scrum Meeting отличается только тем, что проходит по Skype'у и не проводиться стоя, в остальном все тоже.
Про остальные Scrum практики, используемые в нашей команде я расскажу в следующей сводке.
пятница, 30 января 2009 г.
Agile - реальность или миф? Проверка на практике.
Заразившись вирусом Agile разработки , я пытался первое время внедрить его в своей компании.
Но, к сожалению, слишком консервативная структура организации не позволила практиковать Agile в полной мере.
Поэтому я решил опробовать Agile на практике, а именно в команде, которая уже работает по Agile.
В связи с чем пришлось сменить работу, что навевает грустные мысли о расставании с людьми которых знаешь, но в тоже время несет много приятных и других(назовем их так :)) неожиданностей от нового рабочего места.
Проверку Agile'a на практике я начну со 2ого февраля этого года, т.е. через 2 дня после публикации этой записи.
Каждую неделю я буду сообщать вам новые заметки по Agile'у на практике.
Но, к сожалению, слишком консервативная структура организации не позволила практиковать Agile в полной мере.
Поэтому я решил опробовать Agile на практике, а именно в команде, которая уже работает по Agile.
В связи с чем пришлось сменить работу, что навевает грустные мысли о расставании с людьми которых знаешь, но в тоже время несет много приятных и других(назовем их так :)) неожиданностей от нового рабочего места.
Проверку Agile'a на практике я начну со 2ого февраля этого года, т.е. через 2 дня после публикации этой записи.
Каждую неделю я буду сообщать вам новые заметки по Agile'у на практике.
Подписаться на:
Сообщения (Atom)