Краткий план типового рассказа про Agile

Просмотрев десятки книг и докладов по Agile, я выделил некую типовую последовательность изложения. Она встречается во многих докладах и книгах в той или иной форме. Чтобы помочь будущим докладчикам и писателям я составил краткий план. Пользуясь им вы сэкономите кучу времени. И у меня просьба. Делайте ссылку, соответствует ваш доклад (книга) этому плану. Если это возможно.
– План ————————-

  1. Для начала немного истории - для тех, кто не в курсе. Agile методологии разработки родились в противовес классическим моделям, в которых результата пытались достичь за счет процессов, процедур и регламентов.
  2. Естественно получалось фуфло.
  3. Мы у себя внедрили Agile.
  4. Сейчас я вам расскажу, какие классные процессы, процедуры и регламенты мы у себя внедрили.
  5. Далее перечисляется некий набор процессов, процедур и регламентов, в зависимости от автора.

– Конец плана —————–

Коллеги, это только я вижу некое несоответствие в этих пунктах?

Комментариев: 10

  1. Anthony Marchenko написал:

    моему не совсем соответствует - «Опыт внедрения Канбан в продуктовой компании» :)
    1. рассказ про компанию.
    2. рассказ почему мы отказались от скрама.
    4. То что осталось - назвали Канбан.

    То есть как мы эволюционировали. Как было хорошо, и как мы сделали ещё лучше.
    Ни хочу показаться не вежливым, (только что вернулся из AgileIndia2012.in), но все доклады которые делали индусы, полностью соответствуют вашему плану. В американских же докладах, больше было про Programmer Anarchy и старательно избегали слово Agile.

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

  2. Григорий Печенкин написал:

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

  3. SALar написал:

    > 4. То что осталось - назвали Канбан.
    Почему то мне кажется, что то, что вы назвали Канбаном, имеет такое же отношение к канбану, какое утконос имеет к проектированию дирижаблей. Но слово модное. Это да.

    > но все доклады которые делали индусы, полностью соответствуют вашему плану
    LOL.

    > как мы отказались от диктатуры, и пришли к демократии
    А не подскажете методологию, которая предполагает диктатуру? Мне на ум кроме XP ничего не приходит. XP - очень жесткая, диктаторская методология.

  4. Apoheliy написал:

    2.255:
    Убираем слова “процессы, процедуры, регламеты” в п.1 - и жизнь налаживается :) . В смысле, план становиться живее.

    2.Григорий Печенкин:
    Можно добавить, что мух было всего 3.

    2.SALar
    Можно вспомнить про WaterFall - тоже с диктатурой дружит :)

    2.255:
    Для полноты картины нужно написать аналогичный план для классических методологий:
    1. Для начала - немного истории: WaterFall используется в противовес Agile.
    2. Мы использовали Agile - и получилось фуфло. YAGNI в паре с KISS - и разработка/тестирование из уютного офиса переносится на ‘объект’. И blah-blah-blah, и всё недоделано, и blah-blah-blah, и всё нестабильно …
    3. Мы внедрили WaterFall с примесью Инкремента и др.
    4. А сейчас я расскажу о классных процедурах …
    5. … Далее в зависимости от автора …
    6. И назвать методологию ‘Канбан’ :)

  5. SALar написал:

    > Можно вспомнить про WaterFall - тоже с диктатурой дружит
    С какой радости? Вы статью Ройса читали или вам ее “консультанты” пересказали? Ройс довольно много говорит о людях. В отличии от “псевдоконсультанотов”.

    > WaterFall используется в противовес Agile.
    Какая чушь. Аж уши в трубочку сворачиваются.
    Сам Ройс описал итеративную модель разработки. Кроме того WaterFall это ЖЦ, а ни разу не методология. Не надо подобно “консультантам/тренерам/коучам” путать теплое с мягким. ЖЦ класса WaterFall, даже не итеративный Ройсовский, а однопроходный “консультантовский” вполне можно использовать в Agile. Да, это противоречит Scrum и XP, но на них свет клином не сошелся. Agile манифест ничего не говорит о выборе ЖЦ. Какой удобней, такой и используй.

    > 6. И назвать методологию ‘Канбан’
    А за это нужно вообще гнилыми помидорами кидаться.

  6. ytrewq написал:

    > WaterFall используется в противовес Agile.

    как выглядит знакомо.

    Википедия (статья Гибкая методология разработки) гласит: В феврале 2001 в штате Юта США был выпущен Манифест гибкой методологии разработки ПО. Он являлся альтернативой управляемым документацией, «тяжеловесным» практикам разработки программного обеспечения, таким как «метод водопада», являвшимся золотым стандартом разработки в то время.

    Где-то здесь перепутано теплое с мягким, я пока ленюсь разбираться, где. Нно я разберусь. Ройса прочту вдумчиво.

  7. Apoheliy написал:

    Э-э-э, как бы помягче сказать, здесь не Ройса обсуждают :) И то, что Ройс использовал итеративную модель означает примерно “в огороде бузина”. В любом случае (вне зависимости, прав я или нет) хотелось бы аргументации, почему водопад не дружит с диктатурой.

  8. Apoheliy написал:

    2SALar: Про не-идеализацию Ройса написал ранее.
    Про WaterFall соглашусь, что в основном про него говорят, как про ЖЦ. Хотя про него же говорят и как про метод/практику разработки ПО (управление документацией, и др.).
    Если рассматривать сам Agile (а именно - манифест), то из него (как Вы правильно отмечаете) вообще мало что можно вывести. Однако, IMHO:
    - WF говорит про важность процесса (а не людей);
    - WF даёт рабочий продукт после этапов интеграции и, однозначно, после созданной документации (в Agile-манифесте - наоборот);
    - WF очень сильно ориентирован на контракт и его ЖЦ не предполагает изменений (и это тоже против Agile);
    Поэтому противопоставление этих понятий вполне возможно (IMHO). Ваше мнение?

    PS: Канбан - это шутка, помеченная знаком ‘:)’ :)

  9. Apoheliy написал:

    2SALar: на WaterFall есть стандарт IEEE Std 1074 лучше оценивать по нему, а не по Ройсу.

  10. SALar написал:

    > - WF говорит про важность процесса (а не людей);
    Ройс очень много говорил про людей. Это вы скорее про дальнейших “интерпретаторов”. Но. Но.Но.
    Асхат Уразбаев на всех докладах, на которых я был, говорит про процессы, процессы и процессы. Исходя из этого… Ну вы поняли.

    > (в Agile-манифесте - наоборот);
    Это неправда. В манифесте не запрет, а смещение акцентов важности.

    > WF очень сильно ориентирован на контракт и его ЖЦ не предполагает изменений
    Это не совсем правда. Здесь лучше перечитать статью Ройса.
    Кстати. Существует масса способов работы с изменениями. Запрет на изменения один из них. Вполне нормальный.

Оставьте комментарий

Вы должны войти, чтобы оставить свой комментарий.