пятница, 21 декабря 2012 г.

Остров, о котором забыл 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?

22 комментария:

  1. Проблема всех XP практик это большой порог вхождения. Настроить CI сервер? Трахайся две недели, если это первый раз делаешь. Написать код через TDD? Обучайся два-три месяца. Производительность команды в это время просто отвратительная. Кто возьмет на себя расходы по обучению команд? По идее это должна делать компания вендор, но она часто преследует цель распилить бюджет проекта и сделать все как можно дешевле. Заказчик тоже не будет платить за обучение команды - он пришел со своей проблемой и хочет ее решения самым дешевым способом. Ему плевать на все эти TDD, BDD, CI, хороший код и архитектуру. Вот и получается замкнутый круг. Разработка сама по себе. Инженерные практики сами по себе.

    ОтветитьУдалить
  2. Это целиком и полностью ответственности команды. Не обязательно сразу и всем внедрять TDD к примеру. Без CI нельзя работать — его стоит в первую очередь настроить. В каждой команде есть более опытные эссиэмщики — пусть они и занимаются. Не вижу в этом проблемы. Проблемы в головах, а не в бюджетах или времени.

    ОтветитьУдалить
  3. Покажи мне хоть одну true agile компанию в Самаре и я поверю в это))

    ОтветитьУдалить
  4. Полезным нашел ориентировочные показатели метрик. :-) А то, что SCRUM приводит к загниванию процесса разработки -- это ж очевидно, потому что в SCRUM'е во главу угла поставлено всем известное фичивание, но только вроде как планируемое, а не "срочно надо сюда вот это!!".

    Далее будет жарко.

    >>Без CI нельзя работать — его стоит в первую очередь настроить.

    Спорны высказывания, потому что все это находится в Complex Cynefin.
    Да и вообще, весь мир Agile похож на чемодан самодельных инструментов, которыми умеют пользоваться только их создатели да и то только в своем проекте, который смогли вывести на успех. А истории успеха, как это уже многим известно, всегда уникальны.

    Просто взять чей-то подход и "в лоб" применять его у себя -- это нужно быть готовым к срыву бюджета и сроков, потому что хоть и есть Shuhari, да только вот отдача от внедрения приходит лишь на RI. Это стоит немало времени и усилий. Если же еще вспомнить, что нет одинаковых проектов (если проекты одинаковы, то Agile там не нужен, водопада хватит) -- то вообще весь этот цирк сложно представить работоспособным более, чем обычную прикладную научную исследовательскую работу в рамках конкретной темы с поставленными сроками сдачи и результатом в виде ПО.

    Спрашивается, если оно похоже, то почему же так оно не называется? Да просто ж все. Пойдите и найдите хоть одного бизнесмена, который будет платить за это. Никто не согласится, а если и согласится, то денег даст гораздо меньше. Так причем тут Agile? Да ни причем, просто слово красивое, через него можно себя хорошо продать.

    Я не против методов Agile, мне нравится и TDD, и CI, но просто нужно быть хотя бы с собой честным и не морочить голову коллегам.

    ОтветитьУдалить
    Ответы
    1. >>Просто взять чей-то подход и "в лоб" применять его у себя -- это нужно быть готовым к срыву бюджета и сроков, потому что хоть и есть Shuhari, да только вот отдача от внедрения приходит лишь на RI.

      если вы работаете над своим продуктом, а не выполняете заказную разработку, то почему бы и нет? Пригласить крутого эксперта, который вам все сделает и выстроит процесс и будет помогать его поддерживать?

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

      В остальном пост про метрики конечно очень противоречивый и немного странный. Метрики для мотивации?..

      Лично для меня он дал понимание одного из кейсов использования метрик.

      Удалить
  5. Есть предложение по переводу: 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. Очень хорошая статья, но на языке потенциального противника.

    А вообще хочется попросить организаторов блога провести какой-нибудь тренинг по монадам и по другим штукам из ФП.

    ОтветитьУдалить
    Ответы
    1. Тема ФП очень интересная тема, и я надеюсь в скором времени мы соберемся и устроим какое-нибудь мероприятие по ФП, в особенности по Scala или Erlang.

      Удалить
    2. По собственно переводу — спасибо! Я теперь знаю о чем писать следующий пост.

      Удалить
    3. Держите перевод! http://joydevel.blogspot.ru/2013/01/haskell-javascript.html

      Удалить
    4. Вов, может быть сделай в блоге xp.party ссылку на свой пост?
      имхо, это может быть интересно многим

      Удалить
    5. спойлер был опубликован. любопытно, кто-нибудь прочитал пост?

      Удалить
  6. Собственно, Scrum - это управленческая/организационная методология ведения проекта, призванная решить некоторые управленческие/организационные проблемы процесса разработки. Гипер-продуктивность скрама - это продуктивность, полученная за счет более простого и более эффективного управления/организации и заложенного механизма саморазвития.

    Кроме организационных/управленческих в процессе разработки есть еще дофига инженерных проблем. В какой-то момент только организационных мер увеличения/поддержания производительности становится недостаточно без развития инженерной технологии разработки, а это область адресуемая в т.ч. и практиками XP. Распространение метрик и награды - это организационное/управленческое средство, а до этого должен быть кто-то кто поймет инженерную проблему и предложит в нужный момент адекватную метрику. Ну или просто обозначит и решит техническую проблему.

    ОтветитьУдалить
  7. Касательно практики - я лично использую TDD, но практически, оно не распространено сейчас на всех.

    Continuous Integration мы также пока не ввели - для меня оно имеет смысл, только если есть множество функциональных тестов, которые там имеет смысл исполнять. Быстрые модульные тесты не слишком сложно запускаемы ручками.

    Парное программирование - нужно осознать проблему недостаточного шаринга знаний, зависимости от одного человека, несмелых технических решений и ресурсовозможности. Возможно это следующий шаг после TDD или вместе с повсеместным TDD.

    Какие там еще практики? (Было б неплохо где-нибудь справа подвесить список)

    ОтветитьУдалить
    Ответы
    1. во, нашёл как список повесить
      не всё, конечно перечислил, но наиболее популярные, по-моему, упомянул
      или что-то забыл всё-таки?

      Удалить
    2. В списке я бы повесил ссылки на википедию.

      Удалить
    3. Build Automation очень удобная практика которая экономит кучу времени даже если ты каждый раз деплоишь руками или как-то хитро и неавтоматизированно.

      Удалить
    4. Касательно парного программирования — его надо использовать повсеместно, но дозировано.
      Парное программирование даёт:
      - коллективное владение кодом (важнейшая практика в любой команде!)
      - ответственные участки кода сделаны лучше и более прозрачно, если работаете в паре над ними
      - шаринг знаний и навыков (именно навыков! в голове у одного программиста куча навыков которые могут помочь другому программисту — это где-то хоткеи, где-то нюансы конкретной среды или фреймворка, где-то просто удобный тул, которым пользуется один кодер, но о нем никогда не заходила речь и никогда не пользовался другой кодер)

      Ну и просто парное программирование это весело — это делает из бурундуков, сидящих по разным углам команду.

      Удалить
  8. Code Smells - да, а вот Code Review я пока не применял. Хорошо работает?

    Build Automation - да, применяем активно и чем дальше, тем активнее. Но не на всех проектах оно включает полное конфигурирование сервера с нуля - сложновато получается. Очень понятно, хотя и действительно долго во внедрении - особенно вещи типа выбора нужных фич для сборки и множественные конфигурации для разных сред. Было бы интересно почитать кто, что, как и для каких проблем использует.

    ОтветитьУдалить
    Ответы
    1. :) Code smells это не практика.

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

      Удалить