ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.10.2023
Просмотров: 362
Скачиваний: 11
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
1 2 3 4 5 6 7 8 9 10 ... 20
Глава 2. Почему же Agile?
104
Разработчики имеют право на помощь от коллег, руководителей
и самих клиентов.
Такая помощь может выражаться по-разному . Программисты могут просить друг у друга помощи в решении задач, сверке результатов, в изучении фреймворка и во многом другом . Разработчики могут попросить клиентов лучше объяснить требования или уточнить приоритеты . По большей части, этот постулат дает разработчикам право на взаимодействие . И с правом просить о помощи приходит и ответственность — помогать, когда просят .
Разработчики имеют право на оценку задачи и ее уточнение
в зависимости от обстоятельств.
Никто не сможет оценить задачу за вас . И если вы даете оценку задаче, у вас всегда есть возможность ее изменить по мере появле- ния новых факторов . Ведь оценки основаны на предположениях .
Конечно, эти догадки небезосновательны, но они и остаются до- гадками . Эти догадки становятся точнее со временем . Оценка не может быть обязательством .
Разработчики имеют право самостоятельного принятия на себя
ответственности и недопущения возложения на себя лишнего.
Профессионалы принимают предложения по работе, а не назна- чение заданий . Разработчик имеет полное право говорить «нет», если его не устраивает какая-либо работа или задание . Может быть такое, что разработчик не уверен в своих способностях выполнить ту или иную задачу или, может быть, считает, что кто-то другой справится лучше, чем он . Или, допустим, разработчик отказыва- ется из личных или моральных соображений
1 1
Вспомните разработчиков из «Фольксваген», которые «согласились» выполнить задание обойти испытания на количество выбросов вредных веществ в атмосферу . https://ru.wikipedia.org/wiki/Дело_Volkswagen.
Заключение
105
В любом случае за право выбора приходится платить . Принятие предложения налагает ответственность . Согласившийся раз- работчик принимает на себя ответственность за качественное выполнение задания, за постоянное уточнение оценок, чтобы выверять график работ, и за взаимодействие со всей своей ко- мандой . Он не должен стесняться просить о помощи, когда она ему необходима .
Программирование в команде подразумевает тесное сотрудниче- ство, где есть старшие и младшие программисты . У команды есть право согласованно решать, кто чем будет заниматься . Технический руководитель может попросить разработчика взяться за задание, но ни в коем случае никого не принуждать .
ЗАКЛЮЧЕНИЕ
Agile — это набор методов, помогающий разработчикам достигать и поддерживать высокий уровень профессионализма . Специ- алисты, которые придерживаются этих методов, принимают и от- вечают разумным ожиданиям руководителей, заинтересованных сторон и клиентов . Agile также наделяет определенными правами как разработчиков, так и клиентов и накладывает на них некоторые обязательства . Взаимное соблюдение прав и принятие ожиданий, признание методов Agile — основа этической нормы для сферы разработки ПО .
Agile не процесс . Agile не модное увлечение . Agile не просто набор правил . Скорее, Agile — это набор прав, ожиданий и методов, ко- торый составляет основу профессиональной этики специалистов, связанных с разработкой программного обеспечения .
3
МЕТОДЫ
ВЗАИМОДЕЙСТВИЯ
С КЛИЕНТАМИ
Планирование
107
Существует куча методов взаимодействия с клиентами, которые разработчику нужно соблюдать, чтобы преуспеть . Среди них пла- нирование, небольшие и частые релизы, приемочное тестирование и «одна команда» .
ПЛАНИРОВАНИЕ
Как провести оценку проекта? Самое простое: его нужно разбить на составные части, а затем провести их оценку . Подход-то хорош, но что делать, если эти части слишком велики, чтобы достоверно их оценить? Тогда нужно просто разбить эти части на меньшие по объему и оценивать уже их . Уверен, вы подумаете, что это по- пахивает рекурсией .
Как далеко можно зайти в такой разбивке? Проект можно делить вплоть до каждой строчки кода . Это как раз то, чем занимаются программисты . Программистом можно назвать того, кто постиг искусство разбиения задач на отдельные строки кода .
Если вы хотите провести наиболее точную и достоверную оценку проекта, разбейте его вплоть до отдельных строк кода . Да, это займет какое-то время, но зато вам станет доподлинно известно, сколько времени займет проект, ведь вы его уже выполнили .
Конечно, это уже никакая не оценка . Оценки построены на до- гадках: нам нужно знать, сколько времени займет выполнение проекта, не выполняя его непосредственно . Хочется, чтобы оцен- ка проекта не стоила дорого . Поэтому оценка по определению не может быть точной . Неточность позволяет нам сократить сроки, необходимые для проведения оценки . Чем ниже степень точности, тем меньше времени понадобится на оценку .
Глава 3. Методы взаимодействия с клиентами
108
Это не означает, что оценка должна быть неточной . Нужно давать как можно более точную оценку, но точную настолько, чтобы это не было непомерно дорого . Вот пример для лучшего понимания .
По моим оценкам, я закончу свой жизненный путь в течение сле- дующей тысячи лет . Это совершенно верно, но точность очень низка . Я буквально не потратил ни минуты на то, чтобы провести настолько достоверную оценку, потому что она совсем неточная .
Такая хоть и достоверная, но неточная оценка обозначает времен- ной отрезок, в течение которого оцениваемое событие произойдет почти наверняка .
Задача разработчиков — потратить как можно меньше времени, чтобы произвести достоверную оценку, и при этом в наибольшей степени сократить временной промежуток .
Трехвариантный анализ
Есть один метод, который неплохо подходит для больших задач .
Это трехвариантный анализ . Такие оценки включают в себя три положения: лучший случай, допустимый случай и худший случай .
С помощью такого анализа можно предречь исход с различной вероятностью . Худший случай — это когда мы уверены в сроках на
95 % . Допустимый — на 50 %, а лучший — на 5 % .
Например, я могу быть на 95 % уверен, что задание будет выпол- нено в течение трех недель . Только на 50 % я могу быть уверен, что оно будет выполнено за две недели . И 5 % вероятности, что полу- чится уложиться в одну неделю .
Можно представить вероятность и иначе . Представим, что у нас
100 схожих заданий . Пять из них будут выполнены в течение неде- ли, 50 — в течение двух недель, а 95 из них — в течение трех недель .
Планирование
109
Существует целый математический метод, связанный с управлени- ем трехвариантными оценками . Кому интересно, могу предложить изучить технику оценки и анализа программ и проектов (PERT)
1
Это мощный метод управления крупными проектами и портфеля- ми проектов . Если вы отдельно не изучали эту технику, не стоит думать, что прочитав о ней, вы уже все знаете . PERT выходит далеко за рамки графиков, которые вы видели в Microsoft Project .
Несмотря на то что трехвариантный анализ хорошо подходит для долгосрочной оценки всего проекта, он слишком неточен для по- вседневного управления, которое необходимо в течение проекта .
Для этого у нас есть другой подход — единицы сложности историй .
Истории и единицы сложности
Метод единиц сложности историй позволяет соблюсти достовер- ность и точность благодаря коротким циклам обратной связи, с по- мощью которых можно многократно выверить оценку в сравнении с действительностью . Сначала точность невысока, но через несколь- ко циклов она повышается до приемлемого уровня . Но прежде чем мы углубимся в метод, поговорим немного о самих историях .
Пользовательская история — это сокращенное описание функции программы с точки зрения пользователя . Например:
Когда я веду машину, то нажимаю сильнее на педаль газа, чтобы
поехать быстрее.
Это один из наиболее распространенных видов пользовательских историй . Некоторым людям нравится так . Другие предпочитают
1
https://ru.wikipedia.org/wiki/PERT.
Глава 3. Методы взаимодействия с клиентами
110
ее в более коротком виде: «ускориться» . Оба вида достаточно хо- роши . Обе истории представляют собой упрощенную версию того, что описывается большим количеством слов . Многое из того, что описано в истории, еще не произошло . Это произойдет ближе к мо- менту разработки функции программы . А вот само действие начи- нается тогда, когда историю уже пишут . В то время разработчики и заинтересованные стороны обсуждают некоторые возможные подробности истории и затем записывают все в упрощенном виде .
Еще рано точно говорить о подробностях, поэтому подробности опущены, а описание упрощено . Мы стараемся отложить уточне- ние подробностей как можно на более долгий срок, до тех пор пока не начнется разработка по этой истории . Поэтому оставим историю в сокращенном виде как предпосылку для дальнейших действий
1
Как правило, мы записываем истории на каталожных карточках .
Понимаю-понимаю . С чего бы мы использовали такую примитив- ную древность, когда в современном мире у нас есть компьютеры, планшеты и прочее, спросите вы? Но выходит, что возможность держать карточки у себя в руках, передавать их друг другу через стол, писать на них и делать с ними многое другое представляется чрезвычайно важной .
Иногда автоматизированные средства могут их заменить, я рас- скажу о них в другой главе . Но сейчас будем считать, что истории написаны на карточках .
Вспомните, что во Вторую мировую войну боевые действия пла- нировались
2
с помощью карточек, поэтому я считаю этот метод проверенным .
1
Это одно из определений истории, данное Роном Джеффрисом .
2
Ну, в какой-то степени, все равно .
Планирование
111
Истории для банкоматов
Давайте представим, что мы находимся на нулевой итерации и наша команда пишет истории для банкомата . Что представляют собой эти истории? Первые три довольно легко вычислить: выдача наличных, внесение наличных и перевод . Конечно, нужно научить банкомат идентифицировать пользователя . Можно назвать эту историю «вход» . А раз есть вход, значит, вероятно, должен быть и выход .
Теперь представим, что у нас есть пять карточек . Их будет почти наверняка больше, как только мы начнем по-настоящему углу- бляться в работу банкомата . Мы можем представить, что есть такие задачи, как аудит, платеж по кредиту и много всего прочего . Но давайте пока что остановимся на пяти карточках .
Что у нас на них? То, о чем мы недавно упоминали — вход, выход, выдача наличных, внесение наличных и перевод . Конечно, это не все слова, которые мы перечислили во время нашего исследования .
Во время встречи мы обговорили много подробностей . Мы обсуж- дали, как пользователь осуществляет вход посредством того, что вставляет карту в приемник и вводит пин-код . Мы обсуждали, что собой представляет внесение наличных, как их вставляют в купю- роприемник и как он пересчитывает эти средства . Мы обсуждали, как выдаются наличные средства и что делать в случае, если купю- ры застряли или просто закончились . Мы прорабатывали многие из этих подробностей .
Пока что все эти подробности неточны, поэтому мы их и не запи- сываем . Мы записываем только слова . Нет ничего плохого в том, что вы сделаете несколько пометок на карточке, если вам нужны напоминания по каким-то вопросам, но это необязательно . На карточки не накладывается формальных ограничений .
Глава 3. Методы взаимодействия с клиентами
112
Отказ от подробностей возможен благодаря дисциплине . И это непросто . Каждый член команды посчитает нужным так или иначе обсудить все подробности, ничего не упустив . Сдерживайте эти порывы!
Как-то раз я работал с менеджером проекта, который настаивал на том, что нужно записывать на карточке подробности абсолютно каждой истории . Карточки с историями были разбиты на единицы сложности, а сами единицы сложности были написаны мельчай- шим шрифтом . Их было невозможно прочесть, и они стали не- пригодными . На них было столько нюансов, что оценить задания просто не оставалось шансов . Составить график работ по ним не получалось . Пользы от них не было никакой .
Хуже того, в каждую карточку с историей была вложена уйма уси- лий, поэтому от них нельзя было просто избавиться .
Именно временная нехватка подробностей делает историю осуще- ствимой, планируемой и оцениваемой . Истории должны создавать- ся с небольшими затратами, потому что многие из них придется изменить, разделить, объединить или даже забыть . Просто не за- бывайте о том, что они являются заменителями, а не требованиями .
Теперь у нас есть кипа карточек, созданных во время нулевой ите- рации . Остальные создадут позже, по мере возникновения новых идей и функций . На самом деле создание историй никогда не пре- кращается . Истории постоянно пишут, изменяют, отбрасывают и, что самое главное, развивают в ходе проекта .
Оценка историй
Представьте, что эти карточки лежат на столе напротив вас, а во- круг стола сидят остальные разработчики, тестировщики и заинте- ресованные стороны . Все вы встретились для того, чтобы оценить