Всем привет!
Несколько минут назад, я опубликовал очень важный, на мой взгляд, для всего российского Agile сообщества перевод статьи Боба Мартина «Остров, о котором забыл Scrum» (в оригинале "The land that Scrum forgot"), опубликованной в ленте новостей Scrum Alliance.
В статье автор поднимает одну из важнейших проблем — гипер-продуктивность Scrum команд. Точнее, как эту самую гипер-продуктивность поддерживать. Автор вкратце рассказывает о метриках и практиках XP, но самое главное, он дает направление к пониманию того, как это всё применять на практике...
Жду ваши ценные комментарии по поводу перевода в своем уютненьком: http://joydevel.blogspot.ru/2012/12/the-land-that-scrum-forgot-scrum.html
А здесь ожидаю бурную полемику среди разработчиков и Scrum мастеров!
На затравку вопрос к вам: какие из практик XP вы используете в своих командах? Как они вам помогают? Почему вам не нравится Scrum?
Несколько минут назад, я опубликовал очень важный, на мой взгляд, для всего российского Agile сообщества перевод статьи Боба Мартина «Остров, о котором забыл Scrum» (в оригинале "The land that Scrum forgot"), опубликованной в ленте новостей Scrum Alliance.
В статье автор поднимает одну из важнейших проблем — гипер-продуктивность Scrum команд. Точнее, как эту самую гипер-продуктивность поддерживать. Автор вкратце рассказывает о метриках и практиках XP, но самое главное, он дает направление к пониманию того, как это всё применять на практике...
Жду ваши ценные комментарии по поводу перевода в своем уютненьком: http://joydevel.blogspot.ru/2012/12/the-land-that-scrum-forgot-scrum.html
А здесь ожидаю бурную полемику среди разработчиков и Scrum мастеров!
На затравку вопрос к вам: какие из практик XP вы используете в своих командах? Как они вам помогают? Почему вам не нравится Scrum?
Проблема всех XP практик это большой порог вхождения. Настроить CI сервер? Трахайся две недели, если это первый раз делаешь. Написать код через TDD? Обучайся два-три месяца. Производительность команды в это время просто отвратительная. Кто возьмет на себя расходы по обучению команд? По идее это должна делать компания вендор, но она часто преследует цель распилить бюджет проекта и сделать все как можно дешевле. Заказчик тоже не будет платить за обучение команды - он пришел со своей проблемой и хочет ее решения самым дешевым способом. Ему плевать на все эти TDD, BDD, CI, хороший код и архитектуру. Вот и получается замкнутый круг. Разработка сама по себе. Инженерные практики сами по себе.
ОтветитьУдалитьЭто целиком и полностью ответственности команды. Не обязательно сразу и всем внедрять TDD к примеру. Без CI нельзя работать — его стоит в первую очередь настроить. В каждой команде есть более опытные эссиэмщики — пусть они и занимаются. Не вижу в этом проблемы. Проблемы в головах, а не в бюджетах или времени.
ОтветитьУдалитьПокажи мне хоть одну true agile компанию в Самаре и я поверю в это))
ОтветитьУдалитьПолезным нашел ориентировочные показатели метрик. :-) А то, что SCRUM приводит к загниванию процесса разработки -- это ж очевидно, потому что в SCRUM'е во главу угла поставлено всем известное фичивание, но только вроде как планируемое, а не "срочно надо сюда вот это!!".
ОтветитьУдалитьДалее будет жарко.
>>Без CI нельзя работать — его стоит в первую очередь настроить.
Спорны высказывания, потому что все это находится в Complex Cynefin.
Да и вообще, весь мир Agile похож на чемодан самодельных инструментов, которыми умеют пользоваться только их создатели да и то только в своем проекте, который смогли вывести на успех. А истории успеха, как это уже многим известно, всегда уникальны.
Просто взять чей-то подход и "в лоб" применять его у себя -- это нужно быть готовым к срыву бюджета и сроков, потому что хоть и есть Shuhari, да только вот отдача от внедрения приходит лишь на RI. Это стоит немало времени и усилий. Если же еще вспомнить, что нет одинаковых проектов (если проекты одинаковы, то Agile там не нужен, водопада хватит) -- то вообще весь этот цирк сложно представить работоспособным более, чем обычную прикладную научную исследовательскую работу в рамках конкретной темы с поставленными сроками сдачи и результатом в виде ПО.
Спрашивается, если оно похоже, то почему же так оно не называется? Да просто ж все. Пойдите и найдите хоть одного бизнесмена, который будет платить за это. Никто не согласится, а если и согласится, то денег даст гораздо меньше. Так причем тут Agile? Да ни причем, просто слово красивое, через него можно себя хорошо продать.
Я не против методов Agile, мне нравится и TDD, и CI, но просто нужно быть хотя бы с собой честным и не морочить голову коллегам.
+1
Удалить>>Просто взять чей-то подход и "в лоб" применять его у себя -- это нужно быть готовым к срыву бюджета и сроков, потому что хоть и есть Shuhari, да только вот отдача от внедрения приходит лишь на RI.
Удалитьесли вы работаете над своим продуктом, а не выполняете заказную разработку, то почему бы и нет? Пригласить крутого эксперта, который вам все сделает и выстроит процесс и будет помогать его поддерживать?
SCRUM имхо более дружелюбен к разработке продуктов, т.к. позволяет очень грамотно управлять рисками и поддерживать очень четкий фокус на продукте.
В остальном пост про метрики конечно очень противоречивый и немного странный. Метрики для мотивации?..
Лично для меня он дал понимание одного из кейсов использования метрик.
Есть предложение по переводу: http://blog.jcoglan.com/2011/03/05/translation-from-haskell-to-javascript-of-selected-portions-of-the-best-introduction-to-monads-ive-ever-read/ . Статья про монады с примерами на JavaScript. Очень хорошая статья, но на языке потенциального противника.
ОтветитьУдалитьА вообще хочется попросить организаторов блога провести какой-нибудь тренинг по монадам и по другим штукам из ФП.
Тема ФП очень интересная тема, и я надеюсь в скором времени мы соберемся и устроим какое-нибудь мероприятие по ФП, в особенности по Scala или Erlang.
УдалитьПо собственно переводу — спасибо! Я теперь знаю о чем писать следующий пост.
УдалитьДержите перевод! http://joydevel.blogspot.ru/2013/01/haskell-javascript.html
УдалитьВов, может быть сделай в блоге xp.party ссылку на свой пост?
Удалитьимхо, это может быть интересно многим
спойлер был опубликован. любопытно, кто-нибудь прочитал пост?
Удалить+1 к Scala.
УдалитьСобственно, Scrum - это управленческая/организационная методология ведения проекта, призванная решить некоторые управленческие/организационные проблемы процесса разработки. Гипер-продуктивность скрама - это продуктивность, полученная за счет более простого и более эффективного управления/организации и заложенного механизма саморазвития.
ОтветитьУдалитьКроме организационных/управленческих в процессе разработки есть еще дофига инженерных проблем. В какой-то момент только организационных мер увеличения/поддержания производительности становится недостаточно без развития инженерной технологии разработки, а это область адресуемая в т.ч. и практиками XP. Распространение метрик и награды - это организационное/управленческое средство, а до этого должен быть кто-то кто поймет инженерную проблему и предложит в нужный момент адекватную метрику. Ну или просто обозначит и решит техническую проблему.
Касательно практики - я лично использую TDD, но практически, оно не распространено сейчас на всех.
ОтветитьУдалитьContinuous Integration мы также пока не ввели - для меня оно имеет смысл, только если есть множество функциональных тестов, которые там имеет смысл исполнять. Быстрые модульные тесты не слишком сложно запускаемы ручками.
Парное программирование - нужно осознать проблему недостаточного шаринга знаний, зависимости от одного человека, несмелых технических решений и ресурсовозможности. Возможно это следующий шаг после TDD или вместе с повсеместным TDD.
Какие там еще практики? (Было б неплохо где-нибудь справа подвесить список)
во, нашёл как список повесить
Удалитьне всё, конечно перечислил, но наиболее популярные, по-моему, упомянул
или что-то забыл всё-таки?
В списке я бы повесил ссылки на википедию.
УдалитьBuild Automation очень удобная практика которая экономит кучу времени даже если ты каждый раз деплоишь руками или как-то хитро и неавтоматизированно.
УдалитьКасательно парного программирования — его надо использовать повсеместно, но дозировано.
УдалитьПарное программирование даёт:
- коллективное владение кодом (важнейшая практика в любой команде!)
- ответственные участки кода сделаны лучше и более прозрачно, если работаете в паре над ними
- шаринг знаний и навыков (именно навыков! в голове у одного программиста куча навыков которые могут помочь другому программисту — это где-то хоткеи, где-то нюансы конкретной среды или фреймворка, где-то просто удобный тул, которым пользуется один кодер, но о нем никогда не заходила речь и никогда не пользовался другой кодер)
Ну и просто парное программирование это весело — это делает из бурундуков, сидящих по разным углам команду.
ссылочки добавио
УдалитьCode Smells - да, а вот Code Review я пока не применял. Хорошо работает?
ОтветитьУдалитьBuild Automation - да, применяем активно и чем дальше, тем активнее. Но не на всех проектах оно включает полное конфигурирование сервера с нуля - сложновато получается. Очень понятно, хотя и действительно долго во внедрении - особенно вещи типа выбора нужных фич для сборки и множественные конфигурации для разных сред. Было бы интересно почитать кто, что, как и для каких проблем использует.
:) Code smells это не практика.
УдалитьCode Review это дико круто и улучшает коллективное владение кодом, избавляет код от потайных мест, наследованных от прошлых разработчиков и в целом развивает командный дух :) Можно прекрасно совмещать с парным программированием.