отзыв о "Scrum and XP from the tranches"

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

Но вот второе издание дало книге ту глубину, которая и делает её отличной книгой из просто хорошей. 

Во втором издании автор пересматривает изложенное ранее с точки зрения опыта, который он приобрел за 5 лет после первого издания. При чем это сделано не в стиле молчаливого редактирования с исчезающими старыми и появляющимися новыми абзацами, а в стиле диалога с читателем. Т.е. автор не просто меняет контент, а дополняет и корректирует его прямо указывая "вот это ошибка", "а вот здесь вот можно сделать лучше следующим способом". Именно эта манера пересмотра и анализа старого материала выгодно выделяет эту книгу среди остальных книг посвященных Scrum.

Т.е. вместо фразы "надо делать так", читатель получает "надо делать так, потому что", "а ещё можно вот так" и "в целом так вроде бы и надо по стандарту, но не рекомендую, потому что"

Стоит так же отметить, что данная книга сосредоточена на тех вещах, которые изначально закладывались в него Джефом Сазерлендом, а не на вещах которые привносились в него евангелистами от IT. Т.е. книга фокусируется не на процессах Скрама, которые делают его инженерным фреймворком, а на процессах, которые делают его организационным фреймворком. Т.е. на процессах планирования и ретроспективы, сбора требования и наличия готового продукта, а также на коммуникации. А ведь именно эти процессы и позволяют использовать Scrum как в организациях(скрам скрамов), так и личной жизни(вот пример с адаптацией Скрама для управления временем http://s-kalinin.blogspot.com/2015/10/scrum.html)

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

В целом книга является must-read для тех кто думает о внедрении, внедряет или уже внедрил Scrum на проекте или в компании как опорная книга и пинок для ретроспективы накопленого опыта.

P.S.

А к TDD после накопления опыта автор рекомендует относиться осторожно - ибо не серебрянная пуля.

P.P.S.

Электронная версия доступна бесплатно www.infoq.com/minibooks/scrum-xp-from-the-trenches-2. На русский переведена только старая редакция :(

книга API design for C++

Прочитал в августе API design for C++ by Martin Reddy, книгу которая оставила после себя странное впечатление. Осмысление этого впечатления заставило отложить написание отзыва на 2 месяца.

У книги есть как явные плюсы: например то, что автор опирается на свой опыт работы в различных проекта, так и явные минусы: например то, что книга была написана перед выходом стандарта C++11, слабо учитывает новые решения, которые появились с этим стандартом и судя по всему не получит новой редакции, которая адаптирует её к новым стандартам C++11 и C++14.

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

Глава 1 является чисто вводной и объясняет что такое API, какая специфика его в C++, чем мы платим и за что. Содержит довольно большое количество "воды", но основные моменты выписано чётко, что очень радует.

Глава 2: Качества. Тут автор описывает качества хорошего API почти не останавливаясь на специфике для C++. Встречал я и более краткие и более смысло-плотные раскрытия этой темы, а потому эта глава выглядит больше как дань научной степени полученной автором в своё время. По крайней мере, шаблон подачи материала классический для диссертационной работы и "воды" опять же много...

Глава 3: Паттерны проектирования. А вот эта глава от воды по сути избавлена. Разбираются только шаблоны, которые активно используются в API, и рассматриваются только специфика их C++ применения. Т.е. pimpl, singleton, factory, proxy, и т.п. При этом каждый паттерн разбирается со всех сторон - что получаем, чем платим, возможные варианты применения и альтернативные решения. Для меня эта глава стала основной ценностью этой книги.

Глава 4: Архитектура. Мартин Редди пересказывает принципы проектирования архитектуры программных систем. При чём эти принципы не являются специфичными для C++ или для API design. Странная глава, которая так и не позволила понять зачем она в этой книге... 

Глава 5: Стили. Короткая глава, которая вводит класификацию API и предлагает некоторые неочевидные варианты. По хорошему должна быть в первой тройке глав.

Глава 6: Использование C++ и Глава 7: Производительность. Комбинация style guide'ов и знаний, которыми человек, который взялся за проектирование C++ API уже должен обладать. Главы ни о чем и полезны разве что списком утилит, которые можно использовать для анализа производительности.

Глава 8: Версионирование. А вот эта вот глава довольна неплохая, хотя и содержит сколько-то воды. Раскрывает подходы к построению версий, выделению веток и рассматривает процесс разработки API в течении длительного периода времени, т.е. не только на этапе новой разработки, но и на этапе maintenance. В целом она является одной из опорных глав этой книги.

Глава 9: Документация. Смысл в главе есть, но зачем так много примеров и воды?!

Глава 10: Тестирование. Довольно неплохая глава, которая даёт представление об основных фреймворках, подходах в тестировании API, ограничениях налагаемых языком и методами их обхода. Заодно объясняет зачем это делать надо и даёт обзор связанных областей(coverage, continuous build, bug tracking etc)

Глава 11: Скриптование. Интересная глава, которая внятно объясняет зачем нам поддержка других языков в C++ API, чем мы за это платим, как это получить в C++ различными методами и какие преграды есть на этом пути и способы их обхода.

Глава 12: Расширяемость. Термин этот довольно расплывчатый, и к нему относят многое: расширяемость через внешние модули, расширяемость через архитектуру и т.д. Должен признать, что Мартин Редди не сосредотачивается на каком-то одном толковании, а разбирает большинство возможных толкований, при чем рассматривает их с разных сторон и очень качественно.

Если свести все впечатления воедино, то:

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

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

Целиком эту книгу я бы не рекомендовал никому, разве что избранные главы...

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

Прохожу сейчас в неторопливом ритме курс "Организационный анализ" на coursera.
Постоянно замечаю пересечения между материалом курса и различными теориями командного взаимодействия.

Из последного сильно зацепившего:
*  описание Руссо охоты на оленя описывает те же причины, решения и следствия, которые подымают у себя в курсах команда Стратоплана при помощи мамонта. И эти же причины совпадают с теми, которые приводят к возникновению коалиций при анализе организации с помощью модели торговли/бюрокраии.
* Ппричины кризиса коалиции после достижения цели один в один совпадают с причинами реформинга в модели Такмана.

Интересно, что будет дальше... :)

О частоте релизов

После прочтения continuous integration, delivery и иже с ними выкристаллизировалось:

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

Хотя выстроить процедуру частых релизов - это все ещё искусство... ;)

Stroustrup и 16 способов положить кота в стек

Прочитал статью Страуструпа о стеках и кошках: 

http://isocpp.org/blog/2014/03/sixteen-ways

Казалось бы, написана она ещё в 1990 - что нового можно в ней почерпнуть?.. 

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

Но, при внимательном прочтении, начинаешь замечать мелочи, которые играют важную роль. Для меня такой мелочью стал внутренний класс stack_id: 

class stack
{
public:
    class id
    {
        friend stack;
    private:
        int i;
    };
    ...
}; 

Казалось бы мелочь, а ведь сколько проблем доставляли мне в свое время типы идентификаторов, определённые через typedef базовых типов... 

А тут:

• раз, и логическая привязка к основному классу;  
• два, и неприводимость к базовому типу(int/string/etc); 
• три, и неизменяемость его наружными классами, а только передача между различными функциями.  

Красиво же!  

Пара мыслей о Канбане

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

Забавно, что поход с пареньком Херби из "Цели" Голдрата можно рассматривать как пример Канбана, потому что остальные дети вытягивали только то, что он проходил. А вот ситуация со станком "Херби" уже не может быть рассмотрена как подобный пример, потому что ресурсы не вытягивались к станку по мере необходимости, а выталкивались на основании прогнозов о том, когда они ему понадобятся. Но "цель" и "дао тойота" пересекаются очень интересно...

P.S. Не используйте канбан у себя на кухне, иначе тарелки будут грязные всегда, а отскребать засохшую грязь тяжело. Иногда выталкивание лучше вытягивания... :)

Adrenaline Junkies and Template Zombies - отзыв

Если кратко, то эта книга описывает различные шаблонные состояния внутри команды, либо внутри проекта, когда идёт взаимодействия команд, либо даже внутри компании, которая выполняет этот проект.
По мере прочтения узнавал кучу ситуаций, с которыми уже сталкивался в процессе работы. И книга с точки зрения описания ситуаций очень хороша. Но вместе с тем у неё есть 2 недосказаности, которые вместе не дают внести её для себя в список "рекомендовано к прочтению".
Первая недосказаность - это отсутствие "способов лечения" ситуаций. Но учитывая, что все команды разные, то расписывание всех вариантов лечения в каждом случае, увеличило бы размер книги в лучшем случае в 3 раза. Так что это скорее не недостаток, а мелкая придирка с моей стороны.
Вторая недосказаность - это отсутствие описания последствий: "А что будет, если мы не будем это лечить?" Ведь не у всех же такой опыт как у членов "The Atlantic Systems Guild", и вполне возможно что при анализе последствий будет что-то упущено. Или же с точки зрения выгоды для себя и для людей, условному мне будет выгодно засушить ситуацию, чтобы она пришла к ожидаемому условно негативному варианту... И вот отсутствие этого анализа даёт послевкусие неокончености книги. Как, если бы из дипломного проекта на защите было доступно только введение.
Честно говоря, было странно читать такую "незаконченную" книгу от авторов Deadline и Peopleware. Итого - хорошая, но необязательная к чтению книга.

Упрощенное GTD

Каждый в процессе работы вырабатывает некоторые практики, которые упрощают отслеживание и выполнение различных задач.

Делюсь своей наработкой для отслеживания задач.
У неё есть определённая специфика - ориентирована только на рабочие задачи. Я не хотел видеть в списке рабочих задач личную жизнь(мухи отдельно, котлеты отдельно).

IT-People Pecha-Kucha: первые впечатления

Впечатления от IT-People Pecha-Kucha, прошедшем 1-го декабря.
Disclaimer: это не анализ, это впечатления по быстрому... ;)  

Для чисто технического спеца, который не планирует растить в себе softskills и заниматься хоть каким-то управлением людьми, это мероприятие было бы почти бесполезной тратой времени, потому что было больше ориентировано на работу с людьми. Всё таки не даром в названии торчит "People" :)

Собственно сами впечатления:
Выступление Дмитрия Миндра. Само по себе выступление было неплохим для вводного, но выбор темы был просто непонятен - в кафе и так собрались люди, которые не "сидят на попе ровно" (с)Панкратов. Так что идея о необходимости убеждать пришедших, что стоит вкладываться в самообразование, networking и делать работу качественно, - вызывает сомнения.
«Роль менеджера в гибкой разработке» - внятные впечатления просто не формулируются... Аджайл всегда такой аджайл...
Тим Евграшин и Сергей Бережной - просто качественные презентации. Правда понимание того, что стоит за этим "просто" и "качественно" заставляет снять шляпу перед авторами - хоть сейчас утаскивай это "просто и качественно" как опорный конспект для действий.
Презентация BABOK - прикольный анонс киевской группы BA, сделано весело и так чтобы привлечь внимание, но это пока не в области моих интересов.
Был человек, которому микрофон мешал выступать :) Очень зажигательно, очень быстро - впечатление как от китайской пиротехники: Вспышки, взрывы...Трах-бах! Бздыщ!! Но в конце вопрос: "что ЭТО было??!!" Может поэтому и не запомнил как его зовут?
"Просто и качественно" можно сказать и о Квантоновом скачке Панкратова, но от него ожидал подспудно большего.
Вика Придатко с "Техническим интервью с человеческим лицом" и выступление Орлова - лучшие для меня презентации на этой PechKucha и новый пункт в моё must view для TL или ПМ.

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

Update:
Андрей Анпилогов начал выкладывать записи с мероприятия на youtube

Update2:
Теперь понятно, почему в панкратовской чувствовалось возможность улучшения. Оказывается на ExpertLabs у него был более полный доклад - смотреть здесь.

TDD в условиях плотного использования ATL/COM

Попытки внедрить TDD для проектов, которые активно используют ATL/COM, очень часто заканчивались для меня неудачно из-за сложности задачи, которая приводит к тому, что просто опускались руки из-за того что не знал как подступится к задаче и гугл с яндексом в те моменты молчали и не желали делится мудростью других людей.

И проблема была даже не в том "как протестировать сам COM-компонент?" - это не представляло особой проблемы, потому что был и есть явно заданный интерфейс класса, единственной особенностью которого является то, как создаётся объект этого класса. Дальше всё сводилось к классическому подходу для TDD.
Основной проблемой являлся вопрос "как протестировать класс, который уже активно использует COM-компоненты?"

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

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

Подсказкой к решению является скрытая причина этой ситуации - у нас уже по всему коду протянута неявная зависимость от реестра системы. Соответственно для удобства в написании тестов я должен обеспечить единую точку доступа и контроля этой зависимости. Что привело меня к следующей идее: введём дополнительный архитектурный слой с единичным контейнером, который контролирует процесс создания COM-компонентов (по аналогии с слоем работы с объектами базы данных).

Единый контейнер прийдёт к нам со всеми своими достоинствами и недостатками:

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

Архитектурная идея с подобными контейнерами не сильно распространена в C++, но она решает свою задачу.

P.S.
Я таки дописал хоть один пост за прошедший год.