Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Креш-тест: видение эффективного процесса разработки


Александр спрашивает:

— Мое видение эффективного процесса разработки. Имеет ли право на жизнь? Что улучшить-добавить-убрать?


Когда я вижу такую диаграмму, я пытаюсь воспринимать ее примерно так:

Effective SW Development — это ни что иное, как совокупность Specifications, Development, Time tracking... Которые, в свою очередь, подразделяются на следующие компоненты...

Если посмотреть в самые нижние уровни, можно увидеть, что, пожалуй, не стоит рассматривать диаграмму как декомпозицию:

Version Control:

  • History of all changes
  • Team work
  • Makes work easy

То есть, связь в диаграмме не очень-то похожа на «состоит из / является частью», больше на «как-то связано с». Но тогда получается, что отсутствие линии должно говорить об отсутствии связи, что тоже явно неверное предположение: как же могут оказаться несвязаны User interface or API и Usability testing, или, скажем, Test Driven Development и Meet the specifications.

Тогда это больше похоже на облако тегов. Или «заметки на полях» про которые надо бы не забыть сказать на презентации. Да и основная декомпозиция состоит из странного набора: тут есть и чисто технологические вопросы (Version control, Bug tracking, Code review), есть и методологические проблемы (Development, Specifications, Testing) и общеменеджерские вопросы (Time tracking, Risk management, Early Problem Detection) да и организационные тоже (Common place for all related information).

Выходит, это чеклист? Не забудьте сделать это, это и это — и будет все хорошо? Кто позаботится об этом и этом — у того и будет эффективный процесс разработки?

Кстати, это нельзя называть и процессом. Процесс — это нечто протяженное во времени, активно происходящее в нем. Тут же мы имеем некоторые наброски тем, в которых нет связи со временем. В тексте самых нижних уровней есть кое-какие указания на неоднородность во времени:

  • Find problems at early stages
  • History of all changes
  • No early optimization
  • Processes description
  • Quick start guides

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

Я думаю, это подойдет только для игры в Buzzword Bingo. Годный набор, чтобы сделать примерно такие карточки, и слушать, как кто-нибудь со сцены будет все это озвучивать:

Meet the SpecificationsSelf Documented CodeRisks MonitoringCoding StyleEarly Problem Detection
Test Driven DevelopmentTesting of MaintainabilityAvoiding AntipatternsRefactoring When NeededTeam Work
Assign Issues to ResponsiblessKnowledge Sharing Inside the TeamSet of Acceptance TestsAvoiding ComplexityUsability Testing
History of All ChangesRisks TrackingRegression TestsMetricsDesign Patterns
The Only Base For All IssuesNo Early OptimizationSeparate Testing TeamWhat Could Be Done to Prevent Risk?Nightly Builds

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



33 коментарі

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
C моей точки зрения, у данной конкретной попытки есть несколько недостатков:
— процесс определяется условиями проекта. Соответственно, из вышеуказанного набора опытный человек будет выбирать подчасти, которые соответствуют потребностям проекта (при чем в соответствии текущему этапу жизни проекта). Эффективный процесс для стартапа, у которого задача определить, есть ли незакрытая потребность в целовом рынке, и готовы ли люди платить за эту потребность, и у легаси продукта, у которого 2 тысячи пользователей, для которых главное — стабильность — будет по определению разный
— реализация практик опять таки определяются условиями — коде ревью организовывается достаточно по разному, когда вся команда сидит в одной комнате, и размер команды 4 человека, и когда команда распределена по 4 локациям, и на проекте кодит 30-40 человек
— неполнота практик — в данном случае мало говориться о конфигурационном менеджменте (который включает в себя не только контроль версий), процессе релизов, мониторинг енвайроментов, архитектуру для того, чтобы выдерживать большие нагрузки и интеграционном менеджменте (когда у приложения может быть 15-20 связянных приложений), continuous delivery; continuous testing, ...
— избыточность практик для конкретного проекта — вполне успешно можно делать проекты без тайм трекинга, если разрабатываеш себе в удовольствие, например :-)

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

Алексей, расшарьте исходник этой mind map.

У меня его нет. Спрашивайте у автора.

Good summary on the common sense and proven things piled up together. But I believe challenge is “to do a common thing uncommonly well”, so it’s more about “how” not “what”. For instance: will need loose coupling and separation of concerns in design to support agility and frequent changes effectively, this won’t just magically appear from the blind usage of design patterns and avoiding complexity. Automated testing? How to get maintainable code from QA team? etc. etc. etc. So I wouldn’t certify project as one using “effective” process even if all these practices are used, qualitative assessment will be required to make any reasonable conclusions.

Даже если все это юзать, это еще не гарантия эффективной разработки.
Алсо, немного попридераюсь:
— Early Problem Detection я бы раскидал между Testing и Development
— Design заслуживает более подробного раскрытия
— Auto-generation from code — это скорее Documentation (которое, кстати, можно смело выделить из Common place for all related information), а не Design

— может лучше Implementation вместо Development?

Но если, скажем, на проекте нет и половины перечисленного — то вполне себе сигнал, что вряд ли все закончится хорошо, нет?

Я думаю, это подойдет только для игры в Buzzword Bingo.

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

В итоге или заламываешь цену или сразу «давай — досвидания».

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

Руководитель, кстати, не всегда виноват — нередко у него связаны руки «вказiвками» от заказчика из серии «А за QA/unit testing/... мы платить вам не будем» — тебе ли не знать, ты же сам участвовал в подобном проекте?

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

Вот поэтому лучше принести такую схему на собеседование, что бы не попасть на такой проект с таким клиентом.
Потому что в крупной компании проект решает. Денег-то платят всем примерно одинаково (за «звания»), но на одном проекте хороший клиент, аджайл, энтузиазм, фан, тимбалдинги и т.д. А на другом — унылое гнилое болото и никто ничего не может изменить.

Well, this perspective is hands down the best one in the overheated market conditions. In more developed markets people are getting paid for “solving problems” not for “having skills”, plus let’s face it majority of the projects out there do have design, code base and people issues (people means both project manager and the whole team — don’t believe in one person accountability when we speak about team work). So alternative perspective I’d like to offer is that joining problematic project and being proactive in getting things better could actually help professional to gain very valuable problem solving, change management and soft/people skills. Yes it would be challenging but making mistakes and pushing limits is the only way to learn/progress as for me.

So alternative perspective I’d like to offer is that joining problematic project and being proactive in getting things better could actually help professional to gain very valuable problem solving, change management and soft/people skills. Yes it would be challenging but making mistakes and pushing limits is the only way to learn/progress as for me.
It is a noble challenge to solve problems on the problematic project to make it better. If to make it better is the goal. But often this is not a case. Because to move ahead someone have to pay for correcting previous mistakes and technical debts first.
So instead development skills are usually used to invent botchery patches and soft skills are used to mask the problems.
“How to Ride a Dead Horse”
www.tonycooke.org/...ns/25_ways.html

В чем вы делали самую первую диаграмму?

Думаю основная ошибка в том, что виды разработки очень разные бывают, много вариаций на тему кто, что и зачем разрабатывает. Например если зоопарк из 100 человек кодит по спецификациям от клиента в аутсорсе, с завуалированной целью зачарджить часы по максимуму и подсадить клиента на зависимость, то многие пункты вполне приносят пользу. Если 3 хакера делают инновационный продукт, то 90% пунктов вполне можно выкосить.

Интересно, какие 10% пунктов останутся у хакеров.

version control system, bugtracking, wiki например можно оставить

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

In outsourcing engagements headcount wouldn’t grow without value being delivered to client ;)

easily, have you not heard about “dead bodies”? :)

А что будет лишним для «своего» проекта размера выше среднего (несколько человеко-лет хотя бы)?

Позитив: Ну хоть не про ХР-ов.

Не позитив: Я так и не осознал суть этого раздела (и текущей статьи). Мо мне кто-то объяснит?

Люди которые считают себя не очень опытными задают вопросы людям которых администрация сайта почему то считает более опытными. Последние отвечают. С уважением, твой К.О.

Анонс раздела тут:

dou.ua/...razrabotchikov

В статье — видение эффективного процесса разработки неким Александром в виде mindmap-а и комментарии Алексея Колупаева к этому видению.

В следующий раз скорее всего будет статья-code-review.

О, это будет поинтереснее мочилово!

Это mind map, я считаю что допускаются различные связи типа часть-целое и просто отношение, без явного указания. Они и есть типа заметок на полях.

Слепой и глухой за девушек поговорили.

Олег, формат креш-теста позволяет отвечать не только одному человеку на вопрос,

если вам есть что посоветовать Александру по его диаграмме — советуйте.

У меня, как и у автора первого ответа, другое восприятие реальности. Поэтому процесс в виде mindmap я не понимаю. Это совсем не значит, что автор диаграммы что-то делает не так.

Ну вы вполне могли бы написать своими словами о вашем видении эффективного процесса разработки.

Підписатись на коментарі