Майк Кон - Agile: оценка и планирование проектов

Тут можно читать онлайн Майк Кон - Agile: оценка и планирование проектов - бесплатно ознакомительный отрывок. Жанр: О бизнесе популярно, издательство Альпина Паблишер, год 2018. Здесь Вы можете читать ознакомительный отрывок из книги онлайн без регистрации и SMS на сайте лучшей интернет библиотеки ЛибКинг или прочесть краткое содержание (суть), предисловие и аннотацию. Так же сможете купить и скачать торрент в электронном формате fb2, найти и слушать аудиокнигу на русском языке или узнать сколько частей в серии и всего страниц в публикации. Читателям доступно смотреть обложку, картинки, описание и отзывы (комментарии) о произведении.
  • Название:
    Agile: оценка и планирование проектов
  • Автор:
  • Жанр:
  • Издательство:
    Альпина Паблишер
  • Год:
    2018
  • Город:
    Москва
  • ISBN:
    978-5-9614-5208-2
  • Рейтинг:
    3/5. Голосов: 11
  • Избранное:
    Добавить в избранное
  • Отзывы:
  • Ваша оценка:
    • 60
    • 1
    • 2
    • 3
    • 4
    • 5

Майк Кон - Agile: оценка и планирование проектов краткое содержание

Agile: оценка и планирование проектов - описание и краткое содержание, автор Майк Кон, читайте бесплатно онлайн на сайте электронной библиотеки LibKing.Ru
Оценка и планирование критически важны для успеха любого проекта. Однако процесс планирования сложен, и наши планы часто оказываются далекими от реальности. На помощь приходит Agile-подход. Благодаря Agile вы научитесь создавать реалистичные планы, которые сможете корректировать по ходу работы, при этом выполняя проекты в срок и в рамках бюджета.
Майк Кон, гуру в области Agile, дает инструменты, необходимые для оценки, планирования и управления Agile-проектами любого масштаба. В книге нет теоретических рассуждений, она полна конкретных примеров, методов, графиков, рецептов, а главное — аргументированных рекомендаций.

Agile: оценка и планирование проектов - читать онлайн бесплатно ознакомительный отрывок

Agile: оценка и планирование проектов - читать книгу онлайн бесплатно (ознакомительный отрывок), автор Майк Кон
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Во-первых, agile-команды планируют очень многое, но этот процесс более равномерно распределен по всему проекту. Во-вторых, agile-команды прямо учитывают тот критический фактор, который упускают из виду многие не использующие agile-подход команды, — неопределенность. Важно ли планирование? Несомненно, важно. Важна ли корректировка плана по мере накопления знаний и уменьшения неопределенности? Исключительно важна. Мне известно множество случаев, когда организации, которые на начальном этапе принимали нереальные обязательства, а потом не могли их выполнить, оказывались подходящими для заказчика, в то время как на тех, которые старались быть реалистичными (и понимали неопределенность), навешивали ярлык «неспособные соблюдать программу» или «некомандные игроки». Похоже, срыв поставки продукта считается приемлемым, а отказ принять обязательства (даже когда они очевидно нелепы) — нет. Agile-подход в мастерском представлении Майка сфокусирован на поставке ценного для пользователя продукта, а не на составлении ничем не оправданных и невыполнимых планов и принятии обязательств. Agile-разработчики, по существу, говорят: «Мы предоставим вам план на основе того, что нам известно в настоящий момент; мы будем адаптировать этот план так, чтобы реализовать вашу наиболее важную цель; мы будем адаптировать проект и наши планы по мере продвижения вперед и получения новой информации; мы ожидаем, что вы понимаете, о чем просите нас». Иными словами, гибкость, допускающая адаптирование к меняющимся условиям, и жесткое соблюдение первоначальных планов являются взаимоисключающими целями. В настоящей книге разбираются все эти утверждения.

Возвращаясь к критически важному вопросу управления неопределенностью, Майк превосходно показывает, как agile-подход к процессу разработки снижает одновременно и неопределенность целей (чтó мы реально хотим создать), и неопределенность средств их достижения (как мы будем создавать это). Многие сторонники традиционного планирования не понимают ключевого момента: планирование не устраняет неопределенность. Планы строятся на основе того, что мы знаем в данный момент. Неопределенность — это способ представления того, что нам неизвестно относительно целей и средств их реализации. Для большинства неопределенностей (отсутствия знания) единственным путем их снижения и приобретения знания является действие — выполнение каких-либо работ, создание чего-либо, моделирование чего-либо — и получение обратной связи. Подход многих руководителей проектов можно представить как «планирование, планирование, планирование — выполнение». Agile-подход — это «планирование — выполнение — адаптация», «планирование — выполнение — адаптация». Чем выше неопределенности проекта, тем важнее применение agile-подхода для успеха.

Я бы хотел проиллюстрировать «как» и «почему» из книги Майка на примере глав 4 и 5, где детально показано, как оценивать пользовательские истории в пунктах или идеальных днях, а также приведены все за и против для каждого из этих подходов. Я практиковал оба подхода при работе с клиентами, но слова Майка помогли кристаллизоваться моим представлениям об оценке историй в пунктах и позволили понять, что пункты являются частью эволюции — эволюции в направлении простоты. Организации, занимающиеся разработкой программного обеспечения, давно ищут ответ на вопрос «насколько велик данный элемент программного обеспечения?». Строитель способен дать довольно обоснованную оценку, имея данные о площади здания. Оценки разных строителей могут варьировать, но размер фиксирован (хотя отделочные работы, требования к материалам и т. п. также влияют на оценку) и остается постоянным. Разработчики программного обеспечения давно хотят иметь подобный показатель.

В сфере разработки программного обеспечения для измерения размера продукта поначалу использовали количество строк программы (этот показатель до сих пор не вышел из употребления). В текущем планировании, однако, количество строк программы находит ограниченное применение по целому ряду причин, включая трудозатраты на их подсчет. Затем на сцену вышли функциональные точки (и несколько аналогичных идей). Функциональные точки устраняли некоторые проблемы показателя количества строк, но по-прежнему требовали значительных трудозатрат для подсчета (нужно было оценивать входные данные, выходные данные, файлы и т. п.). Впрочем, на пути широкого использования функциональных точек встали не трудозатраты, а их сложность. По моему мнению, именно увеличение сложности подсчета — беглый просмотр веб-сайта International Function Point User Group (IFPUG) дает хорошее представление об уровне этой сложности — привело к сокращению использования этого показателя.

Так или иначе, потребность в оценке «размера» софтверного проекта никуда не исчезла. Проблема с обоими историческими показателями имеет две стороны — их сложно определять и они основаны на каскадном подходе к разработке. Нам же требуется показатель размера, который просто определить и можно применять без необходимости проходить все требования и фазы проектирования.

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

Еще одним примером тщательности изложения материалов Майком служат главы 9–11, посвященные приоритизации историй. Майк не ограничивается советом браться в первую очередь за истории с наивысшей стоимостью, а раскрывает ключевые аспекты стоимости: финансовые выгоды, затраты, инновации/знание и риск. Он дает четкие разъяснения по каждому из этих аспектов (включая общие представления о чистой приведенной стоимости, внутренней ставке доходности и других инструментах финансового анализа), а затем приводит ряд схем (с разной степенью упрощения) принятия решений по весам на основе рассмотренных аспектов стоимости.

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать


Майк Кон читать все книги автора по порядку

Майк Кон - все книги автора в одном месте читать по порядку полные версии на сайте онлайн библиотеки LibKing.




Agile: оценка и планирование проектов отзывы


Отзывы читателей о книге Agile: оценка и планирование проектов, автор: Майк Кон. Читайте комментарии и мнения людей о произведении.


Понравилась книга? Поделитесь впечатлениями - оставьте Ваш отзыв или расскажите друзьям

Напишите свой комментарий
x