Обратите внимание, перед вами реальная фотография правой половины моего рабочего стола.
На левую сейчас лучше не смотреть, потому что там лежит гора папок, бумажек, распечаток и несколько ежедневников. Периодически я их разбираю. Но не суть! Сейчас важна рассматриваемая картинка.
Вам ничего не напоминает набор этих листочков? Выкладываю их таким образом которую неделю, постоянно передвигаю, смещаю, уточняю. Пришлось перейти на такие маркеры задач, потому что это единственный здравый способ не забыть все отслеживаемые направления.
Я думаю, что почти все, работающие в области разработки программного обеспечения, с ходу разглядели тут подобие scrum или agile board. Предупреждаю, что дальше представителям других профессий читать видимо будет неинтересно.
На моём проекте давно витает мысль о том, что на практике при оперативном планировании мы постоянно применяем технологию Agile, только не называем её своим именем. Официально в больших и "серьезных" планах РП на год или для больших проектов используется Waterflow. Ежедневная жизнь заставляет применять Agile, втискивая эту технологию в существующие инструменты планирования.
Давно понятно, что работать в рамках каскадной модели тяжело, если не невозможно. Пора ей давно на свалку. Технология, родившаяся в 70-м году прошлого века безнадёжно устарела и не обеспечит конкурентоспособность в современных условиях.
Все жалуются на скорость работы производственного центра. Почему? Потому что у нас предполагается жёсткая последовательность действий, одно точно следует за другим. Говорят, что Waterfall нужно выбирать в случае, если "требования к проекту известны на его начальном этапе, тщательно продуманы и неизменны". Но это требование невыполнимо! Никогда! Даже если это реализация законодательства. Почему?
Потому что заказчик обычно не может сформулировать все требования на начальном этапе, тем более оформить их качественно. Сам по себе процесс согласования пожеланий клиента -всегда итерационный. Даже если стоит задача вывести на экран строку с текстом "Hello, world!", нам грозит итерация по поводу шрифта, размера букв, цвету текста и фона. Ведь у пользователя могут оказаться "особенные" мониторы и потребуется доработка для более качественного отображения текста.
В случае законодательства итерации обязательны, потому потому что это российское законодательство, написанное в духе "казнить нельзя помиловать". Неожиданно и вдруг может выйти разъяснение ЦБ о том, где правильно ставить запятую.
Окей! Я доказала, как минимум самой себе, что нам нужен agile. За чем же дело стало? Нужен - применяй на своём проекте. Сейчас у нас для оперативного планирования отладки при внедрении используются google-доки, так же самостоятельно и спонтанно. Есть свои минусы, но это лучше, чем xls-файл, рассылаемый почтой на всех участвующих.
Аналогично мне никто не мешает найти бесплатный вариант автоматизации agileboard и пробовать организовывать работы на своём проекте. Ведь это реально у всех работает...
Комментариев нет:
Отправить комментарий