Я закончил читать Agile! на прошлой неделе, и я подумал, что написание об этом заставит меня заняться книгой на более глубоком уровне, так что поехали ...

Цитаты, которые запомнились мне

если архитектура достойная, вы можете ее улучшить, но рефакторинговый мусор остается мусором

Если что-то заставляет кровь Бертрана Мейера закипеть, так это «Враг - все, что нужно заранее», которое является противоядием Agile от больших предварительных требований. Он выступает против этой точки зрения, особенно в отношении проектирования архитектуры программного продукта. Я думаю, что в начале Agile маятник слишком сильно качнулся с точки зрения предварительных требований. Я думаю, что демонизация больших письменных требований принесла индустрии много пользы, но я также могу понять, что инженеры могут потерять рассудок, если им предложат спроектировать новую архитектуру на ходу. Он действительно попадает в точку с этой цитатой чуть позже ...

Хорошая идея - не делать слишком много с самого начала.

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

Мне действительно не нравится представление о том, что отзывы клиентов - это истина в последней инстанции при разработке программного обеспечения. О клиентоориентированности я писал здесь. Спасибо Бертрану за еще одну пачку патронов.

Обратной стороной стратегии «построить простейшее, что может сработать» является то, что она предпочитает собирать на каждом этапе низко висящие плоды.

Я посетил Scrum-Workshop, где консультант сказал аудитории, что разработчики «теперь разбивают истории на однодневные задачи, чтобы каждый разработчик мог иметь ежедневное задание для спринта». Я спросил, могут ли быть задачи, которые нельзя разделить на однодневную задачу, или задачи, в которых это не стоит того. На самом деле он не ответил, но я думаю, что простое правило разбивать задачи на мелкие части в Agile переоценивается. Некоторые вещи сложны и требуют времени, и ценность их разбиения на мелкие кусочки не имеет большого значения. При этом, конечно, должна быть цель сломать вещи, но не только ради этого. Я думаю, что страх сорвать только низко висящие плоды также подпитывается необходимостью разбивать задачи.

Это часть уважения к программистам - признать, что люди разные, и не навязывать им единую схему.

В этой цитате Бертран Мейер говорит о дизайне «открытого пространства» на сегодняшних рабочих местах. Я думаю, что это выходит даже за рамки этого. Agile-методы и особенно Scrum говорят вам, что каждый программист может выполнять одну и ту же задачу в одно и то же время, или, по крайней мере, это подразумевает это. Есть задачи, которые лучше подходят для начинающих / пожилых людей, или задачи, которые являются хорошим / плохим первым шагом в новой области для разработчика. Представление о том, что все одинаковы, упрощает работу команды разработчиков программного обеспечения. Решение, какие задачи решает разработчик, является фундаментальной частью развития члена команды и должно играть большую роль в процессе разработки.

Части, с которыми я не согласен

Вот некоторые моменты, с которыми я не согласен с автором.

Хорошие - короткие ежедневные встречи

На мой взгляд, Stand-Ups действительно переоценивают. На бумаге они звучат потрясающе: мы встречаемся каждый день на несколько минут, и все в курсе. На самом деле обратная сторона подобных встреч обычно игнорируется. Мне очень нравится позиция Джейсона Фрида на ежедневных встречах, которую вы можете прочитать здесь. В нашей отрасли ценность сейчас действительно недооценивается, но это уже другой блог. Требования к стендапам, чтобы действительно повысить ценность, настолько высоки, что я думаю, что они редко того стоят. Это может сработать для вашей команды, и если это действительно поможет, но, по моему опыту, большинство команд делают это только потому, что им хорошо, а не потому, что они повышают ценность работы команды.

The Brilliant - правило закрытого окна

Бертран Мейер называет правило закрытого окна, которое запрещает изменение области действия во время итерации с ограниченным временем, «одной из самых проницательных и эффективных Agile-идей». Я думаю, что изменение объема и задач всегда должно быть возможным, но к этому следует относиться очень серьезно. Если новая задача важнее (по какой-либо причине), чем текущая, ее следует выполнять. Тот, кто делает ставку, должен обладать доверием и знаниями, чтобы менять планы каждый раз, когда это необходимо. Принятие решения о том, что делать, требует большой ответственности, и я думаю, что на самом деле это не изменится, если вы в начале итерации или во время нее. Существует множество причин, по которым изменение объема может быть плохим, но, на мой взгляд, активная итерация не является одной из них.

Мое представление изменилось

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

Раздутое - парное программирование

Я никогда не был большим поклонником парного программирования из учебников. Я не разработчик, поэтому все, что я пишу здесь, является моей точкой зрения как PM. Бертран Мейер называет парное программирование «необоснованно разрекламированным» и на самом деле отвергает этот метод, который больше используется, чем «дополнение к сумке трюков команды». Он действительно ломает все плохие стороны такой тесной связи членов команды. До прочтения книги мне не очень нравилось парное программирование, теперь я считаю, что это плохая практика для команд разработчиков. Команды должны сотрудничать, им нужен наставник, но им не нужно сидеть за одним столом в течение 8 часов. Требования к созданию ценности парного программирования настолько высоки, что только некоторые пары инженеров могут его использовать.

Плохое - разработка через тестирование

Бертран пишет: «Программный процесс, определяемый как повторное выполнение основных шагов TDD […], не может восприниматься всерьез». Я никогда не разрабатывал программное обеспечение методом TTD, но я всегда очень высоко оценивал этот подход. Бертран Мейер действительно хорошо справляется с выявлением слабых мест рабочего процесса «хорошо, чтобы быть правдой». Прочитав ту часть книги, я подумал о том, сколько разработчиков / команд, которые действительно занимаются TDD, я знаю - их нет… Важно не путать позицию против TDD с противостоянием самому тестированию. Тестирование стало такой частью разработки программного обеспечения, что оно имеет почти такую ​​же ценность, как и сам код. Критика направлена ​​на TDD, а не на тестирование.

Книга

Я действительно думаю, что это книга по Agile для разработчиков. Если вы новичок в методологиях, вам может быть трудно понять некоторые из замечаний автора. Если вы в течение нескольких лет были частью команды разработчиков, которая использует Agile-методы, книга, вероятно, несколько раз попала в точку. Для членов команды разработчиков, не являющихся инженерами, эта книга дает прекрасное изложение точки зрения другой стороны. В мире сертификации и «Agile Con Artists» эта книга действительно проливает свет на проблемы Agile-мира, которые большинство из них не признает.

Меня зовут Адриан Вайгель, я работаю в команде разработки продуктов Reservix. Английский не является моим родным языком, поэтому, пожалуйста, терпите меня ...