Итак начнем сводку номер 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.
