to post messages and comments.

Юный адепт аджайла хлопал глазами и энергично мотал головой, всеми силами давая понять, что ни о каких ручках, ножках или иных конечностях он совершенно ничего не знает.
А я говорю: “Ну это как же не знаешь, ведь каждый день у вас скрам 15 минут, еженедельное планирование, ретроспектива, на которой можно обняться и плакать четыре часа, размазывая сопли по цветным бумажкам”.

Сходил сегодня на #vldc (спасибо Антону). Рассказывали про Agile (насколько я понял, это гибкий и нестандартный подход к процессу формирования и функционирования команды разработчиков ПО сайтов etc). У кого-нибудь есть опыт применения подобной методологии в (не)крупных компаниях? Как оно вообще? Рекомендации приветствуются, ибо любопытно мнение профессионалов, да и не только. В целом, концепция показалась довольно интересной.

Ссылка по теме: slideshare.net

octagram.name

Если кому надо, пока новая версия OpenMod'а ещё не готова, здесь можно взять агильные структуры (словари, последовательности, боксы для строк, чисел и boolean) и парсер подмножества YAML. Пригодится тем, кому надо на InnoSetup PascalScript написать что–нибудь эдакое.

Сегодня, в 19:00 по Мск все смотрим трансляцию с семинара по методологиям разработок: clubs.ya.ru . Сергей Дмитриев очень интересный тренер. Виделся с ним некоторое время назад в Питере на AgileDays. При первом знакомстве с ним немного "экание" ухо режет, а так всё отлично, и главное — он знает о чем говорит, и почему это работает.

Вот есть такая технология. Все вокруг говорят, что это очень Agile, что без тестирования код мёртв и т.д. И воде бы логично, что код надо тестировать, да и код, который гонят какую-то функцию или класс на подготовленных данных почти всегда пишется.... Но как же неудобно всё это оформлять в тесты. Не лень писать тестирующий код. Лень писать окружение для этого кода. Ведь если задуматься, то со времён когда Бек сотоварищи описали концепцию xUnit ничего вобще не изменилось. В итоге у нас есть несколько подходов один неудобнее другого. Начну, с xUnit. Чтобы начать его использовать надо подключить внешнюю библиотеку (линк+хедер), написать тестирующий класс, написать отдельное приложение либо define переключатель в своём меине который будет всё это тестировать. Зашибис. Причём для 90% случаев все вышеперечисленные шаги абсолютно одинаковы. Очень хочется поставить это всё на автомат в IDE.
Чтож добрые дяди из MS подумали и сделали интеграцию UnitTest с MSVS. И вродебы теперь тесты писать легко и быстро.... но для .NET. Конечно можно пробрасывать unmanaged код чтобы потестировать.... но теряются все плюсы. Вобще хочется чтобы тесты были сильно привязаны к методу/процедуре которую они тестируют. Чтобы можно было не только go to header/definition но и go to Test.
Следующий шаг попытались сделать в питоньих тестах. PyTest кажется. Тест помещается сразу под объявлением метода в комментарии. Только чтобы протестировать метод со всех сторон надо написать более 4 тестов обычно + часто нагрузочные, которые могут быть из нескольких строк. В итоге получается километровый комментарий, что в купе с каким-нибудь автодокументирующим стилем комментариев создаст комментариев гораздо больше чем кода. Программирование превратится в сплошной скроллинг и не дай бог понадобится что-то подправить на месте в редакторе без схлопывания участков кода.
Так и сидим. UnitTest это хорошо. это agile, это модно. НО АБСОЛЮТНО неудобно. Поэтому пусть тесты пишут вновь принимаемые на работу. Заодно с кодом познакомятся.... а мы попишем новые фичи.

вечра посетил AgileDays, было классно! Достаточно много интересных докладов по организации/управлению и туча интересных людей с богатым опытом, которым они не стеснялись делиться. Да, познакомился с клёвыми ребятами из e-legion! А ещё там был человек с фамилией Тян, глупо конечно смеяться, но ведь блин как тут не поржать :).

Внедрение Agile напоминает езду на велосипеде. Чем быстрее едешь, тем стабильнее велосипед, нужно просто один раз поверить, что ты не упадешь и пересечь граничную скорость.

Только что на конфе прозвучала мудрая мысль (на обсуждении надо ли делать суперскрам скрамов для больших проектов) — а какого черта мы вообще делаем большие проекты, когда можно раздельно делать много маленьких?

Еще раз: у команды должны быть все ресурсы для имплементации фичи — иначе будут отмазки типа "мы не успели потому что тот дизайнер опоздал с дизайнами дизайны, мы не виноваты".

Команда должна иметь в себе специалистов из всех необходимых областей для полной разработки фичи (программеров, дизайнеров, тестеров) — иначе она не может быть ответственной за результат.