Привет, друзья.
Пару недель назад появилось астанинское подразделение компании Newinttech, которая занимается разработкой СЭД Документолог. Но эта запись в блоге не для пиара ради. Сегодня, я хочу рассказать немного о планировании выпусков версий Документолога.
В алматинском подразделении мы используем стандартный waterfall... как-то исторически сложилось. Там нет product backlog-a. Не работаем с burndown-ами. Зато есть СЭД Документолог, которая имитирует to do, not checked out, checked out, completed и позволяет вычислять производительность(velocity) команды.
Этого нам хватает за глаза.
В астанинском же подразделении не используются какие-либо workflow-средства и методологии разработки. Документолога, который трансформирует процесс разработки в естественный waterfall, здесь тоже нет:) Зато есть Open Office со своим Spreadsheet-ом.
Скажу одно: "Spreadsheet-ы не самое удобное, что можно применить к мониторингу задач". Сжирает кучу времени и приходится оставаться работать после работы, чтобы не отставать от графика. Помимо всего этого требует жесткой дисциплины, что в веб-среде - редкость.
XP или SCRUM?
Не знаю мировой статистики, но для большинства знакомых веб-разработчиков парное программирование неприемлемо. Конечно, принцип добровольно-принудительно никто не отменял, но все же у казахстанцев рабочая машина - это нечто личное. Эдакая культурная особенность. Возможно, мои доводы ошибочны, но черт возьми, покажите мне хоть одну отечественную софтверную компанию, которая экстремалит по всем правилам агила.
По сути: короткими ли перебежками(XP) или же спринтами(SCRUM) достигать в сроки майлстонов - неважно. Сколько бы мы не планировали. Всегда приходили к одному и тому же. Планы - бесполезны, но планирование - важно. Почему планы бесполезны? Потому что постоянно корректируются. Даже после того как утверждены:). Милая картина: если сроки установлены и утверждены, то можно остаться после работы, чтобы успеть в срок.
Знаете, что обычно делает разработчик, когда нужно отладить программу? Нет-нет, он не будет ставить breakpoint-ы или запускать юнит-тесты. Он будет искать нужную нить программы и в нужной строчке кода пропишет console.log(), System.out.println(), print_r() или что-то вроде того. Где-то в интернетах есть статья, в которой говорится, что на разработку продукта уходит 30% ресурсов, а на поддержку 70%. Если на момент чтения статьи я не верил в эти цифры, то сейчас утверждаю, что это истинный тру. Ну так вот, когда разработчик найдет заветную строчку в программе и убедится, что System.out.println() выполняется, то он начнет наворачивать доменную модель, а через год руководитель проекта поймет, что очередной багфикс обходится в 10 000 KZT, а не 1 000 KZT как год назад. Что же случилось? Все просто. Система обросла костылями, и исправление одного бага приводит созданию костыля для костыля. Печально. А ведь в начале забили на шаблоны проектирования и тд и тп. А теперь представьте, что это все происходит не на простенькой трехзвенке, а на чем-нибудь распределенном. Ужас просто какой-то. Не завидую я таким проектам. К счастью, у нас с проектирование ПО все отлично и мы легко справляемся с добавлением нового и поддержкой старого функционала. И это благодаря паттернам проектирования и отчасти тест драйв девелопменту. Этим абзацем я хотел сказать, что все-таки TDD окупает себя. Вот только не стоит писать testCase на все и вся. Например, те же контроллеры в MVC Model 2 можно оставить непокрытыми тестами, а вот CRUD-ы и IO-шки я бы посоветовал покрыть на 100%.
XP или SCRUM?
Ответ лежит на поверхности. Берите то, что подходит для вас. Например, SCRUM больше отвечает на вопрос "как управлять", а XP "как делать".