Первое – «сложности». Всякое, что вызывает сложности, помехи и мешает продвигаться к цели следует изучить и исключить после летучки. Аджайл использует «теорию ограничений», описанную Эли Голдратт, в которой менеджер должен убирать любые препятствия на пути команды. Менеджер обязан сделать TO-DO список задач после каждой летучки.

Второе – «отклонение от плана». Если вы запланировали на задачу 2 дня, а уже пошёл 4-ый день и конца не видно, стоит начать разбираться. Если летучка сегодня короткая, то можно не отходя от кассы сразу попытаться понять – почему? Задайте вопрос – какие сложности? Но лучшей альтернативой будет обсудить сразу после летучки. Нужно понять: это плохая оценка, или злобная проблема, или знак свыше, что нужна помощь и стоит подключить ещё кого-нибудь? Одиночный случай – не проблема, он изолирован. Искусство мастера увидеть динамику, повторяемость проблемы служит знаком поиска глубинной проблемы. Так же, если вся запланированная итерация чудным образом завершилась за один день. Попробуйте поменять цели итерации, и может быть включите тестирование, приемочные тесты и сориентироваться на сдачу проекта на месяц ранее.

Третье – «эмоции». Замечайте, что было сказано и не было. Был ли кто-нибудь рассержен или расстроен. Была ли напряжённость, которую было бы неплохо понять. А может быть кто-то был ниже воды и ниже травы? Все это подсказки, чтобы перемолвиться словом после летучки. Это также затруднения для прогресса, как и любые явные вещи (см. пункт 1). Иногда даже не нужно ничего решать, главное выслушать, а решение и само может прийти (а это иногда позволит удальцам писать больше кода… багуга!)

Четвертое – «вопросы». Возможно, вы полностью не въехали в вопросы и проблемы во время летучки. Если уточняющие вопросы внесли больше сумятицы, чем прояснения – верный способ поговорить после летучки (раньше когда я был разработчиком, у меня быстро получалось въезжать во все эти технические проблемы, сейчас же я стал программ менеджером и мне нужно разжёвывать по полочкам; к тому же я получил PMP сертификат и могу показать – что для меня теперь нужно все разжёвывать м-е-д-л-е-н-о). Мы не можем исправить то, что не понимаем. Много вещей в разработке произрастают из технических неувязок, но когда эскалация и устранения требуется (и это моя работа) я должен быть в курсе дела, чтобы найти лучшее решение.

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

На сегодня это 5 самых самых, завтра они могут быть другие :)

Оригинал: LeadingAnswers
Перевод: agileguru.ru

Автор: Marcin Niebudek
Перевод: agileguru.ru

Контракт с фиксированной ценой (fixed price contract) является злом - это то, что часто можно услышать от программистов. Но нужно согласиться, что эти контракты являются реальностью, с которой встречаются все команды. А давайте вместо того, чтобы бороться с таким контрактом, будем его использовать (прим. перев.: глупо отрицать такие проекты, ведь клиент хочет получить результат и готов щедро платить за такие условия – а долг аджайлиста подстроить свой процесс, чтобы достигнуть результат). Как компания может выполнить такой договор? Можем ли мы использовать гибкий подход разработки для достижения лучших результатов с меньшими рисками? В этой статье мы постараемся ответить на эти вопросы.

Итак, давайте начнем с самого договора.

Фиксированная цена (fixed price), время (fixed time) и объём (fixed scope)

Фиксированная цена контракта означает заморозить все три магических фактора: деньги, время и объём работы. Являются ли цены и время сложностью  для Agile команды? Не должны. В самом деле, ограничить объем – действующая практика Agile (time boxing, прим.перев.: в Agile ограничение объёма происходит после подсчёта суммарного времени выполнения всех задач, которые запланированы в итерацию и отсекания всех, на которые у нас нет ресурса; а это означает мы ограничили объём, но ограничения происходят исходя из доступного времени/ресурса команды).

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

Почему клиенты настолько уверены в фиксировании объема (fixing the scope)? Мы понимаем, что они хотят знать, сколько они будут платить (кто не хочет знать этого) и когда они получат результат. Исходя из этого они могут строить свои планы, например планы продаж и получать прибыль. Единственное, чего они не знают, что именно они хотят получить (даже если они настаивают, что они знают).

Проблема фиксирования объема работы (scope) уходит корнями в следующее:

* Отсутствие доверия между сторонами
* Отсутствие понимания принципов разработки ПО
* Слабое понимание понятия «объём работы» (scope)

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

Ключевыми неверными предположениями относительно фиксирования объема (fix scope)  являются:

* Подробные требования определяются позднее
* Хорошо определенный документ мешает внесению изменений в требования
* Фиксированный объем (fixing scope) требует лучших оценок трудозатрат

Переход от фиксированного объёма к фиксированному бюджету

Теперь, когда мы понимаем, что основной конфликт между применением гибкого подхода и фиксированной ценой (fix price) контракта заключается в фиксированном объёме (fixed scope), мы можем сосредоточиться на преобразовании фиксированной объёма (fixed scope) в фиксированный бюджет (fixed budget).

Это означает, что вместо предоставления детальной спецификации требований, нам надо сосредоточиться на поиске максимального количество пользовательских историй (User Stories). Нам необходимо построить первоначальный список требований (backlog), который мы попытаемся оценить с помощью методики Story Points.

Прим.перев.: Story Points или просто оценка с помощью баллов (points) - метод приблизительных оценок «размера рубашки», где вместо размеров Small, Middle, Large используется более детализированный ряд: 0, ½ , 1, 2, 3, 5, 8, 13, 20, 40, 100; которому так же можно сделать соответствия с размерами рубах:

• Small: 0, ½ , 1, 2, 3
• Middle - 5, 8, 13
• Large – 20 (желательно задуматься над декомпозицией)
• Extra Large – 100 (в природе не бывает и требует декомпозиции).

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

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

Оценка истории в баллах (story points) - труднее объяснить клиенту в начале проекта, так как не является распространенным способом выражения трудозатрат и усилий. Но зато снижает опасность недооценки масштаба. Как это происходит? Баллы (story points)  по своей природе являются относительными к другим историям, в то время как традиционные оценки (как правило, делается в человеко-часах) анализируют каждую функцию в отдельности.

Критерий DONE (done = сделано) - это еще один способ укрепления доверия и общего понимания процесса. Когда клиент видит впервые истории пользователей (user story) он легко понимает их; но не всегда очевидно, сколько потребуется усилий для их реализации. Команды, которые обсуждают критерий DONE для историй с клиентом, лучше знают, что является ожиданиями клиента. А так же смогут сделать лучшую оценку проекта. Кроме того, на стороне клиента, практика "критерий DONE" создает некие критерии приемки продукта.

Например, определение DONE для истории (user story) может выглядить так:

* Протестирован под IE 7 / 8, Firefox 3.x и Chrome
* Добавлен соответствующий раздел в "Руководстве пользователя"

Позднее команда добавит больше требований в терминах DONE. Но на этапе планирования эти три практики помогают создать договор и хорошо понять объем продукта (defining scope).

Определяя критерий DONE, мы постепенно разрабатываем контакт с использованием оценки в бюджетных баллах (budget points – прим. перев:  объем в функционале конвертируются в объём в баллах). А это как раз то, что мы можем зафиксировать в контракте. Не фиксировать требования, а определить объём работы в баллах. И это открывает новые возможности для перемен!

Хотя у нас есть возможности фиксировать бюджет (в терминах оценки - points), но мы по-прежнему готовы менять требования во время разработки. У нас есть инструменты (user story и story points), которые используем для сравнения одних требований с другими и можем изменять первоначальные требования. Главное не выйти за границы бюджета в баллах (budget points). Это позволяет нам изменять требования не изменяя объем. Получается, мы зафиксировали объем (scope) в  баллах (budget points), а не зафиксировали объём в функционале. Если мы можем оставаться в рамках этих ограничений (scope в терминах story points), мы также можем оставаться в пределах фиксированной цены (fixed price) и времени (fixed time).

Первоначальная оценка

Самое сложное в подготовке контракта с фиксированной стоимостью состоит в определении цены и плана, которые будут устанавливаться на основе четко определенного объёма (scope). Давайте посмотрим, как команды способствуют разработке такого контракта с использованием Agile.

1. Обучить. Нужно встретиться с клиентом и описать, как вы будете работать. Надо сказать, что такое истории пользователей, как работает оценка в баллах и что такое критерий DONE. Лучше это сделать при подготовке первоначального предложения (request for proposal, RFP).

2. Сбор требований. Следующим шагом будет сбор историй пользователей. Это делается в течение ограниченных во времени сессий, растянутых не более чем в 1-2 дня. Этого достаточно, чтобы найти большинство из ключевых требований для формирования видения продукта (product vision) без мелких деталей реализации. Затем следует обсудить критерий DONE для каждой истории, раскидать по релизам и итерациям.

Нам необходимо знать:

* Условия, в которых требования должны быть проверены (таких как количество браузеров, мобильных платформ или операционных систем)
* Какие документы необходимы клиенту
* Как реализованные истории будут устанавливается
* Что делать клиенту во время разработки (рассказать про демо-сессии)
* Как часто мы встречаемся и кто участвует во встречах (планирование, демо, согласование деталей)
* И т. д.

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

Обсудив с клиентом все собранные истории и критерии ‘done’, теперь мы можем начать оценку. Это хорошо известная практика в Agile. Наиболее важным является привлечение как можно большего количества будущих членов команды. Эта оценка делается коллективно. Методы командного планирования, такие как покер (planning poker), как известно, снижают риск недооценки требования (user story) за счёт объединения усилий как опытных разработчиков, так и менее опытных. И самое важное – оценка производится людьми, которые будут реализовывать систему.

Шкала Фибоначчи (1, 2, 3, 5, 8, 13, 20, 40, 100) очень удобна для оценки истории (user story) в баллах (points). Относительная оценка начинается с поиска наименьшей истории и принятия коллективного решения, что она будет 1 или 2 балла в качестве базового уровня для дальнейшей оценки.

На самом деле во время первоначальной оценки часто бывает трудно оценить историй с использованием наименьших значений, например 1 или 2. Чем больше оценка – тем меньше мы понимаем историю. Именно поэтому оценки в баллах легче на ранней стадии, потому что гораздо проще сказать, что история А в пунктах (story points) является  в 2 раза сложнее, чем история Б, нежели сказать, что история требует 25 человеко-часов, а история  B потребует 54 часа.

Это хорошо работает, даже если мы выбираем 3 или 5 бальные истории в качестве базового уровня, и если мы это сделаем, то будет легче разбить их на более мелкие истории позднее, во время фазы разработки. Остерегайтесь же истории 20, 40 или 100 баллов. Такая оценка предполагает, что мы ничего не знаем о том, что должно быть реализовано. Сразу же обсудите их с клиентом и разбейте, а не радостно включайте в договор.

Результатом оценки будет суммарное количество баллов (story points), описывающие начальные возможности продукта. Это число, которое должно быть установлено с точки зрения объема (scope и fixed budget) по контракту, а не список конкретных требований в виде историй (user story).

Как заработать доверие

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

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

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

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

Резюме

Контракт с фиксированной ценой (fix price contract) часто считается очень вредными, и многие аджайлисты говорят, что мы должны просто избегать их. Но нельзя избегать таких контрактов всё время, и нужно найти способы заставить их работать .

На самом деле, некоторые аспекты таких контрактов подходят для Agile-команды, поскольку мы привыкли работать в ограниченных временных промежутках (time-frame), а это именно то, что называется фиксированные сроки в договоре (а также фиксированной ценой). Единственное, что действительно беспокоит нас - это то, как устанавливается эта цена.

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

(продолжение перевода в течение недели)

Умопомрачительная презентация о качестве кода с шикарными примерами.

boolean is_admin;
// something
Boolean b = new Boolean( is_admin );
if( b.toString().length() == 4 ) {
   // something...
}
// something

Смотреть презентацию: ссылка (позднее обещали видео)

Дополнительные сайты:

• http://govnokod.ru/

За последнее время в капиталистическом зарубежье стали задуматься на тему качественного кода. Конечно эта тема там буксует с 1999 года, но постепенно затухает в виду сложности для понимания менеджерскому составу. А о пост-советском пространстве и говорить не приходится. Менеджеры конечно же ищут пути повышения эффективности сначала в процессе, потом в человеческом факторе. Некоторым не хватает подготовки первое осилить, а до второго руки не доходят. Деадлайны и сроки горят. Тут не развиваться нужно - а поставку делать. Но ни то, ни другое не ведёт что-то к счастью. Потому как сердце проблемы не в процессе или людях, это уже с лихвой решается любой современной теоретической методологией. Проблема в коде.

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

Поэтому нам, разработчикам, нужно помочь менеджерам в нашем общем деле. Просто взяться за ум и поставить перед ними ультиматум! Либо все эти менеджерские buzz-ворды, либо просто хороший код. А мировой опыт маленькими капельками просачивается на нашу родную землю. И образует нескончаемый поток. Остаётся только войти в этот потом и прикаснуться к Истине.

Книга "Чистый код" поможет сделать шаг к настоящему мастерству. Так что дерзайте. Но для того, чтобы уверенно стоять на двух нижних лапах рекомендуется весь список литературы освоить :)

Жена посылает мужа-программиста в магазин:
- Дорогой, купи, пожалуйста, палку колбасы, и если будут яйца, то купи десяток.
Через полчаса программист возвращается с десятью палками колбасы.
Жена:
- Что это?! Зачем ты купил столько колбасы?
Программист:
- Ну так яйца-то были...

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

Чтобы улучшить качество данного алгоритма, мы должны сделать неявное явным: "если будут яйца, то переключись с колбас на яйца и купи 10 штук", или по простому "если будут яйца, купи их 10 штук".

Более детально с этим рефакторингом вы можете разобраться в книге Мартина Фаулера "Рефакторинг" или в скудной версии ознакомиться на сайте http://refactoring.com/catalog/separateQueryFromModifier.html.

В целом использование "подразумеваемой" логики не такая уж и плохая вещь. Это позволяет уменьшить количество передаваемой информации, за счёт уже заранее известной. Или наоборот выработка определенного соглашения порождает некую метаинформацию полезную для восприятия сообщения. Яркий пример - соглашение по наименованию. Использование шаблонов проектирования - более полезный пример. Когда знание о стурктуре решения передаётся косвено. А незнающий человек (например шаблон visitor) долго будет думать, что же автор кода хотел этим сказать. Вернёмся к яйцам. В быту это нормально, когда сработавшаяся команда вырабатывает некоторые устоявшиеся термины, подходы и решения - это создаёт метаинформацию относительно кода. Банальный пример, когда мета-информация влияет на людей, это когда новый человек в команде должен потратить 3-6 месяцев на подключение к проекту. Первые месяца он только изучает, знакомиться с этой мета информацией, чтобы полноценно подключится к проекту. Но это отдельная тема.

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