[PHPCONF09] практика построения среды разработки, определяющей процесс проектирования

[confguru]

[PHPCONF09] практика построения среды разработки, определяющей процесс проектирования

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

Понятие «предметная область проекта» раскрывается на примерах нескольких реальных проектов.

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

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

Отдельно описываются типичные проблемы и решение этих проблем.

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

Автор
The employer http://unitecsys.com/
http://phpclub.ru/talk/member.php?s=&action=getinfo&userid=24133

 

[whirlwind]

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

 

[The employer]

Хоть я сейчас и в отпуске, но периодически к компьютеру подхожу и могу прямо здесь отвечать на вопросы и раскрывать тему более подробно. Просто немного не в realtime

Пишите вопросы.

 

[whirlwind]

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

 

[grigori]

сплошной абстракционизм
еле прочел с 3го раза, на конфе скорее всего засну

 

[Sherman]

Автор оригинала: whirlwind
Вопрос: Представьте себе, что вам нужно создать веб-приложение «багтрекер» для компании-разработчика ПО. Вам программировать запрещено, писать приложение будут другие люди. Составьте перечень документации, необходимой для передачи проекта разработчикам, для принятия от разработчиков результата, и для ввода багтрекера в эксплуатацию.

Легко

1. Business Vision - зачем багтракер вообще, какие задачи решает.
2. FSR - Функциональные требования. Самый толстый документ. В нем подробно описывается функционал.
3. UI Requirements. - User Interface (делается на основе FSR и пожеланий юзеров).
4. Test cases. В дополнении к unit-тестам, которые хорошие разработчики пишут сами, также составляется документ, где указывается набор разных test cases для приема приложения. TIP. Хорошо бы задействовать возможности анализа покрытия кодом вашего unit framework для того, чтобы убедиться, что test cases покрывают ключевые участки кода.
5. План релиза. Если релиз сложен технологически, составляется план релиза, который предполагает фиксацию всех шагов по выкладке.

p.s. Словарь предметной области включается обычно в FSR.

 

[whirlwind]

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

 

[AmdY]

Sherman
ага, но это не Getting Real и такой подход трудно применим к подавляющему большинству средних компаний.
мне как человеку обжёгшемся на этом было бы очень интересно выслушать ещё одну точку зрения, жаль что заочно . потому что умные и правильные методики редко подходят к компаниям, где процесс не отлажен как в гигантах, которые эти методики продвигают (sun, ms ....)
Двумя руками за, главное, чтобы понятно и с _рельной_ практикой и примерами.

 

[The employer]

Автор оригинала: Sherman
Легко

1. Business Vision - зачем багтракер вообще, какие задачи решает.
2. FSR - Функциональные требования. Самый толстый документ. В нем подробно описывается функционал.
3. UI Requirements. - User Interface (делается на основе FSR и пожеланий юзеров).
4. Test cases. В дополнении к unit-тестам, которые хорошие разработчики пишут сами, также составляется документ, где указывается набор разных test cases для приема приложения. TIP. Хорошо бы задействовать возможности анализа покрытия кодом вашего unit framework для того, чтобы убедиться, что test cases покрывают ключевые участки кода.
5. План релиза. Если релиз сложен технологически, составляется план релиза, который предполагает фиксацию всех шагов по выкладке.

p.s. Словарь предметной области включается обычно в FSR.

Очень хорошо!

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

2 All: дело в том, что перечисленные знания все равно так или иначе присутствуют на каждом проекте. Они могут быть по-разному структурированы, распределены по документам или слиты в единое ТЗ, они могут быть вообще не записаны - но хотя бы в голове людей, исполняющих проект, они обязательно есть. Иначе беда

 

[Sherman]

Согласен.

План тестирования у нас тоже был. Обычно составляется temalead-ом и нач. отдела тестирования.

А тех. характеристики обычно обсуждаются lead-ом, архитектором и отделом маркетинга

2whirlwind

Оплачивает конечно заказчик. Но дело в том, что заказчиком является сама компания. Думаю, что такое кол-во документации возможно только в компании, где есть соотвествующий штат и цели. Я работал в такой компании, где все это было. Штат там был примерно 20-25 человек.

Альтернативой может служить и иная модель. Команда из 3-5 человек, документации не очень много, но при этом есть опыт, четкое понимание целей и Команда. Тогда на документации можно сэкономить. Скажем, все решения принимают 2-3 человека, это фиксируется в неформальной форме. До исполнителей же доходят уже конкретные задачи. Пример: lead сам ставит подробную задачу своим программистам. Если надо, подробно объясняет детали и т.д. Ключевое здесь - Команда.

Сразу оговорюсь, что последнее время(около 4 лет), я занимаюсь только долгоиграющими и довольно большими проектами, которые могут развиваться годами.

Про итеративность. Она никак не противоречит моим словам.
Пример. По каждому мажорному релизу можно обновлять документацию. И делается это обычно в том время, когда в разрбаотке находится очередной релиз. Итерация две недели-месяц. Исключение - business vision. Его конечно надо знать хотя бы на год-другой вперед

2AmdY

Как только у тех, кто платит деньги появляется понимание, что неправильное развитие проекта стоит дороже, чем составление документации, так через месяц у вас уже все появится

-~{}~ 01.09.09 22:25:

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

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

А закачик получает минимизацию рисков и предсказуемость.

Profit!

p.s. План составляет обычно lead вместе с менеджером и другими участниками. Он знает кому что дать делать, у кого какие слабые-сильные стороны, у кого жена рожает и прочие флуктуации

 

[The employer]

Автор оригинала: Sherman
Сразу оговорюсь, что последнее время(около 4 лет), я занимаюсь только долгоиграющими и довольно большими проектами, которые могут развиваться годами.

Это заметно.

Автор оригинала: Sherman
Да, забыл сказать про еще один очень важный документ. Самый важный для разработчиков. Это план разработки. На каждый(я считаю ближайший, но некоторые делают и "дальше") релиз делается подробный план разработки. Расписывается по датам все задачи на всех людей, принимающих участие на данном этапе. Тут же учитываются и все риски, связанные с разработкой.

Кстати, в какой форме вы учитываете риски разработки? И какие вообще риски относите собственно к разработке?

Автор оригинала: Sherman
Собственно, вся документация нужна НЕ разработчику, а заказчику, потому что по этой доке разработчики составляют план разработки и называют срок. И хорошие разработчики в него укладываются.

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

Автор оригинала: Sherman
А закачик получает минимизацию рисков и предсказуемость.

Не-а. Заказчик либо ВЕРИТ разработчику, либо имеет хорошие рычаги воздействия на разработчика (случай большой госконторы и маленького подрядчика). Минимизация рисков и предсказуемость нужна подрядчику. Заказчику нужен только сам результат. Заказчик крайне неохотно идет на то, чтобы разделить риски с разработчиком. Ему достаточно собственныого пакета рисков проекта (величина ROI, к примеру - иметь хотя бы неотрицательный возврат ).

Об откатах не будем, это отдельный вид бизнеса, не имеющий отношения к разработке ПО. Там не нужны никакие документы (кроме актов выполненных работ) и тем более не нужны никакие методологиии (см. ЕГАИС, см. 5-й терминал Хитроу, см. VCF).

 

[Sherman]

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

Другое - это проф. разработка программного обеспечения.

Другое - это кристаллизация супер команд.

Другое - это постоянный проф. рост исполнителей.

Другое - это решение сложных и интересных задач(поверьте они есть везде).

Другое - это любимая работа в кайф за достойные деньги.

==================================================

К рискам непосредственной разработки ПО я отношу следующие:

1. Работа не будет сделана вообще.
2. Работа не будет сделана качественно(это дискусионный вопрос, но давайте положим, что этот предел качества ограничен жизнеспособностью проекта и разумной ценой дальнейшей поддержки).
3. Работа не будет сделана в срок.

Если первые две группы рисков снимаются автоматически, если есть грамотная команда(высокий тех. уровень, профессионализм), то третья группа рисков практически не зависит от тех. профессионализма исполнителей.

Качественная документация дает возможность разработчикам адекватно оценить сроки реализации и сделать подробный план реализации(задачи не более 1-2 дней). Этот план может корректироваться по ходу. Но процесс абсолютно предсказуем.

А если документации нету или она не достаточна, то сроки оценить невозможно. В случае невыполнения плана(а как его выполнить если сроки брали с потолка), начинаются конфликты, которые никогда не заканчиваются вином.

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

 

[whirlwind]

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

что процесс должен быть прогнозируемым

Две недели-месяц итерация? Херасе! Просто покажите мне проектную документацию вашего проекта. Как говорят в народе show me the code.

The employer я кстати пытаюсь поставить себя на место того мифического разработчика, которого зазывает вакансия на вашем сайте. Поработав и программером, и тестировщиком, но тем не менее избегая контактов с непосредственными заказчиками, я уже не понимаю как ваши требования можно качественно реализовать в рамках 24 часов. Ну то есть если добавить к 16 часам тестирования и разработки еще 8 часов всего остального, то и получатся 24. А жрать, срать, спать время не предусмотрено чтоле?

 

[Sherman]

2whirlwind
У меня бывали ситуации, что проект почти полностью переделывался после полугода разработки, потому что "сделали не то, что хотели". А время работы 8-10 человек на 6 мес. - это ояебу денег(здесь не было внутренних релизов). Поэтому планирование - это важная часть. Она может вообще треть занимать, от всего времени разработки.

А в чем собственно проблема с итерациями?

Проектную документацию показать - не могу, по понятным причинам.

Про итерации чуть подробнее.

Я имею в виду итерации n+1. То есть вот запустили проект - и далее вкатываемся в циклы. На моей новой работе, у нас бывают итерации вообще по неделе.

В обощем, с итерациями тут немного сложнее. Рамки итераций обычно ограничены с одной стороны бизнесом(нельзя выпускать релиз 1.2 без фитчи Х) и с другой планированием(я считаю, что _подробное_ планирование более, чем а месяц - это пустая трата времени).

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

Про первую итерацию. Здесь опять же можно делать внутренние релизы и презентации, если Высокое начальство требует отчета.

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

p.s. Некоторые вещи я пишу так как они должны быть в идеале, с моей точки зрения. Абсолютные же цифры сильно зависят от специфики проекта, компании, команды и многих другей вещей. Ну простой пример. Если у вас нету отдела QA, то очевидно, что вы больше времени потратите на unit-tests. Если у вас слабый отдел проектирования, то будет больше времени на уточнение деталей UI, логики и т.д.

 

[whirlwind]

Отдел QA к юнит тестам абсолютно никакого отношения иметь не может.
И это чьи слова?

Его конечно надо знать хотя бы на год-другой вперед

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

 

[Sherman]

"Его" - это business vision. То есть, вот вы делаете, например, проект. И вы знаете, зачем он вам, как вы будеет его развивать, монетизировать и т.д. То есть есть стратегия, а есть тактика.

Ну про практику, у меня есть резюме(см. мой круг), там есть некоторый список того, в чем мне доводилось учавствовать.

Качество кода у нас примерно такое: http://onphp.org.

Есть еще возможность нанять меня консультантом, например, и мы можем поработать над конкретикой

-~{}~ 02.09.09 03:21:

Про отдел QA. Если вы про, то что unit test-ы заменяют QA, то нет - не заменяют. Но _код_ таким образом протестировать вполне можно. У меня сейчас проект, например, где нужно тестировать практически только сам код.

 

[whirlwind]

Ага, меня тоже можно нанять coach-ем или консультантом по QA. В качестве бонуса: модули реализуют определенный функционал в виде программы или ее части на выбранном языке программирования, следовательно для тестирования модуля требуется квалификация программиста. Если у вас в QA сидят люди которые делают как минимум 50% работы программиста, то у вас явные проблемы с разделением обязанностей.

PS. onphp смотрел. давно правда, больше года назад. Насколько помню, модульных тестов на тот момент не было. Сейчас есть, но для сравнения если меряться мои последние проекты

Tests: 1181, Assertions: 6633, Incomplete: 15.
Tests: 69, Assertions: 2236, Incomplete: 1.
Tests: 286, Assertions: 1500

ну и тп покрытие 98%

 

[The employer]

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

Другое - это проф. разработка программного обеспечения.

Другое - это кристаллизация супер команд.

Другое - это постоянный проф. рост исполнителей.

Другое - это решение сложных и интересных задач(поверьте они есть везде).

Другое - это любимая работа в кайф за достойные деньги.

Подход мне нравится. Прям хоть сейчас бери и вывешивай у нас на сайте.

Автор оригинала: Sherman
К рискам непосредственной разработки ПО я отношу следующие:

1. Работа не будет сделана вообще.
2. Работа не будет сделана качественно(это дискусионный вопрос, но давайте положим, что этот предел качества ограничен жизнеспособностью проекта и разумной ценой дальнейшей поддержки).
3. Работа не будет сделана в срок.

Сорри, это как-бы не совсем риски. Это проявления рисков.

Риски - это причины, по которым работа может быть не сделана вообще, может быть сделана некачественно (то есть не будет удовлетворена часть некритичных требований), или работа не будет сделана в срок.

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

Соответственно, меры по снижению и предотвращению для разных рисков (разных причин проблем) - тоже будут разными.

Вот мой вопрос как раз о причинах. Какие причины неудач вы относите непосредственно к разработке?

 

[baev]

Риски - это причины, по которым работа может быть не сделана вообще,

— очень оригинальное определение.

Риск — это вероятность неудовлетворительного итога.
Например, «вероятность того, что работа не будет сделана вообще». В случае неизвестного ранее исполнителя вероятность будет 0.5 — «или сделает или не сделает».

 

[The employer]

Автор оригинала: whirlwind
The employer я кстати пытаюсь поставить себя на место того мифического разработчика, которого зазывает вакансия на вашем сайте. Поработав и программером, и тестировщиком, но тем не менее избегая контактов с непосредственными заказчиками, я уже не понимаю как ваши требования можно качественно реализовать в рамках 24 часов. Ну то есть если добавить к 16 часам тестирования и разработки еще 8 часов всего остального, то и получатся 24. А жрать, срать, спать время не предусмотрено чтоле?

Странный вывод. "Здесь мерилом работы считают усталость"?

Как связаны между собой качество выполнения работы и количество ежедневно отрабатываемых часов?

-~{}~ 02.09.09 16:50:

Автор оригинала: baev
— очень оригинальное определение.

Риск — это вероятность неудовлетворительного итога.
Например, «вероятность того, что работа не будет сделана вообще». В случае неизвестного ранее исполнителя вероятность будет 0.5 — «или сделает или не сделает».

Это Вы цепляетесь к словам зачем-то. Вы приводите узкое определение одного из количественных параметров риска (второй количественный параметр - стоимость риска).

Я же употребил это слово (и это ясно из контекста, из самой постановке вопроса о списке рисков) в смысле определения, например, из Энциклопедического словаря экономики и права:

Риск

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

-~{}~ 02.09.09 16:57:

Ну или можно еще взять определение риска из RUP:

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