Сотфверный Процесс Завалишина, первый пост
Оригинал взят у dz в Сотфверный Процесс Завалишина, первый пост
Этим постом я начинаю проект по описанию некоторого подхода к разработке ПО, который условно называю "Сотфверный Процесс Завалишина".
Не потому, что я претендую на то, что это мои идеи - категорически нет. Тут нет ни одной моей идеи. (Основные источники - RUP, CMMI 3, Tom Gilb, личный опыт, опыт компаний.)
Потому, что это - описание такого процесса разработки, который сформировался у меня в голове за последние 15 лет, от Яндекса, в котором все процессы я выстраивал впервые и для Яндекса и для себя, и до группы компаний DZ Systems, в которой есть специальные люди, которые отвечают за процессы.
Из последнего следует, что, собственно, не стоит полагать, что описанный процесс полностью идентичено тому, который принят в DZ. Нет. Естественно, мой образ мысли довлеет над сотрудниками DZ Systems и в какой-то степени я являюсь драйвером преобразований в сторону того, что здесь будет описано, но об идентичности речь точно не идёт. Тем более, что, в целом, в мобильной тематике (E-Legion) и в энтерпрайзе (Digital Zone), процессы различаются.
Итого. Я описываю именно свою карту мира.
Что такое процесс. Процесс - это совокупность правил, шаблонов документов и практик, которые позволяют превратить разработку софта из ремесла в производство.
Как отличить хороший процесс от плохого? Хороший процесс обеспечивает, в первую очередь, стабильность результата. Как она измеряется? Что есть результат?
Предметом процесса является проект по разработке ПО (дальше уточню ограничения). Оценкой качества проекта является степень попадания сроков и стоимости в предсказанные. Для ориентира - если все проекты попадают в цель с точностью 20%, процесс хорош.
Чтобы ещё раз проиллюстрировать: процесс позволяет превратить точность оценки сроков и стоимости в -50...+500% в точность -20..+20%. В реальности, конечно, никаких -20% не существует, но это больше в силу давления со стороны заказчика по раздуванию скоупа.
Естественно, что для разных видов разработки нужны разные процессы. Например, авиационный софт делается по другому, более жёсткому (и имеющему элементы аудита) процессу, который я здесь не затрагиваю вообще. (Хотя - не зарекаюсь.)
В целом Данная модель применима для задач, связанных с разработкой программного обеспечения при условии, что:
Начиная такую тему невозможно не сказать пару слов про эджайл. Скажу.
Эджайла нет. Уложился? :)
Уточню.
Все записи по этой тематике можно будет найти по тегу ПроцессЗавалишина.
Этим постом я начинаю проект по описанию некоторого подхода к разработке ПО, который условно называю "Сотфверный Процесс Завалишина".
Не потому, что я претендую на то, что это мои идеи - категорически нет. Тут нет ни одной моей идеи. (Основные источники - RUP, CMMI 3, Tom Gilb, личный опыт, опыт компаний.)
Потому, что это - описание такого процесса разработки, который сформировался у меня в голове за последние 15 лет, от Яндекса, в котором все процессы я выстраивал впервые и для Яндекса и для себя, и до группы компаний DZ Systems, в которой есть специальные люди, которые отвечают за процессы.
Из последнего следует, что, собственно, не стоит полагать, что описанный процесс полностью идентичено тому, который принят в DZ. Нет. Естественно, мой образ мысли довлеет над сотрудниками DZ Systems и в какой-то степени я являюсь драйвером преобразований в сторону того, что здесь будет описано, но об идентичности речь точно не идёт. Тем более, что, в целом, в мобильной тематике (E-Legion) и в энтерпрайзе (Digital Zone), процессы различаются.
Итого. Я описываю именно свою карту мира.
Что такое процесс. Процесс - это совокупность правил, шаблонов документов и практик, которые позволяют превратить разработку софта из ремесла в производство.
Как отличить хороший процесс от плохого? Хороший процесс обеспечивает, в первую очередь, стабильность результата. Как она измеряется? Что есть результат?
Предметом процесса является проект по разработке ПО (дальше уточню ограничения). Оценкой качества проекта является степень попадания сроков и стоимости в предсказанные. Для ориентира - если все проекты попадают в цель с точностью 20%, процесс хорош.
Чтобы ещё раз проиллюстрировать: процесс позволяет превратить точность оценки сроков и стоимости в -50...+500% в точность -20..+20%. В реальности, конечно, никаких -20% не существует, но это больше в силу давления со стороны заказчика по раздуванию скоупа.
Естественно, что для разных видов разработки нужны разные процессы. Например, авиационный софт делается по другому, более жёсткому (и имеющему элементы аудита) процессу, который я здесь не затрагиваю вообще. (Хотя - не зарекаюсь.)
В целом Данная модель применима для задач, связанных с разработкой программного обеспечения при условии, что:
- Типовой размер проекта - от нескольких до примерно сотни человеко-месяцев. Проекты меньшего размера исполнимы при урезанных требованиях к процессу, проекты большего размера требуют дробления и иерархичности.
- Типовой срок проекта - от полугода до двух лет.
- Разрабатываемое программное обеспечение ориентировано на business critical сегмент, то есть простой такого ПО, расхождение в сроках реализации или несоответствие результата задачам бизнеса является критичным.
- Заказчик требователен к бюджету, то есть не существует возможности работать таким образом, что стоимость проекта известна только в момент его завершения. Предполагается, что проект нуждается в черновой оценке стоимости на старте и достаточно точной (+-10%) по истечении первой четверти запланированного времени.
- От работоспособности результата не зависит жизнь и здоровье людей. Иначе нужен куда более жёсткий процесс.
Начиная такую тему невозможно не сказать пару слов про эджайл. Скажу.
Эджайла нет. Уложился? :)
Уточню.
- Настоящий полноценный эджайл возможен и полезен, когда у проекта неограниченный срок и бесконечное финансирование. Пример: проект по написанию этих постов я веду по эджайлу. Почему? Потому, что для меня как заказчика проекта он является полезным будучи завершён примерно в любой точке. В этом смысле ресурсы проекта бесконечны, потому что он остановится там, где ресурсы кончатся, и это не будет значить провала проекта.
- Реально, конечно, эджайл вполне есть, особенно при высоком уровне доверия между заказчиком и исполнителем. При этом существуют механизмы повышения уровня такого доверия. Я постараюсь затронуть эти темы. Собственно, ощутимая часть проектов DZ Systems ведётся по эджайлу, Особенно хорошо эджайл ложится на проекты по мобильной тематике и проекты по развитию и техподдержке.
- Как правило, люди, пропагандирующие эджайл не дают чёткого и однозначного описания того, что они имеют в виду. Именно поэтому первая моя рефлекторная реакция на это слово - отторжение. Слишком много хайпа.
- Поскольку данный проект идёт по эджайлу, вы вольны вносить в беклог предложения по его фичам и предлагать к обсуждению и описанию практики, артефакты и процессы, которые считаете важными.
Все записи по этой тематике можно будет найти по тегу ПроцессЗавалишина.