Продолжаю наполняться знаниями и теориями о процессах организации и управления разработкой и разработчиками.
В март также вошли пара книжиц по Python, но едва ли есть смысл делать обзоры учебников по языкам программирования. Они не то чтобы сильно разнообразные.
Кен Швабер, Джефф Сазерленд — «Софт за 30 дней»
Рекламный слоган Scrum прост: Знать, где ты находишься каждый день, используя Scrum или Думать, что знаешь, где ты находишься, на основе хорошо составленного плана, и потом, но гораздо позднее, обнаружить, что сильно ошибался.
Ещё одна книга про Scrum от его создателей. Обзорная. Было, возможно, нелепо надеяться найти тут что-то новое после всего уже изученного и прочитанного, но полезно время от времени пересматривать основные идеи методологии или технологии, для чего можно либо перечитывать уже прочитанное, либо смотреть, что нового написали основатели.
В частности появляются идеи аргументации и обсуждения вопросов применимости Agile-подходов в разных ситуациях и организациях. Например, тут предлагается вот такой опросник для менеджмента — набор утверждений по категориям, на которые можно ответить «Согласен / частично согласен / затрудняюсь ответить / не согласен»:
Область | Утверждение
Мотивация | Люди особенно продуктивны, когда управляют собственной работой
Мотивация | Люди воспринимают более серьезно обязательства, данные себе, чем полученные от других
Мотивация | У людей появляется больше креативных решений, когда они не загружены работой
Мотивация | Люди всегда стараются сделать все, что могут
Мотивация | При необходимости «работать усерднее», под давлением, все автоматически и существенно снижают качество работы. Особенно это касается программистов
Команды | Команды более продуктивны, чем такое же количество людей, работающих по отдельности
Команды | Продукты более крепкие, когда команда обладает кросс-функциональными навыками, чтобы рассмотреть продукт с разных перспектив, включая поддержку, сохранение, развитие, качество, юзабилити и рыночную привлекательность
Команды | Смена состава команды на время снижает производительность
Производительность | Сотрудники и команды в целом делают работу лучше, когда их не прерывают
Производительность | Команды более эффективны, когда они решают свои проблемы сами, получая при этом опыт
Производительность | Открытое обсуждение лицом к лицу — лучший способ для общения в команде
Дэвид Андерсон — Канбан. Альтернативный путь в Agile
(Heavy sigh. В оригинале: Successful Evolutionary Change for Your Technology Business. Ничего про «альтернативный путь» или Agile).
Канбан — это не методология жизненного цикла разработки ПО и не подход к управлению проектами. Он требует наличия каких-то процессов, чтобы можно было применить Канбан для их постепенного изменения.
В свете чего вопрос «что лучше — Scrum или Канбан?» кажется не совсем логичным. А отечественное название книги только запутывает.
Хотя содержание книги тоже не совсем ясно. Есть kanban — производственная система Toyota, оптимизированная для работы с повторяющимися и предсказуемыми процессами и задачами, есть ТОС — Теория Ограничения Систем Голдратта. И автор книги заявляет о том, что создал Kanban (именно так, отличие от системы Toyota именно в большой букве), который объединяет и дополняет эти две системы.
Объединяет — да. Дополняет — ну я не нашёл. ТОС вообще-то гораздо шире, и в Канбане от неё только выявление «бутылочных горлышек» и прочих ограничений потока. Вдобавок режут глаз периодические нападки автора на Agile. Напоминает маркетинговые презентации, основанные не на описании преимуществ продукта, а на принижении аналогов других вендоров.
Общая идеология близка Agile-методикам:
- концентрация на качестве;
- снижение количества незавершенных задач;
- частые релизы;
- баланс требований и пропускной способности;
- приоритизация;
- борьба с источниками вариативности для улучшения предсказуемости.
Книга в целом полезная, интересная, хотя немного нудновата. По итогам прочтения лучше в голове стала складываться картина, когда уместен Scrum, а когда лучше подумать о канбан-доске (хотя доска — это ещё не канбан, конечно, и даже не какая-то значительная его часть).
Поль Дюваль — «Непрерывная интеграция»
( Paul M. Duvall — Continuous Integration Improving Software Quality and Reducing Risk)
Издательство «Вильямс». Надо запомнить, чтобы впредь всячески избегать книг данного издательства. Чтобы дать понять почему, приведу лишь одну цитату:
все разработчики выполняют закрытое построение на собственных рабочих станциях перед передачей кода в хранилище с контролем версий, для гарантии того, что внесенные изменения не приведут к ошибке при интеграционном построении;
Это ж надо было перевести build как «построение». А private build — сборка на машине разработчика для проведение тестов — как «закрытое построение». Тесты (tests), к слову, переведены исключительно как «проверки».
Продираться через эти заборы «построений» и «проверок», пытаясь в уме проводить реверс-инжиниринг и угадывать, что, например, кроется за выражением «разработка методом проверки» (видимо, test driven development) это добротная интеллектуальная разминка, но совершенно не увлекательная.
Вдобавок книга не содержит ничего нового, не покрытого более содержательной Continuous Delivery (Humble, Farley). В общем, не дочитал.
Если хочется, всё же, узнать, что на самом деле скрывается под термином CI, то полагаю эта книжка будет полезна. Но в оригинале.
Если вкратце, то CI — это прежде всего регулярная (а вовсе даже не непрерываная) обратная связь:
- прежде чем выложить код в централизованные репозиторий, все разработчики делают сборку продукта/компонента и прогоняют базовые тесты на своей машине;
- при этом каждый разработчик пушит код в репозиторий (в активную ветку) как минимум раз в день;
- несколько раз в день на выделенном сервере проводится интеграционная сборка всех компонент и прогоняются все возможные тесты (интеграция, регрессия);
- все 100% тестов должны проходить успешно;
- если всплыли ошибки, то их исправление — самая высокоприоритетная задача для всей команды;
- регулярно анализируется покрытие кода тестами, его качество и соответствие соглашениям о стандартах.
Self Engineering 