Книга: Постигая Agile

Сноски из книги

· #1

Стеллман Э., Грин Дж. Идеальные команды. Вдохновляющие и предостерегающие рассказы ветеранов тимлидинга. М.: Символ-Плюс, 2010.

· #2

Кон М. Scrum. Гибкая разработка ПО. М.: Вильямс, 2016.

· #3

Джон Дьюи (1859–1952) – американский философ и педагог, представитель философского направления «прагматизм». Автор более 30 книг и 900 научных статей по философии, социологии, педагогике и другим дисциплинам. Прим. ред.

· #4

Водопадная модель (англ. waterfall model, иногда называют «каскадная модель») – модель процесса разработки программного обеспечения, при котором команда вначале определяет требования к продукту, планирует проект в целом, разрабатывает программное решение, а затем создает код и тестирует продукт.

· #5

Узнать больше о том, как разговорный стиль помогает в обучении, можно в книге Clark, Ruth, Mayer, Richard. E-Learning and the Science of Instruction. Wiley, 2011.

· #6

«Никомахова этика» – одно из трех этических сочинений Аристотеля. Считается, что название эта работа получила, поскольку впервые была издана около 300 года до н. э. Никомахом – сыном Аристотеля. Но есть версия, что книга посвящена отцу Аристотеля, которого тоже звали Никомахом. Прим. ред.

· #7

Глобальный онлайн-опрос agile-компаний, проведенный в 2008 году независимой исследовательской компанией Forrester.

· #8

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

· #9

Chief Executive Officer – главное должностное лицо компании, аналог генерального директора в российской иерархии. Прим. ред.

· #10

Питер Наур и Брайан Рэнделл. «Разработка программного обеспечения: доклад о работе конференции под эгидой Научного комитета НАТО», Гармиш-Партенкирхен (Германия), 7–11 октября 1968 года (Брюссель. Отдел по научным вопросам, НАТО, 1969), 231.

· #11

Последний отчет о состоянии вы можете найти на сайте stateofagile.versionone.com.

· #12

Dave West. Water-Scrum-Fall Is The Reality Of Agile For Most Organizations. Forrester, 26 июля 2011 г. http://bit.ly/water-scrum-fall.

· #13

Jim Highsmith. Agile Project Management: Creating Innovative Projects. 2nd Edition (Upper Saddle River, NJ: Pearson Education, 2009).

· #14

Русский перевод книги готовится к выходу в издательстве «Манн, Иванов и Фербер». Прим. ред.

· #15

Lissa Adkins. Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Transitions (Boston: Addison-Wesley, 2010).

· #16

Страница из англоязычного варианта «Википедии» (Blind Men and the Elephant, проверено 25 июня 2014 года).

· #17

Коберн А. Быстрая разработка программного обеспечения. М.: Лори, 2013.

· #18

Существуют некоторые разногласия по поводу того, действительно ли Генри Форд так говорил, но почти все согласны с тем, что ему бы понравилась эта мысль.

· #19

См. в уже упоминавшейся книге Алистера Коберна «Быстрая разработка программного обеспечения».

· #20

Источник: agilemanifesto.org/principles.html (по состоянию на июнь 2014 г.).

· #21

Традиционные руководители проектов также признают, что документация – это просто одна из форм общения. Типичные менеджеры изучают разницу между формальным и неформальным способами общения, а также разницу между письменной и устной коммуникацией. Они также изучают невербальные сигналы в общении и узнают, что общение – наиболее эффективное средство генерации идей. Все эти знания фактически проверяются на экзамене по PMP!

· #22

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

· #23

Keep it simple, stupid.

· #24

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

· #25

Еще одно упрощение. Пока мы просто выдвинем идею, что agile-команды занимаются проверкой сделанного и адаптацией. В главе 4 вы подробнее узнаете об этом на примере scrum-команды и о том, как это связано с самоорганизацией команд.

· #26

Jim Highsmith. Agile Project Management: Creating Innovative Products (Upper Saddle River, NJ: Pearson Education, 2009).

· #27

Не кажется ли вашей команде, что ежедневные встречи – это нереально? Может быть, вы так думаете, потому что люди распределены между командами или имеются другие обязательства? Вы уже начали искать альтернативные варианты, например заменить ежедневные scrum-митинги на онлайн-собрания или вики-страницу? Это может быть показателем того, что вам необходимо изменить свой образ мыслей, чтобы получить наилучшие результаты от Scrum.

· #28

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

· #29

Из англоязычного варианта «Википедии» (The Chicken and the Pig, проверено 26 июля 2014 года).

· #30

Разговор о «свиньях» и «курицах» выглядит странно, но scrum-команды действительно делают это. На самом деле некоторые старые версии scrum-руководства включают раздел, посвященный «свиньям» и «курицам»!

· #31

Уточню: настоящая «свинья» заботится об успехе проекта больше, чем о чем бы то ни было в своей профессиональной жизни. Есть немало вещей в личной жизни – например, семья, – о которых следует заботиться больше, чем обо всем прочем. Если это не так, то у команды проблемы с образом мыслей и он будет мешать устойчивому темпу работ.

· #32

Эти советы кажутся нереальными? Задевают за живое? Если команда не имеет права игнорировать отвлекающие факторы, то, возможно, они не должны ее отвлекать. Потому что отвлекающий фактор, который нельзя проигнорировать, превращается в требование. Если вы работаете в команде, где игнорирование «отвлекающего фактора» – серьезная проблема для проекта, то мышление вашей команды может стать препятствием для внедрения Scrum и с этим придется что-то делать.

· #33

Американский жаргонизм, означающий «вопрос, который не следует затрагивать или поднимать» (по аналогии с контактным рельсом в метро). Прим. ред.

· #34

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

· #35

Эта и другие эффективные коучинг-практики описаны в уже упоминавшейся книге Лиссы Адкинс Coaching Agile Teams.

· #36

Термин lean– и канбан-разработки, означающий критическую точку невозврата, до достижения которой система допускает разные варианты решения конкретной проблемы. Прим. ред.

· #37

Кон М. Пользовательские истории. Гибкая разработка программного обеспечения. М.: Вильямс, 2012.

· #38

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

· #39

Кон М. Пользовательские истории. Гибкая разработка программного обеспечения. М.: Вильямс, 2012.

· #40

J. Laurenz Eveleens and Chris Verhoef. The Rise and Fall of the Chaos Report Figures. IEEE Software, vol. 27, no. 1 (2010).

· #41

2002 CHAOS Report. The Standish Group International, 2002.

· #42

Еще один пункт в поддержку утверждения о пользе личного общения в сравнении с созданием всеобъемлющей документации!

· #43

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

· #44

См.: GASPing About the Product Backlog (по состоянию на 26 июля 2014 г.).

· #45

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

· #46

Если вы хотите узнать больше о покерном планировании, рекомендую книгу Planning Poker PDF, написанную соавтором Agile-манифеста Джеймсом Греннингом.

· #47

Scrum Metrics for Hyperproductive Teams: How They Fly like Fighter Aircraft (документ представлен на 46-й Гавайской международной конференции системных наук, Мауи, 7–10 января 2013 года).

· #48

Демарко Т., Листер Т. Человеческий фактор: успешные проекты и команды. М.: Символ-Плюс, 2014.

· #49

Steward Brand. How Buildings Learn: What Happens After They’re Built (London: Penguin Books, 1995).

· #50

Вернемся к принципам Agile-манифеста в главе 3. Какой из этих принципов применяется здесь?

· #51

Загляните и в нашу первую книгу Applied Software Project Management. Мы были правы. Характерное мировоззрение, присущее традиционной разработке программ и управлению проектами, – избегать изменений, что радикально отличается от менталитета их принятия. Но все-таки это обоснованное мышление, и оно может оказаться совместимым с гибкой разработкой ПО.

· #52

У нас тоже были такие проекты! И мы этого совершенно не стыдимся.

· #53

Как ни странно, некоторые менеджеры обманывают себя, думая, что команды работают продуктивно только благодаря такому давлению. [Они получают такую производительность команды, которой заслуживают.]

· #54

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

· #55

Эти разработчики говорят так: «У меня нет времени, чтобы искать ошибки в нашем коде, – я слишком занят тем, что сам их туда вношу!»

· #56

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

· #57

Единая система расчета зарплат автоконцерна Chrysler. Прим. перев.

· #58

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

· #59

Мы настоятельно рекомендуем читателям найти информацию о разновидностях кода «с душком» и антипаттернах. На наш взгляд, один из лучших ее источников – оригинальный сайт Wiki, созданный Уордом Каннингемом.

· #60

Некоторые люди используют термины edge case и corner case, взаимно заменяя их. Другие считают, что термин corner case используется реже, чем edge case (потому что угол – это место, где встречаются два края).

· #61

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it, проверено 12 марта 2017 г.

· #62

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

· #63

Стеллман Э., Грин Дж. Изучаем C#. М.: Питер, 2016.

· #64

О командах, работающих с открытым исходным кодом, можно прочитать в книге Эрика Реймонда The Cathedral and the Bazaar (O’Reilly, 1999). О повседневной жизни команд, работающих с открытым исходным кодом, читайте в книге Карла Фогеля Producing Open Source Software, которую можно бесплатно скачать на сайте http://producingoss.com/.

· #65

Вспомним цитату Грэди Буча об инновациях и страхе провала из главы 5. Здесь приведен хороший пример того, как команда совершенно не испытывает удовольствия от работы.

· #66

Не кажется ли вам странным, что программирование – это преимущественно умственное занятие? Вот небольшой эксперимент, чтобы доказать это самому себе. Вспомните кусок кода, для написания которого потребовались часы. Теперь перепечатайте его. Работа будет идти намного быстрее. Набор текста – это физическая часть написания кода, явно не самая трудоемкая.

· #67

Некоторые соображения о том, как разработчики достигают и поддерживают состояние «потока», можно найти в книге Тома Демарко и Тимоти Листера «Человеческий фактор. Успешные проекты и команды» (М.: Символ-Плюс, 2014).

· #68

Подробнее об истории 40-часовой рабочей недели и 8-часового рабочего дня: https://en.wikipedia.org/wiki/Eight-hour_day, проверено 12 марта 2017 года.

· #69

Полный список утилит: https://en.wikipedia.org/wiki/List_of_Unix_commands, проверено 12 марта 2017 года.

· #70

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

· #71

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

· #72

Считаете ли вы, что создаете сложные модульные тесты? Добиваетесь ли вы 100 %-ного тестового покрытия искусственно, придумывая тесты на все случаи жизни или очень сложные объекты? Получаете ли вы в итоге трудноизменяемые модульные тесты? Есть ли у вас тесты, закомментированные из-за того, что кому-то потребовалось внести изменения, «сломавшие» тест, а исправить его он не смог? Если вы ответили утвердительно на любой из этих вопросов, то, вероятно, создаете модульные тесты, которые усложняют ваш код, вместо того чтобы его упрощать.

· #73

В том числе и мы, поскольку выработали привычку всегда использовать TDD при написании кода.

· #74

Очень трудно не заметить сарказма в сообщении Кента Бека, опубликованном в Facebook. Объяснение этой шутки делает ее несмешной. Но дабы быть правильно понятым, Кент рассказывает, что раз TDD мертва, то он будет искать ему замену, которая была бы не хуже.

· #75

David Heinemeier Hansson. TDD is dead. Long live testing (23 апреля 2014 года).

· #76

http://wiki.c2.com/?CodeSmell

· #77

Существует великолепный ресурс для изучения вариантного мышления. Это образный роман Олава Маасена, Криса Маттса и Криса Гири Commitment. Можете поблагодарить Дэвида Андерсена за то, что он порекомендовал его нам.

· #78

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

· #79

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

· #80

Глядя на этот график, вы, возможно, удивляетесь, почему мы не называем его диаграммой совокупного потока или CFD? В главе 9 мы объясним разницу между WIP-диаграммой и CFD.

· #81

В книге Mythical Man Month Фред Брукс предложил нам так называемый закон Брукса: «Добавление людских ресурсов в конце проекта затягивает его выполнение». Подумайте об этом, читая о муда, мура и мури.

· #82

Андерсон Д.Канбан. Альтернативный путь в Agile. М.: Манн, Иванов и Фербер, 2017.

· #83

Канбан – это не способ управления проектом, что, конечно, не означает, будто Канбан не для менеджеров проектов! Дэвид Андерсон выпустил серию публикаций, которые объясняют, как менеджеры проектов могут применять Канбан в своей практике. Мы рекомендуем почитать его публикации, чтобы узнать об этом больше.

· #84

Мы выражаем благодарность Дэвиду Андерсону за помощь в формулировке этого раздела.

· #85

Выражаем благодарность Дэвиду Андерсону за помощь в формулировке.

· #86

Cumulative Flow Diagram (CFD) также иногда называют накопительной диаграммой потока. Прим. ред.

· #87

Поставщик, продающий жаренные во фритюре оливки на палочке, использует типичную push-систему – длинную очередь людей; так было в 2014 году. Они могли перейти на Канбан с тех пор, как была опубликована эта книга.

· #88

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

· #89

Вуден Дж. Современный баскетбол. М.: Физкультура и спорт, 1987.