всем, кто пользуется сервисом trello посвящается
urbandictionary.com
urbandictionary.com
я программист на скрам/аджайл
лучшая команда это либо 6 человек, либо 1 (но я)
vimeo.com Эрик Майер ворчит про agile, не могу не поделиться
вуф-вуф-вуф, не плотим деньги тем, кто удалил меньше строк чем написал
Юный адепт аджайла хлопал глазами и энергично мотал головой, всеми силами давая понять, что ни о каких ручках, ножках или иных конечностях он совершенно ничего не знает.
А я говорю: “Ну это как же не знаешь, ведь каждый день у вас скрам 15 минут, еженедельное планирование, ретроспектива, на которой можно обняться и плакать четыре часа, размазывая сопли по цветным бумажкам”.
А я говорю: “Ну это как же не знаешь, ведь каждый день у вас скрам 15 минут, еженедельное планирование, ретроспектива, на которой можно обняться и плакать четыре часа, размазывая сопли по цветным бумажкам”.
"Расставим приоритеты. У всех задач самый высокий приоритет". True agile, bro.
боже, заберите меня отсюда!
боже, заберите меня отсюда!
Сходил сегодня на #vldc (спасибо Антону). Рассказывали про Agile (насколько я понял, это гибкий и нестандартный подход к процессу формирования и функционирования команды разработчиков ПО сайтов etc). У кого-нибудь есть опыт применения подобной методологии в (не)крупных компаниях? Как оно вообще? Рекомендации приветствуются, ибо любопытно мнение профессионалов, да и не только. В целом, концепция показалась довольно интересной.
Ссылка по теме: slideshare.net
Ссылка по теме: slideshare.net
scrumshot
Хороший список книг по Agile: agilesoftwaredevelopment.com
octagram.name
Если кому надо, пока новая версия OpenMod'а ещё не готова, здесь можно взять агильные структуры (словари, последовательности, боксы для строк, чисел и boolean) и парсер подмножества YAML. Пригодится тем, кому надо на InnoSetup PascalScript написать что–нибудь эдакое.
Если кому надо, пока новая версия OpenMod'а ещё не готова, здесь можно взять агильные структуры (словари, последовательности, боксы для строк, чисел и boolean) и парсер подмножества YAML. Пригодится тем, кому надо на InnoSetup PascalScript написать что–нибудь эдакое.
А вот еще статья про управление версиями для agile (для случая, когда над проектом работают несколько команд). Тоже на ангельском. infoq.com
Да, и в продолжение: #1060524, Сергей Дмитриев похож на персонажа из The Big Bang Theory, владельца магазина комиксов. Сравнивайте сами: company.yandex.ru и imdb.com :D
Сегодня, в 19:00 по Мск все смотрим трансляцию с семинара по методологиям разработок: clubs.ya.ru . Сергей Дмитриев очень интересный тренер. Виделся с ним некоторое время назад в Питере на AgileDays. При первом знакомстве с ним немного "экание" ухо режет, а так всё отлично, и главное — он знает о чем говорит, и почему это работает.
Цикл семинаров «Гибкие методики разработки. Развеиваем мифы и экспериментируем сами»: clubs.ya.ru . Был бы семинар в Петербурге, с радостью бы посетил.
Вот есть такая технология. Все вокруг говорят, что это очень Agile, что без тестирования код мёртв и т.д. И воде бы логично, что код надо тестировать, да и код, который гонят какую-то функцию или класс на подготовленных данных почти всегда пишется.... Но как же неудобно всё это оформлять в тесты. Не лень писать тестирующий код. Лень писать окружение для этого кода. Ведь если задуматься, то со времён когда Бек сотоварищи описали концепцию xUnit ничего вобще не изменилось. В итоге у нас есть несколько подходов один неудобнее другого. Начну, с xUnit. Чтобы начать его использовать надо подключить внешнюю библиотеку (линк+хедер), написать тестирующий класс, написать отдельное приложение либо define переключатель в своём меине который будет всё это тестировать. Зашибис. Причём для 90% случаев все вышеперечисленные шаги абсолютно одинаковы. Очень хочется поставить это всё на автомат в IDE.
Чтож добрые дяди из MS подумали и сделали интеграцию UnitTest с MSVS. И вродебы теперь тесты писать легко и быстро.... но для .NET. Конечно можно пробрасывать unmanaged код чтобы потестировать.... но теряются все плюсы. Вобще хочется чтобы тесты были сильно привязаны к методу/процедуре которую они тестируют. Чтобы можно было не только go to header/definition но и go to Test.
Следующий шаг попытались сделать в питоньих тестах. PyTest кажется. Тест помещается сразу под объявлением метода в комментарии. Только чтобы протестировать метод со всех сторон надо написать более 4 тестов обычно + часто нагрузочные, которые могут быть из нескольких строк. В итоге получается километровый комментарий, что в купе с каким-нибудь автодокументирующим стилем комментариев создаст комментариев гораздо больше чем кода. Программирование превратится в сплошной скроллинг и не дай бог понадобится что-то подправить на месте в редакторе без схлопывания участков кода.
Так и сидим. UnitTest это хорошо. это agile, это модно. НО АБСОЛЮТНО неудобно. Поэтому пусть тесты пишут вновь принимаемые на работу. Заодно с кодом познакомятся.... а мы попишем новые фичи.
Чтож добрые дяди из MS подумали и сделали интеграцию UnitTest с MSVS. И вродебы теперь тесты писать легко и быстро.... но для .NET. Конечно можно пробрасывать unmanaged код чтобы потестировать.... но теряются все плюсы. Вобще хочется чтобы тесты были сильно привязаны к методу/процедуре которую они тестируют. Чтобы можно было не только go to header/definition но и go to Test.
Следующий шаг попытались сделать в питоньих тестах. PyTest кажется. Тест помещается сразу под объявлением метода в комментарии. Только чтобы протестировать метод со всех сторон надо написать более 4 тестов обычно + часто нагрузочные, которые могут быть из нескольких строк. В итоге получается километровый комментарий, что в купе с каким-нибудь автодокументирующим стилем комментариев создаст комментариев гораздо больше чем кода. Программирование превратится в сплошной скроллинг и не дай бог понадобится что-то подправить на месте в редакторе без схлопывания участков кода.
Так и сидим. UnitTest это хорошо. это agile, это модно. НО АБСОЛЮТНО неудобно. Поэтому пусть тесты пишут вновь принимаемые на работу. Заодно с кодом познакомятся.... а мы попишем новые фичи.
Неплохой сравнительный обзор тулзеней для поддержания agile методологии: linux.com . Надо потыкать Agilefant и IceScrum для общего развития.
вечра посетил AgileDays, было классно! Достаточно много интересных докладов по организации/управлению и туча интересных людей с богатым опытом, которым они не стеснялись делиться. Да, познакомился с клёвыми ребятами из e-legion! А ещё там был человек с фамилией Тян, глупо конечно смеяться, но ведь блин как тут не поржать :).
Agile is Dead: blog.recursivity.com — подписываюсь.
Только что обсуждали книгу "Адреналиновые наркоманы", было весело! Присоединяйтесь!
Обсуждали целый час "новую" книгу "User Stories Applied: For Agile Software Development". Книга — супер! Стади группа — еще лучше! Вобщем, LOTS OF FUN!!!
Когда приходит дедлайн, эджайл уходит.
Закончили обсуждать Скрам vs канбан. Было круто! Присоединяйтесь к нашей стади-группе! тоже будете полуночничать :-D
Agile Coaching by Rachel Davies, Liz Sedley. PDF. 5.64 Mb. depositfiles.com
Внедрение Agile напоминает езду на велосипеде. Чем быстрее едешь, тем стабильнее велосипед, нужно просто один раз поверить, что ты не упадешь и пересечь граничную скорость.
Инертность мышления — злоъ. Или падкость на инновации — злоъ. Я еще не определился.
Comparing Open Source Agile Project Management Tools
olex.openlogic.com
olex.openlogic.com
Только что на конфе прозвучала мудрая мысль (на обсуждении надо ли делать суперскрам скрамов для больших проектов) — а какого черта мы вообще делаем большие проекты, когда можно раздельно делать много маленьких?
Основной вопрос скрама — должен ли скраммастер рисовать бурнапчарты? :-D
А сейчас пошли какие-то лулзы под лозунгом cooking a product stew. На сцене два чувака в поварских костюмах делают шоу. :)
Еще раз: у команды должны быть все ресурсы для имплементации фичи — иначе будут отмазки типа "мы не успели потому что тот дизайнер опоздал с дизайнами дизайны, мы не виноваты".
Коммуникации и чувству общности очень способствует наличие представителя удаленной команды (просто представителя, не менеджера).
Необходимо создавать общую командную культуру — через обще ценности и цели.
Качество телефонной связи — архииважный фактор для распределенных команд. Видео не играет большой роли.
Вообше, необходимо использовать самый эффективный канал связи.
Нет ничего страшного в распределенных командах — наоборот, это позволяет акцентировать агильные практики.
Команда должна иметь в себе специалистов из всех необходимых областей для полной разработки фичи (программеров, дизайнеров, тестеров) — иначе она не может быть ответственной за результат.