Минирелизы

1 августа 2009 г.

Идея пришла от заказчика. Суть в том, что кроме обязательных заливок в конце итерации, заказчик просит нас делать заливки после выполнения определенных карточек.

Выглядит примерно так:

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

Теперь заказчик получает еще большую отдачу от разработки, а нам такие заливки ничего не стоят :-)

13 комментариев:

  1. А сколько времени уходит на заливку версии?
    После выполнения карточки/итерации производится ли тестирование выполненой задачи/задач?

    ОтветитьУдалить
  2. @Николай

    "А сколько времени уходит на заливку версии?"
    Заливка практически автоматизирована. Выпуск версии для заливки делается около минуты и написан на Nant. Выкладка этой версии на живой сервер требует внимания (поэтому заливка всегда производится вдвоем) и занимает около 5-10 минут.

    "После выполнения карточки/итерации производится ли тестирование выполненной задачи/задач?"
    Весь наш код изначально покрывается тестами (модульные тесты). Тестирование самой задачи (пользовательский интерфейс) происходит ручками перед заливкой.

    ОтветитьУдалить
  3. >> а нам такие заливки ничего не стоят

    только закусывать не забывайте!

    ОтветитьУдалить
  4. @Анонимный
    Типа от радости, что мы залили новую версию?

    ОтветитьУдалить
  5. А на сколько велик проект, можно поинтересоваться?

    ОтветитьУдалить
  6. Да, это достаточно просто в реализации и заказчик счастлив. До тех пор, пока у него не свалится что-то в самый ответственный момент...

    Я так понимаю, серьезного тестирования при помощи QA тима, тест кейсами и прочей ерундой у вас нет? Т.е. в основном идет тестирование только что реализованных фич, а по пути можем найти что-то, если сломалось в других местах. Или как-то по-другому?

    Почему спрашиваю: пока проект в стадии разработки, да если он еще и небольшой - это работает. Когда проект становится больше, вероятность сломать уже существующий функционал увеличивается. Модульные тесты, конечно, очень помогают, но не всегда. А уж когда продукт выходит в production - там вообще все не так просто становится, пропущенный баг может быть слишком дорог, поэтому перед выкатыванием новой апдейтов должен проходить как минимум smoke testing приложения, а при серьезном изменении функционала - даже полное регрессионное тестирование.

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

    ОтветитьУдалить
  7. @Александр Кондуфоров
    Спасибо за дополнение.

    Конечно задачи, которые могут сломать что-то мы заливать "просто так" не будем. К тому же код отлично покрыт тестами, причем как модульными, так и интеграционными.

    На самом деле шанс сломать где-нибудь там повышается, но эта опасность контролируемая.

    ОтветитьУдалить
  8. "А на сколько велик проект, можно поинтересоваться?"

    В чем величину измерять? В годах, деньгах, строчках кода?

    ОтветитьУдалить
  9. @Александр Кондуфоров
    Наравне с сортировкой карточек по уровню важности, выставление "звездочки" для заливки является бизнес-решением заказчика. В нашем случае проект от этого только выигрывает.

    Я хочу чтобы эту идею взяли на вооружение, но ни в коем случае не использовали как руководство к обязательному исполнению =)

    ОтветитьУдалить
  10. "В чем величину измерять? В годах, деньгах, строчках кода?"

    В чем вам удобнее. Для меня более показательными будут года/строчки кода, чем деньги.
    И еще, пожалуйста, если не затруднит. Сколько времени у вас длится полноценная итерация? Сколько программистов работает над проектом?
    Спрашиваю не просто так. Есть мысль использовать что-то подобное в своем проекте, но пока это только мысль. Вот и интересует опыт успешного применения таких подходов в средних и больших проектах.

    ОтветитьУдалить
  11. Строчек кода очень много, за год написали довольно много функциональности. Над проектом сейчас работает 4 программиста (надеюсь это не секретная информация, да простит меня директор ;)

    Итерация длится 2 недели. В проекте очень часто и довольно резко меняются требования и направления развития, поэтому 2 недели это оптимальный срок.

    Помог?

    ОтветитьУдалить
  12. Спасибо, это кое что.

    Я правильно понимаю, что если итерация - 2 недели, то мини-итерация, заканчивающаяся после завершения очередной карточки, - это 2-3 дня?

    ОтветитьУдалить
  13. "Спасибо, это кое что."

    Надеюсь, что вам пригодиться =)

    "Я правильно понимаю, что если итерация - 2 недели, то мини-итерация, заканчивающаяся после завершения очередной карточки, - это 2-3 дня?"

    Да, на самом деле это любой промежуток времени меньше недели. Проект является SaaS решением, поэтому заливку мы можем делать централизовано для всех наших пользователей.

    ОтветитьУдалить

Моя книга «Антихрупкость в IT»

Как достигать результатов в IT-проектах в условиях неопределённости. Подробнее...