Как разработать отличное программное обеспечение с гибкими методами?

Модель Kano удовлетворенности клиентов определяет различные классы свойств продукта. Среди них есть

1. Должные качества: если они не будут реализованы, покупатель не примет продукт.

2. Привлекательные качества (восхищающие): особенности, которые клиент часто даже не ожидает, но вызывают восхищение и восхищение, когда его обнаруживают.

Привлекательные качества, очевидно, имеют большую деловую ценность. Они заставляют людей покупать Ferrari за 500 000, когда использованный Fiat менее чем за 5 000 отвечает всем необходимым требованиям.

Тем не менее, все гибкие процессы, которые я знаю, строго поддерживают обязательные требования. Они всегда получают самый высокий приоритет. Кажется, в agile даже нет места для привлекательных качеств.

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

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

Формальный ответ: вы неправильно поняли гибкость, гибкость не диктует требования, заинтересованные стороны делают. Суть agile не в том, чтобы высечь ваши требования в камне, а в том, чтобы они возникали по мере вашего продвижения в тесном контакте с вашим клиентом, извлекая выгоду из прогрессивного понимания.

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

Проблема в том, что выслушивание клиента и быстрое реагирование на его нужды часто заканчиваются тем, что они не думают о продукте и не делают никакого дизайна вообще. То, что раньше было активным процессом, основанным на видении и опыте, может и часто превращается в пассивный, полностью реактивный процесс, основанный на пожеланиях клиента. Это приведет к тому, что мы сделаем только то, что нужно для работы.

Автомобиль никогда бы не изобрели, если бы производители в то время были бы «проворны», потому что все клиенты просили быструю лошадь.

Это не делает Agile плохим, хотя. Это немного похоже на коммунизм. Отличная идея, которая вряд ли когда-нибудь сработает, потому что люди - это просто люди, которые делают вещи для людей. И метод / идеология / религия внушает им мысль о том, что у них все хорошо, пока они проходят через движения и / или следуют правилам.

[редактировать]

Slebetman:

По иронии судьбы, Agile развился из автомобильной промышленности (а именно Toyota).

Помните золотое правило автоматизации? «Сначала организуй, потом автоматизируй». Если вы автоматизируете сломанный процесс, лучшее, что может случиться, - это ускорить все, что идет не так. Люди в Тойоте не были идиотами.

Типичная причина для принятия любой новой методологии заключается в том, что дела идут плохо. Руководство признает это, но они могут не понимать основные проблемы. Поэтому они нанимают этого гуру, который произносит речь об Agile и Scrum. И все любят это. По своим собственным причинам.

Разработчики могут подумать: «Эй, это может сработать. Мы были бы более вовлечены в вопросы бизнеса, и мы могли бы предоставить информацию для заполнения этого отставания. Это могло бы дать возможность отделу продаж и обслуживания клиентов понять, что мы делаем, почему это необходимо, и мы уберем их с волос, пока мы прозрачно сжигаем то, о чем договорились ». Не нужно больше "прекратить то, что ты делаешь, это нужно сделать сейчас", чувак, которого ты не хочешь откладывать, выскакивая за столом.

С другой стороны, отдел продаж, обслуживания клиентов или владелец могут рассматривать это как способ получить (вернуть) контроль над этим черным ящиком отдела, который, по-видимому, делает то, что необходимо. Они не видят, что там происходит, но они почти уверены, что суть проблемы скрыта где-то там. Таким образом, они представляют Scrum, устанавливают владельца продукта по своему выбору, и внезапно они имеют полный контроль, все струны находятся в их руках. И что теперь?

Реальная проблема часто заключается в том, что магазин не был хорошо организован, и это не изменилось. Людям были назначены обязанности, с которыми они не могут справиться, или, возможно, они могут, но г-н Босс постоянно вмешивается и разрушает то, что они сделали, или (чаще всего по моему опыту), важные обязанности не были признаны или назначены кому-либо вообще.

Иногда со временем между формальными линиями появляется неформальная организация. Это может частично компенсировать отсутствие формальной структуры. Некоторые люди просто делают то, что у них хорошо получается, есть ли у них визитная карточка, чтобы доказать это, или нет. Тупое введение Agile / Scrum может разрушить это мгновенно. Потому что теперь люди должны играть по правилам. Они чувствуют, что то, что они делали, не ценится, вместо этого они получают маленькие желтые бумажки с небольшими историями, и сообщение будет звучать так: «Что бы вы ни делали, никто не заботился». Излишне говорить, что это не будет особенно мотивировать этих людей. В лучшем случае они начнут ждать заказов и больше не будут проявлять инициативу.

Так что все становится хуже, и вывод будет таким, что Agile отстой.

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

Кажется, в agile даже нет места для привлекательных качеств.

Вы сравниваете яблоки и апельсины. В традиционном водопаде, если ваши требования говорят, что вам нужно обязательно, вы получаете Fiat. Если требования говорят, что это должно быть на высшем уровне, вы получаете Ferrari.

То же самое происходит в Agile. Если ваши требования останавливаются на необходимости, вы получаете Fiat. Если у вас есть истории для совершенства, вы получаете Ferrari. Все, что на самом деле ловко навязывает, - это то, что вы сначала должны сделать все необходимое . Не построить супер крутой спойлер в течение двух лет, а затем пропустить срок для двигателя.

Короче говоря, вы получаете то, что вам нужно. Если вы планируете спортивный автомобиль, вы получите спортивный автомобиль. Agile ничего не меняет. Если ваш гибкий процесс соответствует требованиям Fiat, не вините Agile, обвиняйте тех, кому нужен только Fiat.

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

Как они должны - посмотрите на вашу модель Kano еще раз: если необходимые требования не будут выполнены, покупатель не примет продукт. И тогда ваши восторги не имеют значения.

Кажется, в agile даже нет места для привлекательных качеств.

Нет ничего более далекого от правды.

Agile процессы обычно подчеркивают следующие моменты:

• Частая доставка работающего продукта, о которой вы можете получить отзывы.
• Разделите элементы на мелкие части, которые можно выполнить за короткое время.
• Реализуйте эти части в порядке приоритета.

Ничто не мешает вам придавать "восхитительным" функциям высокий приоритет. Это полностью зависит от людей, которые отвечают за определение приоритетов.

Теперь это правда, что многие такие люди предпочитают не рисковать и, следовательно, могут не отдавать высокие приоритеты «восторженным». Но в не проворном проекте это все равно будет иметь место.

Agile ничего не говорит о том, что должно быть сделано в первую очередь, только то, что код должен быть написан поэтапно, и как можно чаще должен быть доступен для восстановления, вместо того чтобы планировалось, что он будет недоступен в течение нескольких месяцев до следующего состояния, которое можно выпускать.

Я работал над процессами Agile и BDUF (Big Design Up Front), и хотя вы, безусловно, можете получить инновационные, привлекательные функции из обоих процессов, в BDUF, что неудивительно, вы должны планировать их заранее. Это означает, что инновации, как правило, должны предлагаться или, по крайней мере, спонсироваться людьми с большим влиянием в процессе проектирования.

Это потому, что у вас есть шесть месяцев (или что-то еще) до следующего релиза, и руководители проектов испытывают стресс по поводу того, что входит в этот релиз, потому что, если их функция не появится, пройдет еще шесть месяцев до следующего , Таким образом, в переполненном расписании есть полный список функций, и, если непритязательный рядовой человек будет замечен, работая в течение двух или трех дней над чем-то классным, он просто думает, что клиенту понравится, а его нет список, они рискуют весь график, и там будет ад платить.

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

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

Отличное программное обеспечение состоит из двух вещей:

• Предоставление клиенту того, что ему требуется

• Быть профессионалом

При разработке программного обеспечения необходимо соблюдать самые разные принципы. СУХОЙ, читабельной, ТВЕРДЫЙ и т. Д., Которые не имеют ничего общего с требованиями заказчика. Заказчик попросил спортивный автомобиль. Если клиент понимает, что нужно сделать, чтобы сделать спортивный автомобиль потрясающим, он бы вам не понадобился. Вам решать, что еще важно.

Частью нашей работы является поддержание стандартов, с которыми клиент никогда не столкнется, если что-то не пойдет не так.

Если вы делаете это правильно, Agile стремится к распоряжению только тогда, когда клиент действительно этого хочет. Не тогда, когда они считают, что должны согласиться.

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

Водопад до сих пор используется во многих магазинах по сей день. Эти магазины успешны, потому что их требования меняются менее чем на 2% в год.

Ваша задача не просто дать клиенту то, что он хочет. Это также заботиться о вещах, о которых вы знаете, что вы не получите никакого кредита вообще. Вещи, которые клиент никогда не расскажет, если вы не допустите, чтобы все пошло не так. Эти вещи лучше выбрать правильно, иначе вы потратите на них много дерьма.

Любой идиот может построить мост с неограниченным бюджетом. Профессионал строит мост, который почти никогда не падает.

Поэтому я считаю, что не следует рабски фокусироваться на обязательных требованиях.

Конечно, вы должны. За исключением оценки вашего времени. Потому что эти обязательные требования - не единственное соображение.

В порядке,

В Agile программист может создавать программное обеспечение, но, в конце концов, именно владелец продукта создает продукт. (с помощью разработчиков программного обеспечения.)

Что касается «привлекательных качеств», то это зависит от владельца продукта.

Если владелец продукта требует «сексуального дизайна», это может быть требованием. Разработчик не должен беспокоиться об этом выборе.

Кроме того, программное обеспечение настолько отличается от реальных физических продуктов, что я думаю, что большая часть модели Кано не применима. Например, почему я фейсбук? Единственная причина: потому что мои друзья делают. Как выразить это в следующем спринте ........ И еще одно из самых привлекательных качеств программного обеспечения - это то, что оно действительно делает то, что должно делать. (И тут Agile очень помогает: P)

Мой опыт согласуется с комментариями выше - нет ничего присущего в Agile , который препятствует развитию отличного программного обеспечения - однако есть несколько аспектов , как Agile часто (mal-) практиковал , которые приводят к программному обеспечению, только «достаточно хороший «.

• Agile делает акцент на получении чего-то работающего как можно скорее; однако это означает упрощение допущений и сокращение углов, особенно в невидимой для пользователя инфраструктуре. В этом нет ничего плохого, если затраты на исправление упрощающих предположений невелики; однако слишком часто этот «технический долг» не удаляется до того, как продукт поступает в производство;
• Agile проповедует, что в конце спринта у вас всегда должно быть что-то, настолько близкое к возможности отправки, насколько это возможно, чтобы заинтересованные лица и руководители проектов могли решить, что «то, что у них есть», достаточно хорошо, чтобы подтолкнуть производство. Опять же, нет ничего плохого в этом, есливы погасили весь свой «технический долг» (или заключили мир с тем, сколько у вас есть и где он находится). Однако, по моему опыту, слишком большой технический долг идет в производство с обещанием менеджера, что «мы Я уберу его, как только давление на судно исчезнет », которое быстро превращается в« оно находится в производстве, мы должны быть очень осторожны с тем, что мы меняем сейчас », которое в конечном итоге превращается в« Вы никогда не говорили мне, что у нас было такое воздействие! Мы должны сделать лучшую работу в следующий раз! " Урок Бена Франкина о «горечи плохого качества остается еще долго после того, как сладость низкой цены забыта», кажется, никогда не усваивается;
• Тем не менее, даже с доверчивыми менеджерами и хорошо дисциплинированными разработчиками, есть общая проблема , которая просто слишком мало надлежащий анализ, проектирование и анализ проекта происходит до начала спринта , в котором реализация , как ожидается , будет начата и завершено. Неспособность вдумчиво рассмотреть альтернативуМетафоры и дизайн пользовательского интерфейса велики - обычно слишком дорого пересматривать это после запуска проекта; неспособность младших команд тщательно изучить продукты своих конкурентов или расставить приоритеты при определении и внедрении инфраструктурных технологий, таких как I18N, инфраструктуры уведомлений, ведения журналов, безопасности и API-версий версий (например), что означает, что в конечном итоге они будут иметь более высокие ошибки, более низкая производительность и приведет к большему техническому долгу, чем если бы они только что потратили первые 2-5 спринтов заранее, выполняя необходимое обучение, анализ, проектирование и создание прототипов. Короче говоря, Agile команды должны сопротивляться лицензии на взлом;
• У меня был менеджер второго уровня (из более чем 100 разработчиков), который отговаривал его разработчиков отнимать время, чтобы записать запланированные проекты, даже на самом базовом уровне. Его рассуждение - «Я хочу, чтобы люди разговаривали друг с другом» - было иронично, потому что они были в 5 разных часовых поясах и 3 странах. Само собой разумеется, было много указаний на то, какой команде придется работать много ночей и выходных в конце проекта, когда они поняли, что все думают, что другой парень ответственен за реализацию некоторой функциональности (или повторная реализация, потому что проекты поставщика и потребителя просто не слились.)

На самом деле все сводится к тому, хотят ли менеджер проекта и заинтересованные стороны предоставить высококачественный продукт. Если они намерены это сделать, Agile включит его. OTOH, потому что Agile передает решения по расписанию исключительно в руки заинтересованного лица и менеджера проекта, Agile мешает команде разработчиков реализовать отличный проект без такой поддержки. Короче говоря, ответственность за качество продукции лежит почти исключительно на ногах руководителей проектов.

TL; DR

Фактически, гибкая разработка помогает вам повысить качество программного обеспечения, обеспечить удовлетворенность клиентов и предоставить очень ценный продукт.

Гибкие разработки были введены несколькими умными парнями для решения проблем, с которыми сталкиваются многие программные проекты в традиционных процессах.

Ключевые ценности гибкого развития, как это определено в гибком манифесте (1) :

• Индивидуумы и взаимодействия над процессами и инструментами
• Рабочее программное обеспечение на всеобъемлющей документации
• Сотрудничество с клиентами по контракту
• Реагирование на изменения по плану

Следовательно, гибкая разработка не мешает вам создавать качественное программное обеспечение. Гибкая разработка помогает вам поставлять высококачественное программное обеспечение.

Но действительно ли мы (и клиент) всегда заранее знаем, какие требования должны быть.

В этом весь смысл. Ориентируясь на отдельных лиц, клиент, рабочее программное обеспечение и изменения требований гибкой разработки помогут вам выяснить, чего хотят клиенты до того, как будет выпущен конечный продукт.

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

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

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

Я также хотел бы упомянуть Обратное качество - атрибуты, которые приводят к неудовлетворенности - модели Кано.

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

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

Гибкая разработка помогает вам выявлять неработающие или неудовлетворительные требования на раннем этапе и изменять их в ходе проекта.

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

Я довольно опоздал на эту вечеринку, но я хотел бы поделиться другим углом зрения на эту тему:

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

В гибкой разработке программного обеспечения есть временный аспект, который вытекает из итеративного подхода и учета отзывов клиентов , которые являются двумя важными элементами гибкой методологии. Пример: признаки, которые определены как привлекательное качество в итерации t, могут стать обязательным качеством в следующей итерации t + 1.

Применение гибких методов может динамически изменять категорию качества объекта. Если вы сравните запланированные функции итерации t с законченными функциями следующей итерации t + n, вы получите именно то, что вы упомянули:

Несколько раз я получал опыт, когда требования, которым вначале уделяли первоочередное внимание, оказывались гораздо менее важными, если не бесполезными, позже.

С учетом этого временного аспекта вполне вероятно, что гибкие методы могут создавать восхитительные высококачественные программные продукты , концентрируясь на минимуме . Итеративный подход в сочетании с обратной связи с клиентами меняет правила игры в течение долгого времени.

Заключение

Как разработать отличное программное обеспечение с гибкими методами?

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

   > How to develop excellent software with agile methods?

• При создании индивидуального программного обеспечения для клиента :
  • найдите покупателя там, где стоимость не имеет значения, потому что «восхитительная» функция стоит дополнительных денег, и клиент должен решить, хочет ли он заплатить за это.
• При производстве программных продуктов :
  • «Восхитительные» функции хороши для привлечения новых клиентов, а стоимость реализации «восхитительных» функций не так важна, если продукт продается более 1000 раз.
• В среде, где «достаточно хороший (самый дешевый) - лучший», вы не получите денег для реализации «восхитительных» функций

В команде Scrum владелец продукта несет ответственность за выбор функций, которые необходимо реализовать. Таким образом, это зависит от него (и до его бюджета), чтобы определить «хорошее, достаточное» или «отличное» программное обеспечение

Вы поднимаете некоторые хорошие моменты. Но я не верю, что эти проблемы ограничены гибкими процессами / методологиями.

Существуют разные мнения о том, что является существенным, а не второстепенным. Если использовать ваш пример, то кто-то, покупающий авто, может рассматривать привлечение внимания как существенную функцию и поэтому считает, что Fiat не соответствует этому обязательному требованию.
Более реалистично, чтобы программный продукт мог иметь определенную функциональность, чтобы удовлетворить потребности его фактических конечных пользователей ... но он также может нуждаться в определенных других функциях для продажи. Потому что лицо, санкционирующее покупку, часто не является конечным пользователем.
Таким образом, функция, которая является «несущественной» для конечного пользователя (ей), может иметь важное значение для продажи продукта ... и, следовательно, также важна для компании, создающей продукт.

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

Также важно иметь владельца (ов) продукта / заинтересованных лиц, которые уполномочены принимать решения. Если решения владельца вашего продукта постоянно отвергаются кем-то другим, я бы первым согласился с тем, что это проблема, но опять же, это не проблема Agile.

Есть и другие вещи, которые вы хотите видеть у своего владельца (ов) продукта ... я слышал одно описание "CRACK" (совместное, представительное, авторизованное, преданное и знающее). Владелец продукта, которому не хватает ни в одной из этих областей, может создать проблемы для проекта. Но я впервые услышал эту аббревиатуру в условиях водопада, поэтому очевидно, что боль плохих покупателей / владельцев продуктов не ограничивается гибкими магазинами.

Agile может (помочь) сделать, это вынести некоторые из этих проблем на поверхность.

Например, в литературе по XP IIRC довольно ясно говорит о том, что «клиент» осведомлен, доступен для команды и уполномочен принимать решения. Термин «владелец продукта» подразумевает определенный уровень знаний, приверженности и авторитета.

Если вы окажетесь в ситуации, когда большая часть поставляемых функций состоит из функций востребования, а не обязательных функций, гораздо легче поднять эту проблему (и намного легче определить причину), когда вы поставляете работающее или почти работающее программное обеспечение каждый раз. 2-3 недели, чем когда поставки с интервалом в несколько месяцев или лет.

Если вы работаете в небольших итерациях - и часто просматриваете отставание (включая пересмотр приоритетов) - это дает команде возможность учиться на предыдущих ошибках. «Кажется, сейчас это действительно важно, но помните динамическую навигацию, в которой мы были уверены, что нам нужно то, что мы в итоге не использовали?» Как отмечали другие, эти дискуссии гораздо менее вероятны, если все было спланировано заранее.

Напротив, методология предварительного проектирования предполагает (по умолчанию), что понимание продукта и функций является статичным. Это не был мой опыт: наличие чего-то осязаемого для работы почти всегда меняет понимание проблемы бизнесменами. Отсюда акцент на быстрой обратной связи. (Понимание разработчиков также меняется, но это не повлияет на приоритеты.)

Откладывание некоторых планов также позволяет вам реагировать на изменения в бизнес-потребностях. «Вы знаете тот веб-сайт, который вы создаете? Нам действительно нужно, чтобы это было мобильное приложение, способное к автономной работе». Это не то, о чем конкретно спрашивали ... но разве вы не хотели бы, чтобы ваш процесс мог реагировать на изменения в бизнес-среде (по крайней мере, в теории)?

Agile не говорит «не создавайте несущественные функции». В нем говорится «позволяют бизнесу решать, какие функции (а не) строить».
... и (что не менее важно) "позволяют техническим специалистам сообщать вам, сколько времени потребуется для создания нужной вам функции".

1. Must-be qualitiesчасто трудно определить. Люди имеют их в подсознании. Гибкие итерации и участие клиентов помогают найти большинство обязательных элементов. Это сила гибкости, и глупо пренебрегать ею .
2. One-dimensional qualitiesэто означает, что обещания, которые должны быть выполнены, поддерживаются водопадом, пока они не изменятся. Здесь ловкость только помогает, но не так сильно.
3. Attractive qualitiesхорошие особенности. Они могут стать обязательными в следующем поколении. Но в нынешнем поколении они даже не в соглашении - иначе они были бы одномерными качествами. Эти гибкие методы, предполагающие участие представителя клиента, очень хорошо поддерживают эти качества. Ибо мы можем слегка изменить сферу во время работы. Мы можем договориться об улучшении одного места для некоторой компенсации в другом. В водопаде это практически невозможно. Без большой организационной задержки мы могли бы только добавлять функции бесплатно. Это возможно, если какое-то дополнительное время ранее заложено в бюджет.

Таким образом, гибкие процессы могут поддерживать модель Кано, некоторые из них делают это значительно, и определенно намного лучше, чем лучшие проекты водопада.

Чтобы сделать это в вашем понимании, вы должны установить гибкие процессы с ответственным представителем клиента.