|
 Все больше компаний внедряют методы гибкой разработки в ответ на требования клиентов реализовывать изменение быстрее и дешевле. Однако в сообществе гибкой методики наблюдается скептицизм в отношении достижения организациями желаемых выгод. Для преуспевания в гибкой методике организации сначала должны понять основные цели гибкости и затем решать, подходит ли им эта методика.
Большинство проблем, возникающих в гибких проектах, обусловлено тем, что организации не понимают основных целей гибкости. Считается, что при использовании гибкой методики проекты требуют меньше времени, меньше расходов и несут меньше риска. Такое заблуждение дорого обходится.
Для многих организаций гибкость требует значительных изменений культуры и процессов, которые нельзя осуществить одним лишь внедрением гибкой методики. Истинная гибкость требует постановки под сомнение существующих процессов, иерархий управления и способов управления – нечто, что многие компании часто не хотят делать.
Отвратительный
Отвратительные реализации гибкой методики обычно осуществляются проектными группами, желающими сразу же взяться за производство программного обеспечения, обходясь без так называемой традиционной волокиты, или же опробовать очередное «крупное дело». Они убеждают своих линейных руководителей в выгодах, но не разъясняют выгоды коммерческим потребителям или членам других производственных групп.
В результате коммуникация плохая, и участие важнейших коммерческих пользователей отсутствует. Члены проектной группы работают независимо (чтобы сделать свой кусок работы) в отличие от совместного производства продукта для клиента в комплекте. Процессы гибкой методики (например, ежедневные совещания для информирования о состоянии дел, графики прогресса разработки и митинг) выполняются ежедневно, но главные проблемы остаются нерешенными, и проект быстро сходит с верного пути. Восстановление возможно, но длится долго, возвращая организации в прежнее состояние.
Отвратительные реализации гибкой методики направлены лишь на реализацию методики, тем самым теряя выгоды, даваемые истинной гибкостью.
Плохой
Плохие реализации гибкой модели обусловлены желанием фирмы сократить расходы, сроки и традиционную волокиту. Организация не придерживается полностью ценностей «гибкого манифеста» и не добивается подлинной гибкости.
Вкладываются средства в коммуникацию и обучение, но игнорируются инструменты и техники, необходимые для обеспечения гибкости. Формируются группы специалистов разного профиля, но им не разрешается принимать ключевые решения на консультациях с ключевыми коммерческими заинтересованными лицами и потребителями.
Проводятся регулярные проверки проекта, но полностью на основании их результатов никогда не действуют, и главные проблемы остаются. Проект, вероятно, сдается, но опыт оказывается настолько тягостным, что никто не хочет его повторять.
Хороший
Хорошие реализации гибкой модели являются результатом сотрудничества фирмы и отдела ИТ для внедрения методологии выполнения проектов, удовлетворяющей потребности организации, и вкладываются в организационные изменения, требуемые для реализации выгод.
Ключевые коммерческие заинтересованные лица, коммерческие потребители, члены группы и высшее руководство обучаются, и формируются истинно уполномоченные группы специалистов разного профиля. Вкладываются средства в инструменты и техники, требуемые для поддержки гибкой методики (стандарты, непрерывная компоновка, разработка на основе тестирования, парное программирование и т.д.) с целью создания платформы для успеха.
Регулярные проверки проекта рассматриваются как возможности для улучшения, в отличие от неизбежного зла. Изменение принимается и планируется, поэтому, когда оно приходит, то легко воспринимается. Хорошие реализации гибкой концепции обеспечивают внедрение долгосрочных изменений, требуемых для получения выгод от концепции.
Хорошая реализация гибкой концепции является трудной задачей для любой организации. Она требует внутренних изменений подхода к выработке проекта. Она подвергает сомнению традиционную структуру «руководитель – группа» и основывается на решениях немногих уполномоченных людей, в отличие от большого комитета. Она требует от проектных групп постоянно акцентировать внимание на своих ошибках и совместно работать над их устранением.
Взамен она обеспечивает повторяющуюся, своевременную и качественную сдачу проекта, приоритет которой определяется на основе реальной коммерческой потребности. Она строит общность высокомотивированных, многофункциональных и уполномоченных людей, сосредоточенных на достижении общей цели. Она создает базу для долгосрочной успешной сдачи проектов путем реализации стандартов, постоянной интеграции, разработки на основе тестирования и объединенной разработки приложений.
Путь к хорошей гибкой модели
1. Не действуйте слишком поспешно
Большинство организаций необдуманно бросается в гибкую методику в ответ на потребность фирмы в более быстрой и дешевой выработке проекта. Чаще всего проект проваливается, впустую растрачивая кучу денег.
Сосредоточьтесь на понимании реальных потребностей вашей фирмы. Спросите себя, подходит ли гибкая модель для вашей организации. Изучите ваши текущие процессы и по возможности улучшите, используя элементы основной гибкой методики для обеспечения нужд фирмы.
2. Обучайте ваших заинтересованных лиц
Суть гибкой методики заключается в регулярности и качественной сдаче проекта, в отличие от снижения расходов и сокращения сроков. Эти выгоды придут со временем, но первоначальные вложения должны быть сделаны со временем.
3. Получите одного заинтересованного заказчика продукта в фирме
В сфере гибкой методики заинтересованный потенциальный клиент, именуемый заказчиком продукта, крайне необходим, иначе проект нет смысла делать (т.е. зачем производить нечто ненужное). В идеальном мире существует только один заказчик продукта, уполномоченный принимать ключевые решения. В реальности это не всегда так, но человек, назначенный на проект в роли заказчика продукта, должен: a) посвящать как минимум 50 процентов своего времени проекту; b) отвечать за своевременное принятие надлежащих решений вне своей сферы компетенции.
4. Поймите и согласуйте ваше определение сделанного
Большинство гибких методик призывает к сдаче готового к производству программного обеспечения в конце каждой итерации. В большинстве новых реализаций ПО это невозможно, пока не создано и не развернуто ядро решения. Нужно с начала проекта согласовать ваше определение сделанного, выпустить продукт в соответствии с ним, избегая бесконечной разработки или создания прототипа.
5. Постройте свою межфункциональную группу
Гибкие группы не функционируют эффективно, если не являются подлинно межфункциональными (состоящими из специалистов разного профиля). Группа должна уметь выполнять все задачи, необходимые для реализации требований клиентов, например, применение на практике журнала требований по приоритетам.
После определения членов группы нужно потратить время на сплочение их в группу и убеждение их стремиться к общей цели – чтобы произвести продукт для заказчика продукта.
6. Инвестируйте в инструменты и предоставляемые результаты, требуемые для обеспечения гибкости
Первые несколько этапов вашего гибкого проекта нужно потратить на установку каркасов и инструментов автоматизации процессов, требуемых для обеспечения гибкости (например, программные каркасы, серверы непрерывной компоновки, автоматизация тестирования, хранилище текстов пользователя, настольные средства видеоконференцсвязи, чат и т.д.). Обеспечьте заполнение журнала незавершенных задач по продукту настолько большим количеством деталей, насколько позволяет время и выработанная архитектура решения. Эти предоставляемые результаты, которые потенциально могут изменяться, будут служить образцом для вашей отправной точки.
7. Уделяйте первоочередное внимание качеству ретроспективы
Гибкая методика касается проверки и приспособления. Средство, используемое для выполнения данной деятельности, обычно именуется ретроспективой. Ретроспектива должна способствовать прозрачности и повышению квалификации. Действиям, вытекающим из ретроспективы, должно уделяться первоочередное внимание, особенно в сфере оценки. Точная оценка крайне важна для достижения постоянной скорости группы, чтобы вовремя устранить переутомленного и немотивированного члена группы.
8. Заранее создавайте архитектуру решения
Неверно, что гибкая методика не требует документации. Гибкая методика ценит рабочее ПО больше, чем документацию. Однако если документация требуется для выпуска рабочего ПО – она абсолютно необходима.
Архитектура решения или список функциональных требований является главным документом. Он предоставляет модель того, что проектная группа собирается выпустить. Без него проектная группа не сможет понять влияние изменения. Если этот документ не поддерживается, будущие проектные группы будут испытывать трудности с пониманием базовых компонентов решения.
9. Планируйте и принимайте изменение
Любое изменение обходится высокой ценой, даже в гибкой методике. «Гибкий манифест» ценит принятие изменения, но не заявляет, что изменение должно внедряться без затрат. Не забывайте включать стоимость любой потенциальной переделки, вызываемой изменением, в состав вашего процесса оценки.
10. Развивайте сотрудничество с вашими внешними поставщиками
Гибкая методика плохо сочетается с традиционными договорными соглашениями с поставщиками (фиксированная цена, фиксированный результат) и часто вынуждает организации тратить больше времени на управление договором, чем на реализацию требований заказчика.
Сотрудничайте с вашими внешними поставщиками с целью построения прозрачных отношений и взаимовыгодного договорного соглашения. Если вы не хотите использовать модель времени и материалов, договорные соглашения на базе риска и вознаграждения с четко определенными ключевыми показателями эффективности хорошо работают в гибком сотрудничестве.
|
