Agile methodology

[Assynt]

[(плюс записей в ДТС)

ДТС - это что? Product backlog? Iteration backlog?

IMHO, это все-таки DTS

aka Defect Tracking System

[AlexANB]

О, мамма миа!

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

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

[Meadie]

[(плюс записей в ДТС)

ДТС - это что? Product backlog? Iteration backlog?

Дефект Трэкинг Систем. Прошу прощение за отсутствие латиницы. Более точно, конечно, было бы назвать то, что я имел в виду - Issue tracking system, но в русской транскрипции это вообще бы никто не понял:)

[Jou-Jou]

Got it, thanks

[Stanislav]

Раньше я не знал, как назвать происходящее на давно известной картинке...
А теперь знаю - методология создания программного обеспечения!

[CdR]

О, мамма миа!

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

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

Огорчу. Весь этот мир -- иллюстрация типичнейшей agile methodology.
Отакот.

[Rai]

Огорчу. Весь этот мир -- иллюстрация типичнейшей agile methodology.
Отакот.

Полностью соглашусь! Возьмем, например, пупок. Ну кто ж так делает? Эх... :)

[aissp]

=) Из Agile просто из рассылки

Вчера Хунь Лунь починил 9 багов, он стал героем дня. Сегодня цель для нашей комманды починить 130 багов (в среднем 2 бага на бойца) ...

Граждане ЕТО БРЕД!!!! Человек не может починить 8 багов за один день, или ето не баги

[Stanislav]

=) Из Agile просто из рассылки
Вчера Хунь Лунь починил 9 багов, он стал героем дня. Сегодня цель для нашей комманды починить 130 багов (в среднем 2 бага на бойца) ...
Граждане ЕТО БРЕД!!!! Человек не может починить 8 багов за один день, или ето не баги

Так это смотря как считать!
Например, я вчера починил 15 багов:
- поменял расширение картинок с .гиф на .пнг -> МРТЖ сразу перестал показывать
- саппрот завопил - баги!!! ничего не показывает!!!
- пофиксил пхп код в 15 местах -> все стало опять показывать
можно задекларировать как один баг, а можно и как 15

[Stanislav]

Огорчу. Весь этот мир -- иллюстрация типичнейшей agile methodology.
Отакот.

не знаю, как agile methodology, но про мир и про баб - не согласен!

[Alusya]

=) Из Agile просто из рассылки

Вчера Хунь Лунь починил 9 багов, он стал героем дня. Сегодня цель для нашей комманды починить 130 багов (в среднем 2 бага на бойца) ...

Граждане ЕТО БРЕД!!!! Человек не может починить 8 багов за один день, или ето не баги

Интересно сколько он таким образом создал новых.

[aissp]

хороший вопрос, а главное поживорежущий

[Meadie]

=) Из Agile просто из рассылки

Вчера Хунь Лунь починил 9 багов, он стал героем дня. Сегодня цель для нашей комманды починить 130 багов (в среднем 2 бага на бойца) ...

Граждане ЕТО БРЕД!!!! Человек не может починить 8 багов за один день, или ето не баги

В современной промышленной разработке программного обеспечения непосредственно изменение кода занимает не так уж и много времени. Получив задание на исправление дефекта, программист обычно затрачивает некоторое время на закачку последних сорцов, воспроизведение проблемы, нахождение места (или нескольких мест) в коде, куда требуется внести исправление, написание юнит-тестов. Только затем идет непосредственное изменение кода, прогон автоматизированных юнит-тестов (или их ручное выполнение, если автоматизация отсутствует) и аплоад сорцов. Если поддерживается несколько веток продукта, то выполненные изменения нужно смерджить в каждую из них и прогнать тесты. Понятно, что в подобных условиях оверхед может легко достигать и 90%: изменение всего лишь одной строчки кода может сопровождаться многочасовыми дополнительными телодвижениями (и это еще до того, как версия попадет на тестирование).

С другой стороны, если оверхед небольшой, продукт не очень сложный (риск сайд-эффектов невелик), описание дефекта такое, что программист, не запуская среду разработки, уже знает где и что нужно исправить, да и само исправление небольшое (несколько строчек кода), то 1 баг за час починить вполне реально. Ну и, наконец, разные люди могут думать и нажимать на клавиши с различной скоростью -это отличие может легко достигать 2-3 раз:)

[Alusya]

В современной промышленной разработке программного обеспечения непосредственно изменение кода занимает не так уж и много времени. Получив задание на исправление дефекта, программист обычно затрачивает некоторое время на закачку последних сорцов, воспроизведение проблемы, нахождение места (или нескольких мест) в коде, куда требуется внести исправление, написание юнит-тестов. Только затем идет непосредственное изменение кода, прогон автоматизированных юнит-тестов (или их ручное выполнение, если автоматизация отсутствует) и аплоад сорцов. Если поддерживается несколько веток продукта, то выполненные изменения нужно смерджить в каждую из них и прогнать тесты. Понятно, что в подобных условиях оверхед может легко достигать и 90%: изменение всего лишь одной строчки кода может сопровождаться многочасовыми дополнительными телодвижениями (и это еще до того, как версия попадет на тестирование).

С другой стороны, если оверхед небольшой, продукт не очень сложный (риск сайд-эффектов невелик), описание дефекта такое, что программист, не запуская среду разработки, уже знает где и что нужно исправить, да и само исправление небольшое (несколько строчек кода), то 1 баг за час починить вполне реально. Ну и, наконец, разные люди могут думать и нажимать на клавиши с различной скоростью -это отличие может легко достигать 2-3 раз:)

Я так понимаю, что для вас только оверхед может котрибьютить в длительность пофиксивания.
Больше багов хороших и разных!

[Marmot]

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