Полное руководство по гибкой разработке программного обеспечения

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

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

Однако с 2015 года и ранее наблюдается одна тенденция : использование гибкого управления проектами растет (и это отлично подходит для разработки программного обеспечения!).

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

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

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

Полное руководство по гибкой разработке программного обеспечения

• История Agile
• Манифест Agile
• Гибкая разработка программного обеспечения
• Цикл гибкой разработки программного обеспечения
• Комментарий к гибкой разработке программного обеспечения
• Вывод

История Agile

Институт инженеров по электротехнике и электронике может проследить примитивные гибкие методы управления проектами вплоть до 1957 года в Лос-Анджелесе, где Берни Димсдейл, Джон фон Нейман, Херб Джейкобс и Джеральд Вайнберг тесно сотрудничали в разработке программного обеспечения для IBM и Motorola. Крейг Ларман, цитируя Вайнберга в его статье « Итеративные и инкрементальные разработки. Краткая история » , - сказал он:

«Все мы, насколько я помню, думали, что водопад огромного проекта был довольно глупым или, по крайней мере, игнорировал реалии. Я думаю, что описание водопада заставило нас понять, что мы занимаемся чем-то еще, чем-то безымянным, кроме «разработки программного обеспечения» ».

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

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

Только в 1970-х годах воцарился более формальный подход к гибкой разработке под руководством доктора Эрнеста Эдмондса , Тома Гилба и Центра разработки систем Нью-Йоркской телефонной компании. Идеи не получили широкого признания. Фактически, когда доктор Эдмондс представил свою идею в Journal of Computer Aided Design , она была немедленно отклонена. Единственный комментарий, который журнал отправил Эдмондсу, был: «Если вы не знаете, что собираетесь делать, прежде чем начать, не стоит начинать!» Затем он отнес свою работу в General Systems , которая в конечном итоге приняла его работу .

В 1990-е разработчики программного обеспечения были в упадке. Эта когорта программистов, в основном из демографического поколения X (родившиеся между 1961 и 1983 годами), были «детьми с замком» и перенесли свои подростковые годы против истеблишмента в офис. Как обнаружил Крейг Ларман, разработчики обнаружили, что водопад « строго регулируется, регулируется и управляется на микроуровне ». Это не сработало для этой когорты.

90-е годы принесли много облегченных и универсальных подходов к управлению проектами в разработке программного обеспечения, включая метод разработки динамических систем (DSDM), XP , Scrum и разработку, управляемую функциями (FDD). Хотя все эти системы существовали до Agile Manifesto, теперь они считаются частью гибкой методологии.

Манифест Agile

В период с 11 по 13 февраля 2001 года семнадцать человек встретились в The Lodge на горнолыжном курорте Snowbird, которых объединяли три вещи: любовь к еде, любовь к лыжам и « потребность в альтернативе основанным на документации тяжелым процессам разработки программного обеспечения . ” Они и по сей день безумно называют себя «организационными анархистами». На этом собрании все участники торжественно подписали Манифест гибкой разработки программного обеспечения [PDF], документ на семи страницах, посвященный четырем концепциям:

• «Люди и взаимодействие важнее процессов и инструментов.
• Рабочее программное обеспечение над исчерпывающей документацией.
• Сотрудничество с клиентами вместо переговоров по контракту.
• Реагировать на изменения вместо следования плану ».

В своей книге « История: манифест Agile » соучредитель Джим Хайсмит пишет:

Чтобы добиться успеха в новой экономике, агрессивно продвинуться в эпоху электронного бизнеса, электронной коммерции и Интернета, компании должны избавиться от своих Дилбертовских проявлений подделки и загадочной политики. Эта свобода от бессмыслицы корпоративной жизни привлекает сторонников гибких методологий и отпугивает новичков [так в оригинале] (вы не можете использовать слово «дерьмо» в профессиональной газете) от традиционалистов. Откровенно говоря, Agile-подходы пугают корпоративных бюрократов - по крайней мере, тех, кто с удовольствием продвигает процесс ради процесса, - вместо того, чтобы делать все возможное для «клиента» и предоставлять что-то своевременное, ощутимое и «как обещано», потому что им не хватает мест. прятаться. Примечание редактора: мы отредактировали исходный язык, чтобы он соответствовал блогу.

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

Примечание редактора: мы отредактировали исходный язык, чтобы он соответствовал блогу.

В «Манифесте Agile» подчеркивается, что ни один из авторов не верит в «теорию серебряной пули», поэтому определение «What Is Agile» становится таким сложным; основатели не думали, что у них есть ответы на все вопросы, и они не думали, что существует идеальная универсальная методология для каждой команды разработчиков. Их подход был обязательно либертарианским. Они подчеркивали в документе почти на каждом этапе: «Эта группа помогает, а не рассказывать. Члены Альянса хотят помогать другим с помощью Agile-методов и расширять свои знания, обучаясь у тех, кому мы пытаемся помочь ».

Возможно, именно подход к разработке программного обеспечения «мы не все знаем, но кое-что знаем» помог системе устоять.

Популярность Agile растет

Начиная с 2001 года, процессы управления проектами, основанные на Agile, резко выросли. Быстро появились Agile Alliance и Scrum Alliance, а также классика 2001 года - Agile Software Development with Scrum . Сертифицированные курсы Scrum стали обычным явлением, а такие термины, как «Scrum Master» и «самоорганизация», вошли в обиход менеджеров проектов. К 2007 году IBM объявила:

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

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

Гибкая разработка программного обеспечения

«Гибкое» управление проектами - это общий термин, охватывающий множество различных видов разработки программного обеспечения. Это включает в себя:

• Адаптивная разработка программного обеспечения (ASD)
• Кристалл
• Метод разработки динамических систем (DSDM)
• Экстремальное программирование (XP)
• Функционально-ориентированная разработка (FDD)
• Канбан (в зависимости от того, как вы его используете)
• Наклонять
• Scrum

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

1. Люди и взаимодействие важнее процессов и инструментов

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

Не поймите меня неправильно; Программное обеспечение для гибкого управления проектами - отличный ресурс для руководителей проектов. Этот вид программного обеспечения для управления проектами предлагает инструменты для улучшения коммуникации, отслеживания ошибок и планирования выпусков программного обеспечения. Но само программное обеспечение - это не то, что делает команду. VersionOne объясняет :

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

Другими словами, хотя люди в Snowbird были сосредоточены на создании метода разработки программного обеспечения, они хотели, чтобы в первую очередь внимание было сосредоточено на команде. Это их первое значение не зря. Философия заключается в том, что команды, которые не сотрудничают, обязательно будут медленнее адаптироваться к невзгодам и, таким образом, будут медлить с созданием высококачественного программного обеспечения с возможностью поставки.

Если Agile-команда будет придерживаться этого значения, следующие результаты будут идеальными:

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

2. Рабочее программное обеспечение, а не исчерпывающая документация.

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

Не верите мне?

Сколько раз вы подавали длинный отчет о расходах, ждали одобрения менеджера (или старшего менеджера, или вице-президента), чтобы продолжить выполнение задачи, или даже потратили часы для клиента?

Разве это не… в какой-то момент утомляет? Разве это не подавляет инновации?

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

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

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

Например, возьмем дом.

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

Вы закончили работу над домом на 65% , но в настоящее время у вас нет завершенных домов.

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

Если Agile-команда будет придерживаться этого значения, следующие результаты будут идеальными:

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

3. Сотрудничество с клиентами вместо переговоров по контракту.

Этот третий пункт часто неправильно понимают в Agile.

Не все сотрудничество с клиентами носит неформальный характер, и между заинтересованными сторонами и командами, безусловно, существуют контракты . Никто из тех, кто придерживается философии Agile, не станет спорить с этим. Однако , чтобы избежать недопонимания, энтузиасты Agile делают ставку на сотрудничество, а не на конфликт . Используя такое программное обеспечение, как Meisterplan , Sciforma и Eylean , менеджеры проектов могут быстро сообщать, где их команда находится в проекте, в режиме реального времени, поэтому ни один заказчик не останется в стороне от состояния своего проекта.

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

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

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

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

4. Реагирование на изменения вместо следования плану

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

Есть много сил, которые могут легко изменить направление продукта. Они могут включать, но не ограничиваются:

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

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

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

Если Agile-команда будет придерживаться этого значения, следующие результаты будут идеальными:

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

Цикл гибкой разработки программного обеспечения

Гибкая разработка программного обеспечения

Как я упоминал ранее, существует множество различных видов гибкой разработки программного обеспечения, но все они имеют четыре вышеупомянутые краеугольные характеристики. Независимо от того, используете ли вы Scrum, XP, Crystal, Feature-Driven Development или другой метод Agile, базовый Agile-подход остается неизменным.

1. Запустить проект.
2. Определите, что это за проект и каковы его цели.
3. Создайте руководящие принципы для требований проекта.
4. Разработайте программную функцию.
5. Интегрируйте функцию.
6. Протестируйте функцию.
7. Если проверка прошла успешно, перейдите к следующей функции и повторите шаги 4–6.
8. Если тест не удался, запишите, что пошло не так, и вносите изменения, пока функция не заработает.
9. Обдумайте и измените приоритеты на основе отзывов клиентов и новых проблем.
10. После тестирования и интеграции выпустите функцию на рынок.
11. Перейдите к разработке следующей функции и повторяйте шаги 4-10, пока проект не будет завершен.

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

Сертификация экзамена ISTQB

Комментарий к гибкой разработке программного обеспечения

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

Преимущества гибкой разработки программного обеспечения

Гибкую методологию можно разделить на семь преимуществ:

1. Внимание к качеству

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

2. Ориентация на клиента.

Agile делает упор на непрерывную поставку высококачественного программного обеспечения. Отзывы и удовлетворение клиентов напрямую влияют на разработку продукта.

3. Акцент на прозрачность и коммуникацию

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

4. Акцент на гибкость

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

5. Акцент на скорости.

Регулярные выпуски позволяют разработчикам программного обеспечения всегда иметь под рукой часть готового продукта. Скорость - это, вероятно, то место, где гибкость выигрывает больше всего. В 9-м обзоре State of Agile [PDF] наибольшим преимуществом внедрения гибких практик было «ускоренное предоставление продукта».

6. Сосредоточение внимания на снижении риска

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

7. Сосредоточение внимания на управлении экономным бюджетом.

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

Недостатки гибкой разработки программного обеспечения

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

1. Agile не подходит для государственных и крупных организаций.

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

2. Доставка может превзойти качество.

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

3. Стоимость сдачи игнорируется.

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

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

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

5. Agile требует обучения

В отчете State of Agile главная причина неудач гибких проектов - это «недостаток опыта в использовании гибких методов». В то время как управление проектами водопада более интуитивно понятно, Agile требует времени, чтобы научиться.

Вывод

Гибкая разработка программного обеспечения - это больше, чем просто увлечение проектным менеджментом; это дисциплина управления проектами с очевидными преимуществами, особенно для ИТ-команд. Методология управления проектами делает упор на прозрачность, итеративный процесс, коммуникацию и качество конечного продукта.

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

Я хотел бы услышать ваши мысли о гибкой разработке программного обеспечения. Я что-то пропустил? Оставляйте свои мысли в комментариях ниже!